ML Supply Chain Security advanced 7 min read 12 flashcards

Signing, Attestation and SBOMs for Models

How software supply chain frameworks map onto model artefacts, what a model bill of materials should contain, and why the interesting claims are about the training process rather than the file.

Software supply chain security converged on a pattern: sign artefacts, attest to how they were built, and enumerate what went into them. Each part maps onto models with a twist, and the twist is that the interesting properties of a model are properties of a process that cannot be re-executed cheaply.

Signing

Signing a model file establishes that a named party published these exact bytes and that they have not changed since. It is straightforward, it uses the same tooling as container signing, and keyless signing with short-lived certificates tied to an identity provider removes the key management burden that stopped adoption previously.

What it establishes is integrity and origin. It says nothing about whether the model is safe, unbackdoored, or trained on data the publisher had rights to.

Attestation

An attestation is a signed statement about how an artefact was produced: which builder, which source revision, which inputs, in what environment. The SLSA framework formalises levels of assurance, with the higher levels requiring that the build run on a hardened, hosted builder that generates the attestation itself, so the claim does not depend on the publisher's honesty about their own process.

For models this maps onto the training pipeline. An attestation can bind a model artefact to a training job, a dataset version, a code revision and a container image. It is genuinely useful for reproducibility and for incident response, and it is weaker than the software case because re-running the build to verify is prohibitively expensive and, given non-determinism, does not produce identical bytes anyway.

That gap matters. In software, an independent rebuild can verify an attestation. For a large model, nobody is going to spend the training budget to check, so the attestation is trusted rather than verified.

Model bills of materials

An SBOM enumerates a software artefact's components. The model analogue should cover the base model and its version if the model is derived; datasets by version or content hash; the training and inference framework versions; the licences attaching to each of these; and the evaluation results and known limitations.

The value is concrete rather than bureaucratic. When a dataset is found to be contaminated or a base model is found to carry a licence restriction, the question "which of our models are affected" is answerable from the inventory in minutes rather than through archaeology.

When it breaks

Attestation does not establish safety. Every claim here is about provenance. A perfectly attested model trained on poisoned data is perfectly attested, and the attestation records exactly which poisoned dataset was used, which is useful after the fact and not preventive.

Dependency graphs are deep and partly opaque. A model fine-tuned from a base model derived from another base model requires the whole chain, and third-party links usually have no attestation at all. Coverage stops at the first opaque node, which is often the first node.

The interesting inputs resist enumeration. Listing a web-scale corpus by content is not feasible, so the entry becomes a name and a snapshot date. That is genuinely useful and it is much weaker than a software SBOM's component list, and the difference should not be papered over.

Signature checking has to be enforced. Producing signatures that nothing verifies is a common outcome. The control is the verification step in the deployment pipeline, refusing unsigned or unattested artefacts, and without it the signing infrastructure is documentation.

Check yourself

12 flashcards for this concept

Click a card to reveal the answer.

Drill the whole track