Status: Accepted (2026-07-13)
Date: 2026-07-13
Decision: SemVer-Trust consumes SLSA Source and similar source-control evidence through explicit source evidence profiles. A profile MUST bind repository identity, source-revision subject matching, digest algorithms, source-control/VSA issuer authorization, verification mode (replay or trusted_issuer), clock/freshness semantics, and any current-state or transparency mechanism required to detect hidden successors, demotions, or equivocation. SLSA Source facts may supply stable repository identity, immutable revision identity, protected-reference membership, history continuity, contemporaneous source provenance, and final-revision/final-diff review evidence. SemVer-Trust remains responsible for canonical actor mapping, accountable-human counting, agent-independence semantics, scope flooring, propagation, compatibility and blast policy, release intervals, policy transition, authenticated version ancestry, and supersession continuity.
Rationale: SLSA Source v1.2 defines interoperable Source Verification Summary Attestations and source-track requirements, while leaving detailed source provenance formats to source-control systems. That division matches SemVer-Trust’s needs: stable repository and source-control facts should be reused instead of redefined, but a VSA is still a summary from an issuer. Consumers either replay the underlying source provenance or explicitly trust the issuer for the summarized facts. Treating a signed summary as proof of every underlying fact would overclaim what signatures establish. Repository/resource and subject matching are load-bearing because a valid source attestation for one repository or revision must never be replayed into another SemVer-Trust release chain.
Rejected: mapping SLSA Source levels directly to T-levels (SLSA source levels describe source-control process controls, while T-levels count accountable humans under SemVer-Trust semantics); requiring SLSA Source for baseline SemVer-Trust verification (would exclude repositories without SLSA Source infrastructure); accepting any signed VSA without profile-bound issuer authorization and subject/resource matching (replay and confused-deputy risk); changing the emitted release/v0.2 closed schema to add required top-level source-evidence fields (first signed v0.2 bytes have emitted, so such a wire change requires a new predicate URI).
Primary references: SLSA Source requirements (https://slsa.dev/spec/v1.2/source-requirements), SLSA Source verification (https://slsa.dev/spec/v1.2/verifying-source), and SLSA Verified Properties (https://slsa.dev/spec/v1.2/verified-properties).
Revisit trigger: a stable SLSA source-provenance predicate emerges that can replace profile-specific provenance mappings, or SemVer-Trust defines a new release predicate URI with first-class source-evidence fields.