This is the last of the near-neighbour readings, and the one that meets the objection the whole project turns on. Its subject is attestation: the cryptographic frameworks that certify software as it moves through a supply chain. The leading instances are in-toto, which signs the steps of a supply chain, and SLSA, which grades the integrity of a build. The word attestation is shared with this work, and the overlap is worth confronting directly. If these frameworks already attest to artefacts, do they not already do what Attestable proposes?
The finding, stated first: the claim holds, in its strongest form. These frameworks guarantee that an artefact was produced by an authorised party and not altered on the way. They say nothing about whether what was produced is true, or fit to act on. Integrity is a different property from admissibility, and the two specifications draw that line against themselves, in their own words.
What attestation establishes
An in-toto attestation is, in the specification's own phrase, authenticated metadata: a record cryptographically bound to an artefact, proving who created and signed it and that it has not since been altered (in-toto, n.d.); the framework's original design gives the same guarantee, cryptographically verifying that supply-chain steps were carried out as specified, not that their outputs are correct (Torres-Arias et al., 2019). SLSA layers grades of assurance over the build process, certifying that an artefact was built by the expected builder, from the expected source, through the expected steps. Both are precise, valuable, and widely deployed. Both certify custody and process. Neither certifies content.
The distinction is not a matter of interpretation, because each specification states it plainly. in-toto, the spec says, does not validate whether the claims it carries are factually correct; it ensures the metadata is cryptographically bound and authenticated (in-toto, n.d.). SLSA, its documentation states, makes no claims about whether produced artifacts are functionally correct, true, or fit for purpose: it concerns the integrity of the process, not the quality or correctness of the output (OpenSSF, 2023). A signed, verifiably unaltered claim may be false. The signature attests to its custody, not to its basis. Signing a hallucination yields a verified hallucination.
The objection that has to be met
The challenge here is the sharpest of the three, and it is technical. An in-toto attestation carries a component called a predicate, and the predicate may hold, in the spec's words, arbitrary metadata about a subject artifact with a type-specific schema (in-toto, n.d.). So one could define an admissibility predicate, place a claim's basis inside it, and let in-toto carry it, signed. Does that not make the framework the mechanism this work says is missing?
It does not, and the specification draws the line itself. in-toto provides an authenticated envelope for whatever predicate is placed in it. It binds the predicate to a subject, fixes its schema, and proves it was signed and unaltered. It does not define what the predicate means, and it does not verify that the predicate is true. An admissibility claim carried by in-toto would be exactly as founded, or unfounded, as it was before it was signed. The framework would certify that the claim was made by a known party and not tampered with, and would have nothing to say about whether the basis it asserts is sufficient for any action.
So the predicate confirms the division of labour rather than closing it. And the specification names the other half of that division directly: an in-toto attestation's intended consumers, it says, are automated policy engines. That is the previous reading. The two fit together, and the shape of the gap becomes exact:
- Attestation is transport: it carries a claim of basis across a boundary, authenticated and intact.
- The policy engine is the evaluator: it decides, over whatever facts and rules it is handed.
- The basis model, which is this work, supplies the vocabulary and the meaning that the transport carries and the evaluator evaluates.
Neither existing layer supplies the middle. The transport will carry a model of basis once one exists; the engine will evaluate it once it is defined. The definition is the contribution, and it is precisely what neither the envelope nor the evaluator provides.
A note on adversaries
One feature of the attestation literature is worth recording, because it explains why these frameworks cannot see the failure this work addresses. SLSA's threat model is, by its own framing, built entirely around an adversary: every threat it enumerates takes the form of an attacker introducing or tampering with something (OpenSSF, 2023). That is the native posture of supply-chain security, and it is the right posture for the threats it faces. But False Determinism has no adversary. It occurs when every party acts in good faith and every signature is valid, and a claim with no relation to its own truth is carried forward and acted upon because nothing marked its basis. A threat model organised around attackers cannot represent a failure that requires none. The frameworks are not weak here; the failure is simply outside what they were built to see.
References
in-toto (n.d.). in-toto Attestation Framework: Specification. in-toto project. github.com/in-toto/attestation
OpenSSF (2023). Supply-chain Levels for Software Artifacts (SLSA): Threat Model, v1.0. Open Source Security Foundation. slsa.dev/spec/v1.0/threats
Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R. and Cappos, J. (2019). in-toto: Providing farm-to-table guarantees for bits and bytes. Proceedings of the 28th USENIX Security Symposium, pp. 1393-1410. usenix.org · read copy