What Is SBOM Drift?
SBOM drift is the divergence between a software system's declared bill of materials — generated at build or release time — and the actual components present in the running system.
Most SBOM generation happens during the build pipeline. A tool like Syft, cdxgen, or Fossity scans the source tree, package manifests, or build artifacts and produces a point-in-time inventory of components. That SBOM is accurate at the moment it was generated. The problem begins the moment the software is deployed and the environment around it starts changing.
How Drift Occurs in Practice
- Direct dependency updates: A security patch is applied to a dependency in production without going through the full build and release cycle
- Container layer modifications: Base image updates add, remove, or change system packages without regenerating the application-layer SBOM
- Runtime package injection: Init scripts, sidecar containers, or configuration management tools install packages at runtime
- Hotfixes and emergency patches: Files are modified directly on running hosts or containers to address critical issues, bypassing normal release processes
- Dependency resolution differences: The dependency resolver produces different results between build environment and production due to registry mirrors, version constraints, or environment variables
- Inherited drift from base images: The application SBOM does not include OS-level packages from the container base image, which receive independent updates from the image maintainer
Under OMB M-26-05 Tier 1 requirements and EU CRA product documentation obligations, the SBOM you provide to customers or regulators must accurately represent the software as deployed. An SBOM that reflects the build artifact but not the production system is a compliance liability.
Measuring Drift: What to Track
Before drift can be managed, it must be measured. The relevant metrics for a continuous SBOM program are:
Component Delta
The difference between components in the declared SBOM and components detected in the running system. This can be expressed as:
- Added components — present in production but not in the SBOM
- Removed components — in the SBOM but not present in production
- Version drift — component present in both but at different versions
Drift Age
How long has the production system been diverged from the declared SBOM? An SBOM that was accurate 24 hours ago carries a very different risk profile than one that has not been regenerated in 90 days. Setting a maximum acceptable drift age — analogous to a certificate expiration — is a useful operational policy.
Security-Relevant Drift
Not all drift is equal. A version change in a logging library is less critical than a version change in a TLS library or a cryptography dependency. Security-relevant drift should be defined as any component change that: (a) introduces a new CVE, (b) modifies a security-critical component, or (c) adds a component not previously reviewed and approved.
Detection Approaches
There are three primary technical approaches to detecting SBOM drift, each with different tradeoffs in accuracy, overhead, and operational complexity:
Build-Time SBOM + Periodic Runtime Scan
The most common approach: generate an SBOM during the build pipeline, then run a separate runtime scan on a schedule (daily, weekly) and diff the outputs. Tools like Grype, Trivy, and Fossity can scan running containers or installed package databases and produce output that can be compared programmatically against the build-time SBOM.
Limitation: The detection window is the scan interval. A vulnerability introduced Monday morning may not be detected until the next scheduled scan.
eBPF-Based Runtime Observation
Extended Berkeley Packet Filter (eBPF) probes can observe which files and libraries are actually loaded by running processes. This approach identifies not just what is installed but what is actively executing — significantly narrowing the false-positive surface. Tools like Falco (with custom rules) and some commercial runtime security platforms support this approach.
Limitation: High implementation complexity. Effective for runtime call detection but does not easily produce SBOM-format output.
Immutable Infrastructure + SBOM as Deployment Gate
The architecturally cleanest solution: treat infrastructure as immutable (no changes to running containers or hosts), regenerate the SBOM on every deployment, and block deployments where the SBOM does not pass vulnerability and policy checks. This eliminates runtime drift by definition because the only path to production is through a pipeline that generates and validates the SBOM.
Limitation: Not practical for legacy environments, non-containerized workloads, or systems with emergency patch requirements.
For most organizations, a combination of immutable containers for new workloads plus periodic runtime scanning for legacy systems provides the best coverage with manageable overhead. Aim for a maximum drift age of 7 days for production systems handling sensitive data.
SBOM Drift and Compliance Obligations
The gap between declared and actual components is not merely a technical problem — it is a compliance problem under multiple regulatory frameworks:
| Framework | Relevant Requirement | Drift Implication |
|---|---|---|
| OMB M-26-05 Tier 1 | SBOM must reflect deployed software | Drifted SBOM provided to agency = false attestation risk |
| EU CRA | Technical documentation must reflect product as placed on market and updated | Post-update drift without documentation update = non-compliance |
| FDA Cyber Device | SBOM must be maintained and updated for the device lifecycle | Undocumented component changes = regulatory finding during audit |
| PCI DSS 4.0 | Maintain a complete inventory of system components | Unapproved runtime components violate inventory accuracy requirements |
Building a Continuous SBOM Program
Addressing SBOM drift requires moving from a point-in-time SBOM generation model to a continuous one. The key elements of a continuous SBOM program are:
- SBOM generation in CI/CD — every build produces an updated SBOM, signed and stored with the artifact
- SBOM as deployment artifact — the SBOM travels with the container image or deployment package
- Runtime verification — periodic or continuous comparison of declared vs. observed components
- Drift alerting — security-relevant drift triggers alerts to the security team and blocks downstream deployments
- SBOM versioning — each SBOM has a version and timestamp; historical SBOMs are retained for audit purposes
Continuous SBOM Generation and Drift Detection
Fossity integrates into CI/CD pipelines to generate SBOMs on every build and flag security-relevant changes between versions. Runtime comparison capabilities identify drift between declared and deployed components, with configurable alerting thresholds for high-severity changes.
Detect Drift with Fossity →The Organizational Challenge
The hardest part of eliminating SBOM drift is not technical — it is organizational. Drift accumulates because teams make changes outside of normal release processes: emergency patches, configuration management automation, base image updates that the application team does not own.
Solving this requires establishing clear ownership of the production software inventory, defining and enforcing change management processes that regenerate SBOMs on any modification, and creating feedback loops that make drift visible to the teams responsible for it.
For organizations pursuing compliance under any of the frameworks listed above, the practical message is simple: an SBOM program that generates documents at build time and never validates them against production is a compliance program that will fail under audit. Continuous validation is not optional — it is the point.