s0sta
EN NL عربي
Filters
How to search
  • Plain words find names, texts and examples.
  • "two words" finds the exact phrase.
  • --name or -x finds an option.
  • #word looks only inside commands.
  • @grep finds lessons and labs that use grep.
  • Filters: cat:network · in:labs · in:notes · level:rhcsa · ch:8 · root:yes. Put ! before a word to leave it out. OR between words means one of them.
  • ↑ ↓ to move · Enter to open · Esc to close · / to search

Supply chain & SBOMPythonSec series

SBOM vs lockfile

A security review asks what is in the release and what will be installed on the next deploy. Those are two different documents, and teams routinely answer both with whichever file they have open.

Quick reference

SBOMLOCKFILE
What it listsEvery component installedEvery dependency resolved
Made byA scan of the buildA resolve of the manifest
CoversOS and language packagesLanguage packages only
IntegrityDigest of the artefactHash of each package
Changes whenThe build changesThe manifest changes
AnswersWhat shipped?What will install?

SBOM (What is installed): An inventory of the artefact that was built, down to the OS packages.

syft dir:. -o cyclonedx-json

LOCKFILE (What will install): The resolved graph a package manager will reproduce on the next install.

Example: pip-sync requirements.txt

  • SBOM → evidence of the build.
  • Lockfile → a promise before the build.

Explained

The two files

An SBOM is generated after the artefact exists. It lists every component that went into the image, including OS packages the language resolver never saw, and it is tied to the image digest. It is evidence of what shipped.

The lockfile

A lockfile is generated before the artefact exists. The resolver walks the manifest, picks one version for every dependency, records a hash and freezes the graph. The next install reproduces that graph exactly, which is a promise about the future, not a record of the past.

Where they meet

The lockfile covers language packages. The SBOM covers those plus the base image, the OS libraries and anything copied in at build time. A lockfile can be clean while the image carries a vulnerable OpenSSL, because the base image is outside its view. An SBOM names that OpenSSL; the lockfile keeps the next install honest. You need both, and you need them tied to the same build. The SBOM changes when the build changes; the lockfile changes when someone re-resolves it.

The honest caveat: a lockfile proves what the resolver chose, not that the choice was safe or current, and an SBOM proves what was present, not that it was the only path into the image.

The lesson: the lockfile is a promise, the SBOM is evidence, and the release needs both.

Evidence of the build, promise before it.

More notes: Supply chain & SBOM

Open in the notes app: search, filters, copy This note on GitHub