What does provenance add beyond signing, and what makes it usable rather than ceremonial?

What provenance adds beyond signing

A signature proves an artefact came from someone holding a key. Provenance proves how it was produced — the source commit, the build definition, the builder identity, the dependency set with hashes — attested and signed.

The distinction matters because the realistic threat is not a forged signature. It is a legitimately signed artefact containing code that is in no repository, inserted by a compromised builder or a compromised dependency.

What makes it usable rather than ceremonial

1. Verification at consumption, automatically. Provenance that nobody checks is documentation. The deployment path should refuse an artefact whose attestation does not match policy — built from an approved repository, by an approved builder, from a reviewed commit.

2. The signing key unreachable from build code. If the build can access the key, compromising the build compromises signing, and the two controls collapse into one.

3. Dependencies pinned with verified hashes, fetched from an internal mirror rather than the public internet at build time — which closes dependency confusion and upstream substitution.

4. A release inventory that is queryable. "Which releases contain this dependency version" must take minutes. This is the question asked when a vulnerability is announced, under time pressure, and it is the most frequently used product of the whole apparatus.

5. Reproducibility, at least partially. Being able to build the same source and compare is the only independent check that the artefact corresponds to the code.

The organisational controls that matter as much

• Two-person review for build and release infrastructure, held to a higher standard than application code, because it is a higher-value target.
• Separation of duties between committing and releasing.
• A tested emergency revocation and update path, because the response to a compromised release is a race and the mechanism must exist beforehand.

The uncomfortable test

"If our build system were compromised today, how long until we noticed, and which artefacts are affected?" For most organisations both answers are unsatisfactory — and both are addressable with verification and inventory, in advance.