Knowing what you actually shipped

Two provenance questions, one answerable

When something goes wrong, you want to know where the code came from. That splits into two questions with very different answers.

Which third-party components are in this artefact, at which exact versions? Answerable, mechanically, today.

Which lines were generated, and from what? Not answerable, and unlikely to become so. Take the second one off the table first, so that nobody spends a quarter building a system that cannot work.

Why generated-code provenance is not a real control

There is no watermark in code. A watermark relies on steering a choice among many equivalent outputs, and code has hard constraints (it must compile, it must pass tests) that strip the redundancy the signal would live in. Reformatting or renaming a variable destroys whatever was left.

Detectors that claim to identify generated code do not work reliably, and their failures are not random: they misfire on clean, conventional, well-commented code, which describes the work of careful engineers and of people writing in a second language. Using one to police contributions punishes the wrong people.

So if you need a record of what was generated, the only honest mechanism is a declaration by the author, in the commit or the pull request. That is a process, maintained by cooperation, and it is what several organisations have adopted. It is weak. It is also the only thing on offer.

The inventory question, which is solvable

A software bill of materials is a list of everything in your artefact with versions and licences. Two formats are in wide use: SPDX and CycloneDX.

syft dir:. -o cyclonedx-json > sbom.json   # produce the inventory
grype sbom:sbom.json                        # check it against advisories

Both tools are free and open source. Generating one takes seconds and can run on every build.

Why it matters more now: dependencies get added per unit of human attention, and human attention did not increase. When a serious advisory lands, the pattern established by Log4Shell, the only question that matters in the first hour is whether you are affected, and the difference between answering in ten minutes and three days is entirely whether you kept an inventory.

Pinning, which is the part people skip

An inventory of what you intended to install is worth little if the build resolves something else.

• Lockfiles committed, and npm ci rather than npm install in CI.
• pip install --require-hashes -r requirements.txt, which refuses anything whose hash differs.
• Container images referenced by digest (sha256:...), not by a mutable tag. :latest means “whatever was pushed most recently by anyone who can push”.
• Actions and CI steps pinned to a commit, not a moving tag. A compromised tag on a popular action reaches thousands of pipelines in minutes, which has happened.

Signing and build provenance

The layer above inventory answers: was this artefact built from the source it claims, by the pipeline it claims?

cosign, part of the Sigstore project, signs artefacts using short-lived certificates tied to an identity, so there is no long-lived private key to steal. SLSA is a framework of levels describing how tamper-resistant a build is, from “there are build records” up to “builds are hermetic and independently verifiable”. Major CI providers can now emit signed provenance attestations for what they built.

The practical starting point for a small team is modest and still worth doing: sign your container images, verify signatures at deploy, and keep the build logs.

The honest limitations

An SBOM is an inventory, not an assessment. It tells you what is present. It says nothing about whether it is safe, correctly configured, or actually reachable in your code path. Most organisations that produce SBOMs never query them, and an unqueried inventory is a compliance artefact rather than a control.

Inventories are incomplete in practice. Vendored source copied into the repository, statically linked binaries, a script fetched by curl in a Dockerfile: none of these reliably appear.

Signing proves origin, not quality. A signed artefact built from compromised source is a correctly signed compromised artefact. The signature narrows who could have produced this, which is useful and much narrower than this is safe.

The purpose of all of this is to make one question answerable quickly on a bad morning: what is in the thing we are running. It is not a security control. It is the thing that makes security controls actionable.