From Source Code to Signed Artifact: Why Software Provenance Matters Now

The Reckoning

In recent years, software supply chains have been repeatedly targeted—through compromised maintainers, poisoned dependencies, and malicious updates distributed through legitimate channels. High-profile incidents have shown how attackers can exploit trusted ecosystems rather than breaking through perimeter defenses.

Based on reliable reports, supply chain attacks doubled in 2025; global losses are estimated at $60 billion. And every one of these incidents exploited the same blind spot: we trust our artifacts without being able to account for how they were produced.

What Provenance Is

The idea isn’t new. Pharma has batch traceability. Aerospace has airworthiness certification. Food has chain-of-custody documentation. In each case, trust isn’t placed in the final product alone—it’s placed in the documented process that produced it.

Software provenance applies that same principle. It’s verifiable metadata attached to an artifact: which source commit it was built from, which build system compiled it, what environment it ran in, which identity triggered the build, and under what parameters. Not an attempt to capture everything—just enough to answer one question: can this artifact prove how it came to exist?

Testing answers "does it work"?

Provenance answers "should we trust the process that made it"?

When your artifact is assembled from hundreds of transitive dependencies, built on cloud infrastructure, and potentially includes LLM-generated code, that second question is no longer optional.

How Provenance Is Actually Built

Three pieces form the stack, and they do different jobs.

• Attestations are signed, structured claims about a build—“this artifact came from commit abc123, built on GitHub Actions.” They’re machine-readable and standardized, but they’re claims, not proofs. A compromised build system can generate a perfectly valid attestation for a poisoned artifact.
• Sigstore makes those claims verifiable—binding them to a cryptographic identity and recording them in a transparency log. It signs artifacts and links signatures to real identities via OIDC-based keyless signing. Everything gets logged in an append-only transparency log. You can now answer: who signed this, and has it been tampered with?
• SLSA (Supply-chain Levels for Software Artifacts) grades the trustworthiness of the build system itself. Level 1: provenance exists. Level 2: builds run on hosted infrastructure, not a developer’s laptop. Level 3: the build environment is isolated, ephemeral, and generates provenance through a trusted build service with strong isolation from user-controlled steps. Each level closes specific attack vectors.

In practice, this translates to concrete pipeline rules:

• only artifacts from protected branches get promoted
• builds must run on approved, managed infrastructure
• deployment gates verify provenance before rollout

GitHub Actions already supports SLSA Level 3 provenance for containers and npm packages. Kubernetes admission controllers like Kyverno and OPA Gatekeeper can enforce attestation checks at deploy time.

The Shift That’s Already Underway

We used to trust software because we built it. We’re now moving toward trusting it because we can verify how it was built—and eventually, because we can enforce the conditions under which it’s built, promoted, and deployed.

From assumption to evidence to control. That’s the trajectory.

The tooling is still maturing. Adoption is uneven. But the direction is locked in, and every supply-chain incident that makes the news sharpens the urgency. You don’t need a perfect system to start. You need provenance to begin with—even if it’s not perfect yet.

Provenance doesn’t make software safe. It makes trust verifiable.

Security comes from enforcing that trust across the entire supply chain—not just your pipeline.

A short glossary to anchor the discussion

• Artifact: The deployable output of your build—binary, package, or container image.
• Digest: The cryptographic fingerprint that uniquely identifies an artifact.
• Attestation: A signed, machine-readable statement about an artifact.
• Provenance: An attestation describing where, from what inputs, and how an artifact was produced.
• SBOM: A machine-readable inventory of components and dependencies inside the software.
• SLSA: A framework for defining and measuring the trustworthiness of software build pipelines and provenance.
• Sigstore: An ecosystem for identity-based signing of artifacts and attestations, backed by certificates and transparency logs.
• in-toto: A standard for capturing and linking the steps, inputs, and actors in a software supply chain.

These are not just definitions—they form the vocabulary of how modern software establishes trust.

References:

1. HashiCorp – “Software Provenance: Why Visibility Into Your Software Supply Chain Matters”
2. JFrog - "What is Software Provenance?"