Why does an SBOM built from a project's lockfile differ from one built by scanning the shipped image?

### What a vantage point is An SBOM (Software Bill of Materials) is a list of the components inside an artifact. It is not discovered by magic: some process stands at a particular point in the software's life, looks at whatever evidence is available there, and writes down what it can see. That standing point is the *vantage*, and it is the single biggest determinant of what ends up in the document — bigger than the format you chose, bigger than which generator you ran. There are four vantages worth naming. **1. Manifest and lockfile parsing (pre-build).** The generator reads declaration files: the manifest that says what you asked for, and the lockfile that says what the resolver settled on. This is cheap, needs no build, and yields exact versions plus integrity hashes because a lockfile exists precisely to pin them. Its shape is also its limit: it covers exactly one ecosystem's declarations. Operating-system packages in the base image are not declared there. Native libraries linked by a compiler are not declared there. Development and test dependencies *are* declared there and will appear even though they never reach production. And anything copied into the repository by hand is, by definition, not a declaration. **2. Build-time generation.** The generator runs inside the build, with access to the fully resolved dependency graph as the build system actually used it, before that graph is flattened into an opaque artifact. This is the highest-fidelity vantage for the application half: it knows the graph, it knows direct versus transitive, and it can be tied to the exact build that produced the exact artifact. Its cost is reach — you must touch every build, and for anything you do not build yourself you cannot stand here at all. **3. Filesystem and binary analysis of the built artifact (post-build).** The generator opens the image layers, the archive, or the binary and infers components from evidence: OS package databases, embedded manifests inside packaged archives, file names, and version strings. This is the vantage that sees what *actually ships*, including the base image, and it works on artifacts you did not build. But identification here is inference, not declaration. Where evidence is thin, the component silently does not appear. **4. Runtime observation.** Watch a running process and record what it actually loads and opens. This tells you what is live rather than what is present, which is genuinely useful for prioritisation, but it structurally undercounts: a code path never exercised during the observation window looks like it is not there, and by definition you only get this after deployment, which is too late to be the document you ship with the release. ### Why the two documents in the question disagree Put a concrete case beside it. A Python model-training service is built in a multi-stage container build: the builder stage installs a compiler toolchain and downloads wheels; the final stage copies in only the installed package tree and the application code. - The lockfile SBOM lists every Python package the resolver chose, including the test-only ones, and nothing else. - The image SBOM lists the base image's OS packages, plus the Python packages it can still find records for in the final layers, and *not* the compilers — because those stayed in the builder stage and were never copied forward. - A build-time SBOM taken in the builder stage would list the compilers, which is accurate for that stage and misleading as a description of what you deployed. None of these is a bug. Each is a faithful report from where it stood. ### What to do with that First, know which vantage produced any document you are handed, and read its blind spots off that fact rather than trusting the component count. Both major SBOM formats carry creation metadata naming what produced the document, and a mature process records the vantage explicitly. Second, treat vantages as complementary rather than competing. The common production pairing is build-time generation for the application dependency graph plus artifact analysis for the OS and packaged layers, merged and attached to the release. Runtime observation is a prioritisation input on top, not a replacement. Third, expect the counts to differ and be able to explain the difference. "The lockfile document has 340 entries and the image document has 190" is not evidence of a broken generator — it is dev dependencies plus a multi-stage build behaving exactly as designed.