Supply Chain Provenance: Signed Artifacts You Can Verify Offline

The xz backdoor (CVE-2024-3094) was not a vulnerability in the traditional sense. It was a two-year social engineering campaign that compromised a trusted maintainer's build process, injecting malicious code into signed release tarballs that passed every automated check. The artifact was signed. The signature was valid. The provenance was a lie.

That incident exposed a blind spot in how most organizations think about supply chain security: they verify signatures without verifying the build process that produced the signed artifact. A valid signature proves the artifact was not tampered with after signing. It says nothing about whether the build environment was compromised, whether the source matched what was reviewed, or whether the builder identity was authentic.

If your provenance is only verifiable through an API call to a cloud endpoint, it is not verifiable where it matters most --- in classified environments, on air-gapped networks, at the moment an incident responder needs to determine whether a running binary matches its claimed lineage.

Why Now: EO 14028 and the Shift From SBOMs to Build Integrity

Executive Order 14028, Section 4, mandated that software producers provide evidence of secure development practices. NIST translated those requirements into SP 800-218 (SSDF). OMB M-22-18 (refined by M-23-16) operationalized them into procurement language. The industry responded with SBOMs --- and then stopped.

An SBOM tells you what components are present. It does not tell you whether those components were built from the claimed source, on a trusted platform, by an authenticated builder. CISA acknowledged this gap explicitly: its secure software development attestation form (finalized in 2024) moved beyond "produce an SBOM" to "attest to your build process integrity."

The bar is shifting from document production to cryptographic verification. FedRAMP assessments now evaluate CM-8 (Component Inventory) and SR-3/SR-4 (Supply Chain Controls and Provenance). CMMC Level 2 maps to NIST 800-171 controls addressing supply chain integrity. DFARS clauses reference supply chain risk management directly.

None of this is satisfied by a CycloneDX file sitting in a shared drive. The question assessors are now asking is not "do you have an SBOM?" but "can you prove your build integrity --- and can I verify that proof independently?"

SLSA Build Provenance

Advisedly generates SLSA v1.0 build provenance using the in-toto Statement v1 format. Every pipeline run that produces a deployable artifact --- a container image, a release tarball, an update package --- generates a provenance statement recording:

Subject: The artifact image reference and SHA-256 digest
Build definition: Build type, external parameters (repository, branch, commit), and resolved dependencies pinned to exact git commit SHAs
Run details: Builder identity, invocation ID tied to the specific pipeline run, and ISO 8601 timestamps for start and finish

Provenance generation is deterministic. Given the same inputs, it produces byte-identical JSON. This is deliberate --- provenance can be regenerated and compared without relying on the original signing infrastructure.

The output conforms to the in-toto statement specification with the SLSA provenance predicate type. These are not custom formats. They are the formats that cosign, SLSA verifiers, and the broader supply chain security ecosystem already understand.

Signing With DSSE and Ed25519

Raw provenance metadata is useful. Signed provenance metadata is trustworthy.

Advisedly signs attestations using DSSE (Dead Simple Signing Envelope) with Ed25519 signatures. DSSE defines a Pre-Authentication Encoding (PAE) that binds the payload type to the payload content before signing:

"DSSEv1" SP LEN(type) SP type SP LEN(payload) SP payload

This encoding prevents replay attacks where a valid signature from one payload type is applied to a different payload type. A signature over an in-toto provenance statement cannot be confused with a signature over a VEX document, even if the same key signed both, because the payload type is cryptographically bound into the signed data.

Ed25519 produces compact 64-byte signatures, is resistant to timing side-channel attacks, and is deterministic. The key ID is the SHA-256 fingerprint of the SPKI-encoded public key, following the convention established by cosign and the Sigstore ecosystem.

Private keys are stored in an AES-256-GCM envelope-encrypted vault with a KMS adapter cascade. They never leave the API process boundary. No shell subprocess, no runner container, and no external service ever touches the raw key material.

OpenVEX Vulnerability Dispositions

An SBOM tells you what components are in software. A CVE database tells you what vulnerabilities exist. Neither answers the question that actually matters: "Is this specific deployment affected by this specific vulnerability?"

OpenVEX answers that question with machine-readable disposition statements:

not_affected --- requires a justification (component not present, vulnerable code not in execute path, inline mitigations already exist)
affected --- the vulnerability is exploitable in this context
fixed --- a patch has been applied
under_investigation --- the honest default for new findings, as CISA recommends

VEX statements are signed with DSSE and Ed25519 --- the same keypair used for SLSA attestations but with a different payload type (application/vnd.openvex+json vs. application/vnd.in-toto+json). PAE binding ensures signatures cannot cross payload types despite sharing a key.

A VEX harvester combines automated scanner findings with organization-level VEX policies. If your security team has determined that a specific vulnerability does not affect your deployment pattern, that policy applies automatically to future scans. Specificity wins: a policy targeting a specific image reference overrides a wildcard policy.

WORM Audit Trail

Provenance and VEX describe current state. Compliance requires history --- proof that every action on an artifact was recorded in an immutable, ordered sequence.

Advisedly implements Write Once Read Many (WORM) audit trails using hash-chained database records with tamper-prevention triggers. Each audit event contains a prev_event_hash and an event_hash computed over canonicalized event data following RFC 8785 deterministic JSON serialization.

Three PostgreSQL triggers --- BEFORE UPDATE, BEFORE DELETE, and BEFORE TRUNCATE --- raise insufficient_privilege on any modification attempt. This is database-level enforcement, not application-level logic that a privileged user could bypass.

The chain is independently verifiable. A verification function walks the chain from head to tail, recomputing each hash and comparing against the stored value. A single bit flip in any record breaks the chain from that point forward. The verifier reports all breaks, not just the first.

A daily cron job runs automated tamper verification. If the chain is broken, a critical administrative notification fires immediately.

Air-Gap Verification

Here is where offline verification becomes concrete.

Advisedly publishes unauthenticated public endpoints for attestation retrieval --- rate-limited but requiring no API key, no session, no organizational relationship. With the signed envelope and the public key, anyone can verify an attestation using nothing more than standard cryptographic tooling. No Sigstore. No Rekor transparency log lookup. No network access after initial retrieval.

For fully air-gapped deployments, release tooling produces a verification bundle alongside every release tarball:

<release>.sha256 --- SHA-256 checksum
<release>.sig --- detached Ed25519 signature
<release>.provenance.json --- SLSA-style in-toto provenance
<release>.pub --- the public key for offline verification

The verification script performs three independent checks: checksum integrity, Ed25519 signature validity, and provenance subject-digest match. It includes a --self-test mode that generates a throwaway keypair, signs and verifies a test artifact, then intentionally tampers with it to confirm rejection. Exit codes distinguish between checksum failure, signature failure, provenance mismatch, and missing public key (refuse-by-default).

The WORM audit trail verification is similarly self-contained. Export the chain, hand it to an auditor, and they can walk the hash chain on their own machine with zero dependency on Advisedly's infrastructure.

Why This Architecture Matters for Federal

NIST SP 800-218 (SSDF) Practice PS.2 requires producers to provide a mechanism for verifying software release integrity. SLSA provenance attestations satisfy this directly. SR-3 (Supply Chain Controls) and SR-4 (Provenance) in NIST 800-53 Rev. 5 require documented supply chain protections and artifact provenance --- signed DSSE envelopes provide both.

For classified and disconnected environments, air-gap verification is a deployment requirement. Systems on SIPR, JWICS, or isolated operational networks cannot reach external verification services. If verification requires a network call to a cloud endpoint, the artifact is effectively unverifiable in the environments where trust matters most.

FedRAMP control AU-9 (Protection of Audit Information) requires audit records protected against unauthorized modification and deletion. Hash-chained records with database-level mutation triggers provide verifiable compliance --- and the hash chain makes tampering not just difficult but detectable.

Key Takeaways

A valid signature proves an artifact was not tampered with after signing --- it says nothing about whether the build environment was compromised or the source was authentic.
SLSA v1.0 provenance with DSSE/Ed25519 signing produces verifiable build integrity evidence that satisfies EO 14028, NIST SP 800-218, and NIST 800-53 SR-3/SR-4.
OpenVEX dispositions answer the question SBOMs cannot: whether a specific deployment is actually affected by a specific vulnerability.
WORM audit trails with hash-chaining and database-level tamper-prevention triggers make modification not just difficult but cryptographically detectable.
Every verification path works offline --- no Sigstore, no transparency log, no API call required after initial artifact retrieval.
Air-gapped environments get full verification bundles alongside release tarballs; the public key and standard tooling are sufficient.

Frequently Asked Questions

What is the difference between signing an artifact and signing its provenance?

Signing an artifact proves it was not modified after signing. Signing provenance proves what happened during the build --- what source was used, what builder ran, what dependencies were resolved. Both are necessary: artifact signing catches post-build tampering, provenance signing catches build-time compromise (the xz backdoor scenario).

Can I verify provenance without internet access?

Yes. The signed envelope and the public key are the only two pieces needed. Standard cryptographic tooling (OpenSSL or equivalent) performs the verification. No network call to any verification service is required after initial retrieval.

How does VEX differ from patching?

VEX is a disposition --- it declares whether a vulnerability affects a specific deployment, without requiring that the vulnerability be patched. A "not_affected" VEX statement is valid when the vulnerable code path is not reachable, compensating controls exist, or the component is present but not in the execute path. It documents the security decision, not just the action.

What happens if the WORM audit chain is broken?

Daily automated verification detects chain breaks. A break triggers a critical notification immediately. The verifier reports all break points, not just the first, so the scope of any tampering is immediately visible. Chain breaks are themselves audit events --- the system records that integrity verification failed.

Does this work with existing CI/CD pipelines?

Yes. The pipeline engine integrates with existing build tooling --- provenance generation and signing happen as pipeline steps that wrap your existing build commands. You do not need to replace your CI/CD system to get signed provenance; you add the attestation steps alongside your current workflow.

How Advisedly Helps

Advisedly generates SLSA v1.0 provenance, signs it with DSSE/Ed25519, produces OpenVEX dispositions for every finding, and chains every action into a WORM-protected audit trail that is independently verifiable offline --- giving federal and defense customers build integrity evidence that satisfies EO 14028 and NIST 800-218 without depending on any external verification service. Reach out to begin@advisedly.ai