Summary

  • SLSA v1.2 describes provenance as evidence that must be inspected against a verifier’s expectations; an attestation does not act by itself.
  • The specification distinguishes an artifact-bound provenance statement from roots of trust, package-name expectations and the acceptance or response process chosen by an ecosystem, consumer or monitor.
  • A small expectation-and-response receipt can prevent a valid-looking attestation from being misread as a universal release approval, without inventing a new SLSA requirement.

An attestation answers a narrow question

SLSA’s current build-provenance model is deliberately concrete. A provenance attestation says that a particular build platform produced one or more software artifacts through a named buildDefinition. It can identify the subject artifact by digest, identify a builder, describe a build type and record parameters and dependencies in the form the specification defines. This is evidence with real operational value: it lets a consumer compare what was built with what the consumer expected, and it can help another party reproduce or investigate the build.

The narrowness is the strength. An attestation need not be treated as a vague badge attached to a project name. It can be examined in relation to an exact artifact. SLSA’s distribution guidance is especially clear that attestations should be bound to artifacts rather than releases. One release can contain artifacts for several platforms, architectures and environments; builds may occur days apart; additional artifacts and attestations may be added later. A release label therefore cannot silently supply the exact artifact relationship that the attestation already makes explicit.

That evidence is not self-executing. SLSA’s verification guidance says provenance does nothing unless somebody inspects it. The implication is not that provenance is weak or optional. It is that a statement, its evaluation criteria and a decision based on that evaluation are different control surfaces. Confusing them makes an otherwise auditable supply-chain record sound like a blanket safety or acceptance guarantee it does not provide.

Evidence is not the verifier’s expectation

Before a verifier can judge an attestation, it needs a basis for judgment. SLSA directs a verifier to configure roots of trust: recognized builder identities and the SLSA Build level each identity is trusted to meet. It then calls for a signature check, a comparison between the artifact digest and the provenance subject, and verification of the expected buildType and externalParameters.

Those expectations do not arrive automatically because an artifact carries a well-formed attestation. SLSA explicitly allows different verifiers to use different roots of trust. It also distinguishes expectations tied to a package name from provenance tied to an artifact. A package ecosystem may bind a name to a canonical source repository. A consumer may use its own rules. A producer may offer expectations through an authenticated mechanism. A trust-on-first-use model may compare later provenance against the first accepted state. Each model answers a governance question that the attestation alone cannot settle: which values are allowed for this package in this context?

This distinction is most visible in externalParameters. In the provenance model, they are under external control; the build platform records them, and they are meant to be checked downstream. Their presence is not a declaration that every value is acceptable. A verifier should know which values are expected and should reject unrecognized parameters rather than assume that a signed envelope has converted a new input into an approved one.

The same restraint applies to builder.id. A signature can help establish that a particular trusted control plane issued a statement. It does not compel every ecosystem or buyer to place that builder in its roots of trust. SLSA itself notes that Build L3 does not cover compromise of the build platform by a malicious insider and says verifiers should consider their build-platform choices carefully. Authenticity is evidence about the statement and its issuer; trust remains a decision about who is allowed to make statements that matter in a given policy.

The acceptance point has an owner

SLSA lists several valid places to perform verification. A package ecosystem can verify at upload. A consumer can verify at download or before use. A monitor can verify a chosen set of packages and publish results. These locations can coexist. The specification recommends ecosystem verification where possible because it can benefit clients, while also recognizing that consumer-side verification may provide defense in depth.

None of those locations is a mere implementation detail. They allocate authority. Upload verification can decide whether a registry accepts a package. Consumer verification can decide whether a particular environment installs or deploys it. A monitor can detect and publish a mismatch, but SLSA notes that detection has limited value unless a human or automated system takes action. The same artifact can therefore be accepted by one policy, rejected by another, or observed by a monitor while awaiting a response. That is not inconsistency in provenance; it is the normal consequence of distinct decision owners.

The release boundary should remain equally plain. The distribution specification says maintainers can elevate build attestations by publishing them alongside an artifact, and that the goal is to give a repository evidence needed to verify a potential policy requiring a SLSA level for publication. The evidence is necessary for that policy to operate; it is not the policy, its enforcement setting or the audit record of an actual acceptance.

A public page that says only “SLSA provenance available” therefore makes a narrow, useful claim. It should not be inflated into “this release is accepted everywhere,” “this package satisfies every consumer’s policy,” or “a failure will trigger a particular remediation.” Each of those statements requires an additional actor, a named rule and a scope.

Use an expectation-and-response receipt

The smallest useful operational addition is an expectation-and-response receipt. It is not a new attestation format and not an amendment to SLSA. It is a compact record a package ecosystem, consumer or monitor can keep next to its verification decision.

The receipt should name the artifact digest and the provenance reference; the verifier and the relevant policy version; the root-of-trust entry actually used; the expected canonical source, buildType and permitted external-parameter boundary; the time of evaluation; the result; and the owner of the next action. If the result is a failure, it should say whether the artifact was rejected, quarantined, alerted on, allowed under an exception or left pending—and who can change that state. If an expectation changes, the receipt should link the authorized change rather than quietly rewriting the history of the comparison.

This is intentionally less grand than a universal “trusted release” claim. It does not pronounce an artifact safe, prove every dependency complete, promise a response time or turn a monitor into a gatekeeper. It does make a later review possible. A team can distinguish an authentic statement from an approved artifact; a policy change from a signature rotation; an ecosystem’s upload decision from a consumer’s deployment decision; and a detected mismatch from a completed remediation.

Preserve the boundary, preserve choice

Heng Lu’s discipline is relevant as a method, not as SLSA evidence: a coordination record should make its limited authority visible rather than declare an unadopted reality into existence. SLSA already works this way. It tells producers and platforms how provenance can be generated and distributed, and it tells verifiers what they must compare. It does not erase the separate choices about who trusts whom, which package values are expected, or what action follows a mismatch.

Keeping those choices explicit protects all sides. Producers can make a bounded claim about the artifact and build they can evidence. Ecosystems can publish their policy without pretending it applies to every consumer. Consumers can add narrower or stronger rules without falsifying the producer’s provenance. Monitors can report failures without claiming they have remediated them.

The costly shortcut is to turn one machine-readable statement into a composite promise: authentic build, approved package, finished release and effective response. That shortcut is difficult to unwind when a root of trust changes, a package is republished for a new architecture, a policy exception expires or a monitor detects a discrepancy. The receipt does not add bureaucracy for its own sake. It keeps the evidence, the expectation and the decision separately legible while still allowing them to work together.

Sources

  1. SLSA v1.2 — Build: Verifying artifacts
  2. SLSA v1.2 — Build: Provenance
  3. SLSA v1.2 — Build: Distributing provenance