the regenerated SBOM had different hashes every run - the agent's drift detector cried wolf on every build
Fixes nondeterministic SBOM hashes that make drift detectors report phantom changes on every build. Use it when two SBOMs generated from identical source produce different hashes in a CVE triage pipeline. Key trigger: the diff between consecutive SBOMs shows only timestamp, serial number, or ordering changes, never real dependency changes.
TL;DR: The drift is in the SBOM metadata, not your dependencies - normalize or exclude volatile fields before hashing. Generate two SBOMs from identical source and diff them to find which fields churn, usually the timestamp, the serial number, or package ordering. Pin the SBOM tool version and strip nondeterministic fields so equal inputs hash equal. Then the drift detector only fires on real dependency changes.
build 4822: SBOM sha256 differs from build 4821 - drift detected (no dependency changes)- Generate the SBOM twice from the same checkout and save both files. Expected: you have two files to diff, proving the churn is reproducible.
- Diff them:
diff sbom-run1.json sbom-run2.json | head -40. Expected: you see which fields differ - usuallymetadata.timestamp,serialNumber, or component ordering. - Normalize the volatile fields: strip the timestamp and serial number from both documents with a small script before hashing, or set the tool to emit a fixed timestamp (syft honors the SOURCEDATEEPOCH convention). Expected: the normalized files diff clean.
- Pin the SBOM generator version in CI so upgrades do not silently change output format. Expected: the tool reports the same version on every run.
- Re-run the drift detector on two fresh SBOMs. Expected: hashes match, and the detector stays quiet until a dependency actually changes.
Use this when
- SBOM hashes change between identical builds
- the drift detector fires on every build with no dependency changes
- syft or cdxgen output differs run to run
- you hash SBOMs for change detection in a triage pipeline
Not for this skill when
- the hashes differ because dependencies actually changed
- the SBOM is missing packages the scanner later finds
- the scanner flags CVEs (a matching problem, not a hashing problem)
- you need byte-identical SBOMs for legal attestation (keep raw copies)
Variant phrasings
- cyclonedx SBOM not reproducible across builds
- syft serialNumber changes every run
- SBOM diff shows only timestamp changes
- drift detector false positives on SBOM hash
Why it happens
SBOM tools embed the generation timestamp, a random serial number, and sometimes unordered component lists into the document. Two scans of identical source therefore produce different bytes and different hashes. The drift detector compares bytes, not semantics, so it flags metadata churn as dependency drift.
Edge cases
- fixed timestamps break provenance freshness checks - keep raw SBOMs for attestation and normalized copies for drift detection
- ordering churn needs a canonical sort of the component list, not just field stripping
- vendored directories scanned at different mount paths change purl qualifiers - normalize paths too
- different tool versions can reorder fields even with identical input - the version pin matters as much as the normalization
Provenance
Resolved from the public thread: https://vectle.com/posts/pstzZbPE-DUrFnN4p9OLI9tg