> ## Documentation Index
> Fetch the complete documentation index at: https://docs.infraudit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Drift Detection Works in InfraAudit

> Learn how InfraAudit captures baselines, runs configuration comparisons, classifies drift by type and severity, and manages the drift finding lifecycle.

Drift detection is the process of comparing a cloud resource's current configuration against a known baseline and surfacing the differences. InfraAudit runs this comparison automatically on a schedule and lets you trigger it on demand — flagging security, configuration, and IaC changes before they become incidents.

## How baselines are captured

A **baseline** is a JSON snapshot of a resource's complete configuration at a point in time. It contains the full attribute set returned by the cloud provider API for that resource type — security group rules, encryption settings, tags, network configuration, and more.

Baselines are captured in two ways:

* **Automatically** — during the initial resource sync after you connect a provider, InfraAudit captures a baseline for every discovered resource.
* **Manually** — you can capture a new baseline at any time from the resource detail panel or the CLI:

```bash theme={null}
# Capture a new baseline for a specific resource
infraudit baseline create --resource <resource-id>

# List all baselines for a resource
infraudit baseline list --resource <resource-id>
```

See [Baselines](/concepts/baselines) for more on how to manage and promote baselines.

## How the comparison works

When the drift detection job runs:

1. For each active resource with a baseline, InfraAudit fetches the current configuration from the cloud provider API.
2. It retrieves the most recent baseline for that resource.
3. It performs a deep JSON diff between the baseline and the current configuration.
4. For each difference found, it evaluates the drift type and severity.

The comparison is attribute-aware — fields that change frequently without operational significance (metadata timestamps, internal tracking IDs, lease durations) are excluded from comparison to reduce false positives.

## Drift types

Each detected difference is classified into one of three types:

| Type              | Classification                                                                                   |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| **Configuration** | Any change that doesn't meet the security or compliance criteria below                           |
| **Security**      | Changes to ingress/egress rules, encryption settings, public access policies, or IAM permissions |
| **Compliance**    | Changes that violate a control in an enabled compliance framework                                |

## Severity levels

Severity is assigned per-difference based on rules specific to each resource type. Examples:

| Change                                               | Severity |
| ---------------------------------------------------- | -------- |
| S3 bucket `BlockPublicAcls` set to `false`           | Critical |
| Security group: inbound `0.0.0.0/0` added on port 22 | High     |
| EC2 instance type changed                            | Medium   |
| Resource tag added or removed                        | Low      |

## IaC drift

A separate drift type — **IaC drift** — compares live resources against your Infrastructure-as-Code declarations (Terraform, CloudFormation) rather than against baselines. IaC drift uses static analysis of uploaded files and runs against already-cached resource configuration, so it doesn't require additional cloud API calls.

See [Terraform](/integrations/terraform) and [CloudFormation](/integrations/cloudformation) for setup instructions.

## Scan frequency and manual triggers

The drift scanner runs on a cron schedule — the default is every 4 hours. To run a scan immediately:

```bash theme={null}
infraudit drift detect
```

Manual scans run immediately and store results alongside scheduled runs.

## Drift finding lifecycle

A drift finding moves through three states:

```
detected → investigating → resolved
```

* **Detected** — the scanner found a difference. No human has reviewed it yet.
* **Investigating** — a user acknowledged the finding and is investigating the cause.
* **Resolved** — the underlying change was either reverted, or the baseline was updated to accept the new configuration.

## Promoting a baseline after a planned change

After an intentional configuration change (such as a deployment), promote the current live state to a new baseline to clear existing drift findings:

```bash theme={null}
infraudit baseline create --resource <resource-id> --promote
```

This closes any open drift findings for the resource and sets the new configuration as the next comparison target.

## Suppressing false positives

If a specific attribute produces unwanted drift findings, you can suppress it with a drift suppression rule in the UI under the resource's **Drift** tab. You can also open a GitHub issue to have the attribute added to the provider-level exclusion list.