Software Provenance Verification

Software provenance is the verified record of a software artifact's origin , specifically, the evidence that the artifact was produced by the stated build process from the stated source code, rather than a modified version inserted into the distribution chain after the legitimate build completed. Code signature verification confirms that the artifact was signed by the holder of the private key. Software provenance verification confirms that the artifact was built from the expected source code by the expected build system at the expected time. These are distinct assurances , the first is about who signed, the second is about what was built.

The distribution infrastructure compromise is the specific attack vector. Software vendors distribute updates through web servers, content delivery networks, and update infrastructure. An attacker who gains access to this distribution infrastructure can replace legitimate software artifacts with malicious ones , using the vendor's own delivery mechanisms, HTTPS certificates, and in some cases even their signing infrastructure if it is accessible from the compromised environment. The consumer who downloads the software from the legitimate URL, verifies the HTTPS connection, and checks the signature against the vendor's known public key may receive and deploy the attacker's software if the attacker had access to the distribution environment and the signing infrastructure.

The reproducible build connection is the provenance verification mechanism. A software artifact has verifiable provenance if: a provenance attestation exists (created by the build system, not by the developer) that records the source code commit, build inputs, and build environment; the artifact can be independently rebuilt from that source commit and produces an identical binary; and the provenance attestation is signed by the build system and logged to an immutable transparency log. When these conditions are met, a consumer can verify that the artifact they received matches the artifact that the stated build process produced from the stated source code , catching distribution infrastructure compromises that produce different artifacts.

Why this matters

Software provenance verification matters for TPRM because distribution infrastructure compromises are a documented attack vector , the mechanism used in the NotPetya attack (through M.E.Doc update infrastructure), the ASUS Live Update attack, and similar supply chain incidents. The enterprise that verifies signatures without verifying provenance has confirmed that the signing key was used, not that the legitimate build process produced what the signing key signed.

• Signature verification accepted as provenance confirmation
• Distribution infrastructure compromise not considered in software delivery security model
• Provenance attestation not requested or verified for software updates
• Reproducibility not assessed for critical software
• Transparency log verification absent from software deployment process

What good looks like

Mature software provenance programmes request SLSA provenance attestations for critical software updates, verify attestations against transparency logs before deployment, and where software criticality warrants it, validate reproducibility of critical releases from published source code.

• SLSA provenance attestation requested for critical software updates
• Transparency log verification before deployment , Sigstore Rekor or equivalent
• Reproducibility validation for highest-criticality software , confirming build determinism
• Distribution infrastructure security assessed in vendor build security review
• Out-of-band update notification , verifying updates through separate channel from delivery infrastructure

Tooling

Provenance , cosign for SLSA provenance attestation verification; Rekor for transparency log queries

The cosign tool from Sigstore verifies SLSA provenance attestations against the Rekor transparency log , confirming that a software artifact's provenance attestation is valid and that it was logged at the expected time with the expected build system credentials. For critical software updates, running cosign verification before deployment is the specific provenance check that distribution infrastructure compromise detection requires.

Reproducibility , Reproducible Builds project infrastructure; rebuilderd for automated rebuild verification

The Reproducible Builds project provides tooling and community infrastructure for verifying that software builds are deterministic , that the same source code produces the same binary. For critical infrastructure software, participating in reproducible builds verification provides the independent confirmation that the distributed artifact matches the published source code.

Governance challenges

The governance challenge with software provenance verification is the adoption gap. SLSA provenance attestations, transparency log verification, and reproducible builds are emerging practices that many software vendors have not yet implemented. The governance resolution is progressive requirements: requesting provenance attestations from critical software vendors and accepting the disclosure of their SLSA roadmap as evidence of progression, while requiring stronger provenance verification for the highest-criticality software.

• Request SLSA provenance attestations for critical software updates
• Verify attestations using cosign before deploying critical updates
• Assess distribution infrastructure security in vendor build security review
• Require transparency log logging for signing events
• Implement out-of-band update verification for critical software

If you are a small team

For your three most security-critical software products , the ones where a distribution infrastructure compromise would be most damaging , ask one question before the next update: do you produce SLSA provenance attestations for your releases, and can I verify the attestation for this specific release before I deploy it? If the answer is yes, use cosign to verify it. If the answer is no, that is a provenance gap for software at the highest criticality tier. The inability to verify provenance is the same exposure the hook organisation experienced.

• Ask for SLSA provenance attestation before deploying critical updates
• Verify attestations using cosign before deployment
• Assess distribution infrastructure security in vendor review
• Implement out-of-band update verification for critical software

What to require

Ask directly:

"Do you produce SLSA provenance attestations for your software releases , and can I verify the attestation for a specific release using cosign against the Sigstore Rekor transparency log to confirm that the distributed artifact matches what your build system produced?"

Expect as evidence

• SLSA provenance attestation for specific releases
• Transparency log entry verification process
• SLSA level and roadmap
• Distribution infrastructure security description

A vendor who confirms signed releases should be asked about provenance attestation verification. Signature confirms the key signed the artifact. Provenance attestation confirms the build system produced what the key signed. The distribution infrastructure compromise bypasses signature if the attacker also had signing access. Provenance attestation logged to an immutable transparency log before the compromise is the evidence that the compromise cannot erase.

How to evidence it

• Provenance attestation verification records for critical updates
• Transparency log verification implementation
• Distribution infrastructure security assessment
• SLSA provenance requirement for critical software tier

Key Takeaway

Signature: valid. Delivery: HTTPS. URL: legitimate. Distribution infrastructure: compromised 3 weeks prior. Software: attacker's version. The enterprise had verified everything that the legitimate distribution channel provides. The attacker had compromised the legitimate distribution channel. Provenance attestation logged to an immutable transparency log before the compromise is the evidence that the compromise cannot retroactively forge , it exists before the attacker had access, confirming what the build system produced. SLSA provenance verification before deployment is the control that catches distribution infrastructure compromise. Signature verification does not.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security