Your nightly image's SBOM changes week to week with no code change - what explains it?

## The question behind the question "Did the inventory change?" is meaningless until you know **what each document describes**. An SBOM is a statement about one artifact. If you name that artifact by a mutable tag, you have not identified it — you have identified a pointer. So the first move when two documents disagree is to compare their subjects. ## Three sources of a diff **1. The subject moved.** A nightly build that starts from a floating base tag resolves that tag at build time. Upstream rebuilds the base — for a patch, or on their own cadence — and the tag now points at a different digest with a different OS package set. Your build then produces a different image with a different inventory. Nothing about your code changed; the artifact did. The tell is simple: the two SBOMs describe different digests. This is also the mundane, non-malicious version of a serious concern. If a base image can change under you unnoticed, so can its contents, and the change arrives without review. Recording the resolved digest is what makes such a change visible as a fact rather than a surprise. **2. The generator moved.** Generators ship new catalogers, refine how identifiers are constructed, and fix parsers. An upgraded generator may report components the old one could not see, split what was one entry into two, or emit a different package URL for the same package. The bits on disk are identical; the observer improved. This diff is welcome, but it must not be mistaken for a change in what you ship — and it is why the generator's name and version belong recorded alongside the document. **3. The invocation moved.** Scope is the usual culprit: a squashed view describes the final filesystem, an all-layers view also counts things a later layer removed. A run in a different working directory, or against a source checkout rather than the built image, changes the answer for the same reason. Two engineers comparing outputs while running different commands will argue for an afternoon. ## How to make SBOM diffs meaningful - **Name the subject by digest.** Record the digest of the artifact the document describes, and diff only documents whose subjects you can identify. Comparing "last week's nightly" to "this week's nightly" is comparing two different artifacts. - **Record the generator and its version** with the document, so a diff can be attributed to the observer rather than the observed. - **Fix the invocation.** One command, one scope, run the same way in every pipeline, so a difference in output means a difference in the artifact. - **Resolve the base deliberately.** If the base is referenced by a moving tag, at minimum record which digest was resolved for each build; updating that reference on purpose turns base drift into a reviewable change rather than a nightly surprise. ## Reading the diff once it is trustworthy With subject, generator and invocation controlled, a diff is genuinely informative: a new transitive dependency appeared, a base-image update replaced a set of OS packages, a component you thought you removed is still present. That is exactly the signal you wanted when you started generating SBOMs nightly — a change log of what is actually inside the thing you ship. The reason it usually is not informative in practice is that teams start diffing before they have pinned down the other two variables, drown in false positives, and stop looking. ## Common wrong answers - "Generators are non-deterministic" — component ordering can vary between runs, which is a formatting nuisance handled by sorting before diffing; it does not add or remove components. - "Something must have been compromised" — jumping to attack before checking whether the artifact simply changed wastes the team's credibility. Establish the digest first, then investigate. - "It is a scanner bug" — usually it is the input, and the fix is in how the pipeline names its inputs rather than in the tool.