The component list in an SBOM should be identical across runs on the same commit and inputs, even when the file bytes differ. Serial numbers and timestamps are expected to change. If component names, versions or relationships change, something in your build is not pinned or your tool is not deterministic.
Two kinds of difference
When you generate an SBOM twice and diff the files, you will usually see changes. Some are fine and some are warnings.
| Difference | Normal? | Why |
|---|---|---|
| Document serial number | Yes | CycloneDX says every BOM generated should have a unique serial number, even if the contents have not changed |
| Creation timestamp | Yes | It records when the file was made |
| Order of components | Usually harmless | Sorting is not guaranteed unless the tool promises it |
| A component appears or disappears | No | Inputs or tool behaviour changed |
| A version differs | No | A range was resolved to a new release |
| A relationship differs | No | The resolved graph changed |
So a raw text diff of two SBOMs is the wrong test. Compare the set of components and relationships, not the file hash.
Why a component list drifts
Drift almost always traces to one of four causes.
- No lockfile. A range such as "any 2.x" resolves to whatever is newest on the day you build.
- Floating base images. A tag such as "latest" points at different content next week, so OS packages change.
- Network lookups in the tool. Some generators fetch metadata live, so a registry outage or change alters the output.
- Non-deterministic traversal. A tool that walks files in an unstable order can drop a duplicate differently on each run.
The first two are about your build, and they are worth fixing even if you never produce an SBOM. The npm documentation describes the lockfile as the thing that lets later installs produce identical trees regardless of intermediate dependency updates. The Python packaging guidance on repeatable installs makes the same case for pinning versions and, beyond that, for hash checking.
A repeatability test you can run today
- Check out one commit and build twice on a clean machine.
- Generate an SBOM after each build.
- Extract name, version and package identifier for every component into a sorted file.
- Diff the two sorted files. The goal is an empty diff.
- Repeat after a day, without touching the code. A new diff now points at a floating input.
For container images, pin the base image by digest for this test, then repeat with the tag to see how much a floating tag moves.
Should the timestamp be fixed?
Some teams want byte for byte reproducible SBOMs so that the file itself can be hashed and compared. The reproducible builds community defines a standard environment variable, SOURCE_DATE_EPOCH, that tools can read to avoid embedding the current time. Whether a given generator honours it is something to ask, not assume. If you need byte stable files, test for it. If you only need a stable component list, the set comparison above is enough.
What to record
Alongside each SBOM, keep the commit, the tool name and version, and the build identifier. Then two SBOMs that disagree can be explained by a changed input rather than argued about.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation work from your project files, and the free scan at gold.safeguard.sh/scan is a quick way to see the component list for a commit before you run the repeatability test on your own pipeline.
Quick check
Should two SBOMs from the same commit have the same serial number?
No. CycloneDX expects a unique serial number for every BOM generated, even if the contents are unchanged. Compare components, not identifiers of the document.
What is the fastest fix for drifting versions?
Commit a lockfile and pin base images by digest. Most drift comes from floating inputs, not from the generator.
Sources
- CycloneDX 1.6 JSON reference, serialNumber
- pip, repeatable installs
- npm, package-lock.json
- reproducible-builds.org, SOURCE_DATE_EPOCH
Last reviewed: 19 October 2026.
