NIST SSDF (SP 800-218) Evidence: Build-Side Provenance In The Signed Receipt

The NIST Secure Software Development Framework, SP 800-218, defines the practices a producer follows to build software securely and the evidence the producer keeps to show it did. Several SSDF practices ask for an artefact-level record: which build produced this, what was in it, what scans ran, who authored the change.

Asqav binds those artefacts into the same signed, tamper-evident receipt that already carries what an agent did and what the policy decided.

What this page maps: the SSDF practice groups that touch build-side records, against the Asqav supply-chain wire fields and the code-authorship receipt, all already shipping in production.

Where the line sits: Asqav is the evidence layer. It signs the digests and pointers the producer asserts. It does not run the build, parse the SBOM, or re-run the scan.

The build-provenance fields

Asqav carries optional supply-chain fields on POST /api/v1/agents/{id}/sign:

executable_hash (string, sha256:<64 lowercase hex>): SHA-256 of the executable that invoked the action. Identifies a specific build artefact.
sbom_digest (string, sha256:<64 lowercase hex>): SHA-256 of the canonical CycloneDX or SPDX SBOM document covering the executing image. Identifies the dependency surface.
slsa_provenance_pointer (string, https URL): URL to the SLSA attestation envelope for the executing build.
cve_inventory_digest (string, sha256:<64 lowercase hex>): SHA-256 over the canonical-JSON CVE inventory in effect at sign time. Separates known-at-sign-time from disclosed-later.
sarif_digest (string, sha256:<64 lowercase hex>): SHA-256 over the producer-declared canonical SARIF scan bytes. A shape-only existence proof: Asqav never parses, fetches, re-runs, or validates the scan.

All are optional on the wire and none is mandatory on any receipt_type. The cloud accepts each independently. A producer populates whichever fields its pipeline emits. Each field is published on /.well-known/governance.json and specified in draft-marques-asqav-compliance-receipts on the IETF Datatracker.

Mapping SSDF practices to Asqav

PS.2 and PS.3: Provide a mechanism for verifying integrity, and archive and protect each release

SSDF practice PS.2 asks the producer to let consumers verify software integrity. PS.3 asks the producer to archive and protect each release plus the provenance data for it. Asqav binds the integrity anchors into a signed record:

executable_hash pins the exact build artefact behind the action.
sbom_digest pins the dependency surface of that artefact.
slsa_provenance_pointer recovers the SLSA attestation envelope so the consumer can trace the artefact to its source and builder.
ML-DSA-65 (NIST FIPS 204) signatures over the envelope make the archived provenance tamper-evident. The verify key is at GET /.well-known/jwks.json, published independently of the producer.

PW.7 and PW.8: Review and analyse code, and test executable code

SSDF practices PW.7 and PW.8 ask the producer to review and analyse code and to test executable code for vulnerabilities, keeping the results. Static analysis emits SARIF. The inventory of known vulnerabilities is the CVE feed:

sarif_digest binds the producer's static-analysis output into the receipt as an existence proof. The producer runs the scanner. Asqav signs the digest of the result, so the claim "this scan ran against this build" cannot be back-dated.
cve_inventory_digest binds the CVE-feed snapshot in effect at signing. The question "did we sign anything under a vulnerable dependency version?" becomes a record an auditor reconstructs, not a memory test.

Asqav does not parse or re-run the scan. The producer owns the scanner and the verdict. Asqav anchors the verdict's digest into a record the producer cannot later edit.

RV.1: Identify and confirm vulnerabilities on an ongoing basis

SSDF practice RV.1 asks the producer to identify and confirm vulnerabilities over the lifetime of the software. cve_inventory_digest carries the sign-time snapshot, so when a CVE is disclosed later, the auditor can separate "we knew and signed anyway" from "this was disclosed after we signed". The digest is the dividing line.

PO.3 and code authorship: AI-written code provenance

As AI coding agents author more of the codebase, SSDF's people-and-process practices need a record of who, or what, produced a change. Asqav ships a dedicated receipt type:

protectmcp:lifecycle:code_authorship: a signed receipt that records an authoring event for a code change, including the supply-chain digests above where the pipeline emits them. It binds AI-authored code provenance into the same chain as the build and scan evidence.

The Code-Authorship Receipts page documents the field set and the GitHub Action that emits the receipt from a pipeline.

What Asqav does not do

Asqav is not a build system, an SBOM generator, a SARIF scanner, or a CVE service. It does not generate the executable, produce the SBOM, run the static analysis, or maintain the vulnerability feed. It signs the digests and pointers the producer supplies and preserves them inside a tamper-evident envelope. The semantic claims (this hash is the real binary, this SARIF is the real scan) are the producer's. Asqav signs the bytes. SSDF conformance is a producer-process assessment. Asqav supplies the artefact-level evidence that assessment reads.