← Concepts & Glossary
Policy, Gates & Enforcement

Drift Detection

Catching configuration that has quietly moved away from its declared state.

What is drift detection?

Drift detection is the continuous comparison between declared state (what your IaC, Helm charts, deployment manifests, and policy documents say should be running) and actual state (what the clusters, registries, and runtime services are actually running right now).

Drift is usually benign in origin — a manual kubectl edit during an incident, an emergency hotfix that bypassed CI, a dependency updated on a running container — but malicious in consequence: the thing an attacker modifies after admission is, by definition, drifted. Detecting it is how you notice both kinds.

How it works

Three loops running continuously:

  1. Declared-state snapshot. The platform reads the source of truth — Git repos, Helm values, IaC plans, policy documents — and computes the intended configuration for each service and environment.
  2. Actual-state observation. Live data is pulled from Kubernetes clusters, container runtimes, cloud APIs, and SBOM fingerprints of running images. Hashes and versions are normalised so they can be compared apples-to-apples.
  3. Reconciliation and response. Deltas are classified. Benign drift (timestamp fields, autoscaler pod counts) is suppressed. Security-relevant drift (image SHA changed, admission-exempt flag flipped, unsigned workload running) is surfaced — and, where safe, auto-rolled-back to the declared state.

Why it matters

Pre-deployment controls — PR checks, CI gates, admission — answer "should this be allowed to run?" Drift detection is the only control that answers "what is actually running right now, and does that still match what we approved?" Without it, every other policy eventually decays: a rule becomes theatrical the moment production reality moves out from under it and no one notices.

It is also the control regulators increasingly expect in continuous monitoring programs — SOC 2 CC7.1, ISO 27001 A.8, PCI-DSS 4.0 requirement 11, and the EU CRA all care not just about what was approved, but about what is running.

What value it adds

  • Catches what post-admission controls miss

    Hotfixes, manual edits, autoscaler-spawned pods, and tampered workloads all show up as drift — even if they passed every pre-deployment check.

  • One-click rollback options

    When declared state is known-good, returning to it is deterministic — no forensic reconstruction required.

  • Security drift and operational drift share a lens

    Platform teams and security teams look at the same diff, which ends the old "who owns this change?" debate.

  • Continuous monitoring evidence for auditors

    A drift dashboard with timestamps and resolution records is exactly the artifact SOC 2 and ISO continuous-monitoring controls require.

  • Early warning for compromise

    An unexpected image SHA, a new sidecar, or a suddenly-exempted workload are exactly the indicators most intrusion playbooks flag — drift surfaces them in minutes.

How Safeguard uses it

Safeguard continuously reconciles declared policy and live runtime — comparing image SHAs, signatures, SBOM hashes, and policy-gate exemption state — and classifies drift by security impact. Approved rollback flows can return a workload to its last-known-good state in one click. See the full guardrails and enforcement use case for the end-to-end flow.

Know the moment production diverges from intent.

Safeguard watches declared vs. actual state across clusters and registries, classifies drift, and offers rollback in one click.