Skip to main content
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:
See 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:

​
Severity levels

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

​
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 and 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:
Manual scans run immediately and store results alongside scheduled runs.

​
Drift finding lifecycle

A drift finding moves through three states:
  • 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:
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.