I had a conversation this week with a major player in the DevSecOps space. They asked me what real compliance evidence looks like. Not the checkbox kind. The kind that holds up when an auditor or incident responder is standing in your room at 2am.
That question told me everything I needed to know about where the industry is right now.
The tooling is ahead of the understanding. Everyone is generating artifacts. Nobody has agreed on what makes an artifact meaningful.
The Difference Between an Artifact and Evidence
An artifact is a file your pipeline produced. Evidence is a file your pipeline produced, at a known point in time, from a known source, with a cryptographic signature that proves it has not been touched since.
Most teams have artifacts. Very few have evidence.
The distinction matters because artifacts answer the question "did this happen?" Evidence answers the question "can you prove it?" Those are not the same question. Auditors ask the second one. Incident responders ask the second one. The SEC asks the second one.
If your compliance posture is built on artifacts, you have documentation. That is not the same as a defensible record.
What Automated Evidence Collection Actually Requires
Build provenance is not a report. It is a chain. And like any chain it is only as strong as its weakest unverified link.
Real automated evidence collection in a build environment requires four things:
- Every input must be identified and pinned. Dependencies, actions, base images. Everything that touches your build needs a cryptographic reference. Not a tag, not a version string, not a branch name. A SHA.
- Every transformation must be recorded automatically. What ran, when it ran, what it produced, what environment it ran in. Not a log file someone can edit after the fact. An attestation the pipeline generates and signs without human involvement.
- The record must be tamper-evident. If someone can delete the evidence after the fact, it is not evidence. It is a note.
- Collection must be continuous and automatic. A gap in the chain is the same as no chain. One unattested step breaks the whole story. And if evidence collection requires a human to remember to run something, it will eventually fail.
Most build environments today satisfy maybe one of these. Some satisfy two. Very few satisfy all four. And almost none generate this evidence automatically as a byproduct of the build itself.
Evidence that requires manual steps to produce is not really automated evidence. It is just documentation with extra effort.
Why This Matters Right Now
Software supply chain attacks are not theoretical. They are happening at scale, targeting CI/CD infrastructure specifically, and succeeding because build environments have been treated as trusted by default for decades.
The Trivy supply chain attack earlier this year is a clean example. 75 out of 76 tags force-pushed with malicious content. Teams pinning to commit SHAs instead of tags would have been unaffected. Teams relying on tag references got hit.
Zero trust as a framework has been applied to networks, to identity, to endpoints. The build environment is the last major attack surface where implicit trust is still the default posture.
That is what this series is about. Every Friday I will be dropping practitioner notes from the field. What I am seeing, what I am building, and what the research says about where this is all going.
No fluff. No theory divorced from practice. Just the work.
Welcome to Zero Trust Fridays.