Software Provenance
Software provenance is the verifiable record of where a piece of software came from, who produced it, and how it was built, from the first line of source code to the artifact running in production.
ON THIS PAGE
What Is Software Provenance?
It answers three questions: What is this? Where did it come from? Can I prove nobody changed it along the way?
As organizations rely more on open-source packages, third-party dependencies, and now AI-generated code, software provenance has become a basic control for supply chain integrity.
What Software Provenance Means
Think of software provenance as a chain of custody for code. In art or pharmaceuticals, provenance documents every hand an object passed through. In software, it documents every step an artifact went through. That usually includes:
Source origin: the repository, commit hash, and branch the code was built from.
Build process: the build system, build instructions, environment, and parameters used.
Dependencies: the external packages and versions pulled in during the build.
Identity: who or what (a developer, a CI runner, an automated agent) triggered and signed each step.
Integrity evidence: cryptographic hashes and signatures that tie the final artifact to all of the above.
Provenance only matters if it's verifiable. A README that says "built from main" proves nothing. A signed attestation, generated automatically by a trusted build platform and checked before deployment, does. That's why modern software provenance tracking uses cryptographic signing, tamper-evident logs, and standard metadata formats rather than manual documentation.
Concrete Use Cases for Software Provenance in Modern Development
1. Verifying open-source dependencies before use
Package registries such as npm and PyPI now support provenance attestations that link a published package to the specific repository and CI workflow that built it. Teams can reject packages whose provenance is missing or doesn't match the expected source. This defends against typosquatting and hijacked maintainer accounts.
2. Gating deployments in CI/CD
Admission controllers and deployment policies can require that every container image carries a valid, signed provenance attestation before it reaches production. If an image was built on a developer laptop instead of the approved pipeline, it gets blocked.
3. Incident response and blast-radius analysis
When a vulnerability or compromised dependency is disclosed, provenance records let security teams quickly find which builds, services, and releases included the affected component, and which didn't.
4. Tracking AI-generated and agent-written code
AI coding assistants and autonomous agents now write, modify, and commit code. Provenance increasingly needs to record which agent produced a change, under what instructions, and with which tools. That matters because agents can be manipulated through attacks like prompt injection, where hidden instructions steer an agent into adding malicious dependencies or altering build scripts. Without provenance, those changes blend in with legitimate commits.
5. Meeting customer and regulatory attestation requirements
Software vendors selling to governments and regulated industries are increasingly asked to prove how their software was built. Provenance data gives them that evidence.
How Software Provenance Has Evolved in Response to Supply Chain Attacks
For years, software provenance was an afterthought. Teams trusted their build servers and package registries implicitly. A series of high-profile attacks changed that.
SolarWinds (2020): Attackers compromised the build environment and injected a backdoor into signed, legitimate updates shipped to thousands of customers. The source code looked clean. The build didn't. It showed that signing the output is meaningless if you can't verify the process that produced it.
Codecov (2021): A modified script in a widely used CI tool quietly exfiltrated credentials from customer pipelines.
3CX (2023): A cascading supply chain compromise, which began with a trojanized upstream application, led to a tampered desktop client.
xz Utils (2024): A long-running social-engineering campaign placed a backdoor in a core Linux compression library. The malicious code was hidden in release tarballs and never appeared in the visible repository, exactly the gap provenance aims to close.
Self-propagating npm worms (2025): Malware harvested maintainer tokens and automatically republished infected versions of popular packages, spreading through the ecosystem at scale.
The industry responded with standards and tooling. Google and the Open Source Security Foundation introduced SLSA (Supply-chain Levels for Software Artifacts), a framework with graduated levels for build integrity and provenance. in-toto defined a standard format for supply chain attestations. Sigstore made keyless signing and public transparency logs practical for any project. Registries, cloud providers, and CI platforms have since built native provenance generation into their workflows.
The next frontier is extending provenance to AI agents, MCP servers, and model artifacts, which are now part of the software supply chain too.
Frequently asked questions
What is the difference between software provenance and a software bill of materials (SBOM)?
An SBOM is an inventory: it lists the components and dependencies inside a piece of software. Software provenance is a history: it records how and where that software was built, and by whom. An SBOM tells you what's in the box. Provenance tells you who packed it and whether anyone opened it since. The two work best together.
How is software provenance verified in a CI/CD pipeline?
The build platform generates a signed attestation (commonly in SLSA/in-toto format) describing the source commit, build steps, and resulting artifact hash. Tools such as Sigstore's cosign or slsa-verifier then check the signature, confirm the builder identity is trusted, and match the artifact hash before the artifact is promoted or deployed. Policy engines can enforce these checks automatically.
Which regulatory frameworks or standards reference software provenance requirements?
Key references include U.S. Executive Order 14028, NIST's Secure Software Development Framework (SP 800-218), CISA's Secure Software Development Attestation Form, the EU Cyber Resilience Act, and industry frameworks like SLSA. Each one, directly or indirectly, expects organizations to show where their software came from and how it was built.
Can software provenance help detect tampering after a package has been published?
Yes. Because provenance ties an artifact's cryptographic hash to a specific source and build, any change after publication, such as a swapped binary, an altered tarball, or a republished version from a stolen account, will fail verification or show a mismatched origin. Public transparency logs also make unexpected signing events visible, so tampering is easier to spot and harder to hide.
Related terms
See what your agents are actually doing.
Dash discovers every AI agent, tool, and MCP server across your estate, understands session and intent, and enforces policy at runtime.