Your model registry requires a signature, an SBOM and provenance per checkpoint: which risks does that still leave open?

## Where this question comes from An ML platform team is asked by a risk committee to make published model checkpoints accountable. The team lands on a sensible rule: every checkpoint in the registry must carry a signature, a dependency inventory and a build provenance statement, all verified. That is a genuinely strong position - and a senior engineer is expected to be able to say precisely what it still does not cover, because the committee will assume it covers everything. ## What the three claims do settle - **Signature**: these bytes are unchanged since signing, and a specific identity vouched for them. - **Inventory (SBOM)**: this is the set of components and versions the artifact is composed of. - **Provenance**: this artifact was produced by a named builder, from a named source repository and revision, via a named entry point. Who, what, how. Together they make the checkpoint describable and attributable, which is most of what an audit trail needs. ## Gap 1 - identity is not trust, and presence is not verification A signature answers *who*, and the answer is only useful against a policy that says which answers are acceptable. "Signed" without "signed by an identity on our allowed list, for this repository" is a fact with no decision attached. The failure mode is subtle: an artifact signed by *some* valid identity passes a naive check, and the registry has effectively accepted anyone who can obtain a signing identity. The stronger version of this gap is that many pipelines *produce* evidence without anyone *consuming* it. If the registry stores an attestation and nothing rejects an artifact whose attestation is missing, unverifiable or issued by an unexpected signer, the requirement is documentation rather than a control. ## Gap 2 - provenance is about the build, not about the source Verified provenance says the build faithfully consumed revision X. It does not say: - that revision X was reviewed by a second person, or reached the branch through your review process; - that the training code, the dataset selection or the evaluation harness at that revision was sound; - that the person who pushed revision X should have been able to. This is not an oversight in the design. SLSA v1.0 organises requirements into tracks, and its Build track - levels L0 to L3 - is about how trustworthy the build platform's account of its own execution is, not about what happened before the commit. Source-side expectations live outside that track. So a fine-tuning engineer with legitimate commit access who changes what the training entry point loads produces a checkpoint with impeccable, truthful provenance. The provenance faithfully records the compromise. ## Gap 3 - an inventory lists components, not consequences The registry now knows the checkpoint's serving image contains library L at version V. Whether that matters is a separate chain of reasoning: does an advisory apply to V, is the vulnerable code path present in this build, is it reachable from any input this service accepts, is there an exploitable route to it. An inventory feeds that analysis and does not perform it. Answering "we ship it but it is not affected, and here is why" is what an exploitability statement such as VEX exists to carry, and producing one is analysis work, not a document your build emits for free. There is also a scope trap specific to models: an inventory of software dependencies says nothing about the training data - its lineage, its licensing, whether it contained material it should not have. If the committee's real worry is data provenance, none of the three documents addresses it, and a distinct attestation would have to. ## Gap 4 - binding and the moment of enforcement All three claims attach to a digest. The security value therefore depends entirely on whether the thing consumed is the thing attested: - If a serving job pulls a checkpoint by a mutable name and the attestations were issued about a digest nobody re-checks at load time, the chain breaks at the last step. - If verification happens only in the publishing pipeline, an artifact that reaches the registry by another route - a manual upload, a copied file - carries no such guarantee. The verification point matters more than the document count. One claim checked at the moment of use is worth more than three claims checked nowhere. ## How to answer the committee Reframe the question. The three claims answer *who, what and how*, and are the right evidence for attribution and recall. Whether a model is *safe* is a judgment produced by evaluation, review of the training code, and data governance - and the evidence chain's job is to guarantee that the thing you evaluated is the thing you shipped. Said that way, the gaps stop looking like failures of the scheme and start looking like the adjacent programmes that still need owners. ## What a weak answer sounds like Listing the three documents again, or claiming that adding a fourth attestation type closes the gap. The insight being tested is that evidence answers descriptive questions, while trust policy, source-side control, exploitability analysis and enforcement at the point of use are separate things that must each be owned.