OMS model signature and other attestations #586
Description
The AI/ML supply chain security landscape involves multiple attestation types which can be represented as in-toto attestations. For example:
- OpenSSF Model Signing (OMS) Signatures help verify integrity and authenticity
- SLSA Provenance Attestations describe how the model was built
- SBOMs (Software/AI Bill of Materials) inventory the components, training datasets, foundation models, and dependencies that comprise the model
All three can be represented as in-toto statements with different predicates, wrapped in a sigstore bundle. The OMS model-signing signatures are themselves currently represented as an in-toto statement wrapped in a sigstore bundle in a single model.sig file, detached but typically co-located with the model files.
How should other attestations relate to the OMS signature? Critically, should the OMS model signature include the hash of other attestation bundle files itself?
Attestations can accumulate throughout a model's lifecycle—from training through deployment and operation. Adding new attestations (e.g., security scan results, VEX statements, post-deployment audits) after initial release is a strength we should try to preserve.
How do other attestation sigstore bundles appear in the layout of the model repository? There’s no convention or rule for how they must be named. They may appear as individual files, like model.spdx.sigstore.json, or they might all be appended to a growing jsonl file named something like model.sigstore.jsonl. (See also sigstore/cosign#4496.)
If the jsonl list convention is not used, there is no problem. New attestations can be added without breaking OMS signature validation of the model.
If the model.sigstore.jsonl list convention is used and if the hash of that file is included in the OMS signature, then any future attestations that get appended to that file will change the hash and break the integrity check of the model as a whole.
Is this desirable? A downstream consumer may want to detect that an originally present SLSA provenance attestation that was present in the model at the time of signing is no longer present. However, if a consumer cares about that particular attestation type and its signing identity, they can use a policy mechanism to require its presence, regardless of the OMS signature integrity.
Position: The model signature should NOT include the bundle file hashes of other attestations.
Position: We will NOT expand the OMS predicate to include information that can be better represented in other orthogonal attestations.
Including the other attestations’ bundle file hashes in the standalone model signature creates a rigid dependency which is especially problematic when a jsonl list of sigstore bundles is present: adding any new attestation would invalidate the original signature. By keeping attestations independent and individually signed, we preserve flexibility for multi-party, multi-phase supply chain attestation as the model moves between registries and through its lifecycle, while maintaining the original cryptographic integrity of individual claims.
Downstream consumers can guard against deleted attestations by requiring the presence of certain attestations signed by certain identities in their own policies, without relying on coverage by the OMS signature.
See #587 for an illustration of how attestations should be named and handled throughout the lifecycle of a model.
This idea was originally drafted at and received some preliminary feedback in a google doc.