The chain of custody of code
The synthesis. Four posts asked four sharp questions about your pipeline. They were never four separate controls — they were four links in one chain. Here is the chain, and a real system that wired it together end to end.
Continued from Part 4: Auditors don’t have an opinion on your CI pipeline.
Over the last four posts an auditor asked your team four questions, each one sharper than it first sounded.
You built WHAT?! — can you show every change traces to a reason that pre-dated the work? Are you sure you know how to write software? — can you show the code met a defined standard? What is your software doing? — can you prove, on every release, that the system still does what it is meant to? Auditors don’t have an opinion on your CI pipeline — can you show the thing in production is the thing you built and reviewed?
Read separately, they look like four hoops to jump through. Read together, they are something simpler and more useful: the four links in a single chain. Each question secures one handoff in the life of a change, and the four handoffs end to end are the chain of custody of code.
What “chain of custody” means here
The phrase is borrowed from evidence handling. In a courtroom, a piece of evidence is only admissible if you can account for it at every step — who held it, when, and that nobody could have tampered with it in between. A single unexplained gap and the whole exhibit is thrown out. It does not matter how genuine the evidence is. What matters is that the custody is unbroken.
Code has exactly this shape, and almost nobody treats it that way. A change starts as a business reason, becomes a requirement, becomes code, becomes a reviewed and tested artifact, becomes a running binary in production. That is a chain of custody whether you manage it as one or not. The four control points-of-focus from this mini-arc are just the four points where custody is handed from one party to the next:
- Requirements — custody passes from intent to authorized work. (Purposeful.)
- Code quality — custody passes from authorized work to reviewed code. (Assured.)
- Functionality — custody passes from reviewed code to behaviour proven on this release. (Proven.)
- Deployment — custody passes from proven artifact to exactly that artifact, running in production. (Secure and reliable.)
Break any one link and the exhibit is inadmissible. A perfectly reviewed, beautifully tested change with no traceable requirement is a change nobody authorized. A well-authorized, well-tested change that was hand-deployed outside the pipeline is a change nobody can prove is the one running. The strength of the chain is the strength of its weakest link — which is exactly why none of the four posts could be skipped.
Same work, two languages
Through the mini-arc one device kept recurring: the delivery team and the auditor describe the same link in different words. The engineer talks about running the process; the auditor talks about evidence that the process was run. Put the four handoffs side by side and that translation becomes the whole picture.
| Link | What the engineer is doing | What the auditor needs to see |
|---|---|---|
| Requirements | Tickets tie to sprint-planned work; the product owner is engaged | A documented arbitration authority and an immutable, traceable link from commit to requirement |
| Code quality | PRs get reviewed; CI runs lint, scans, tests | A written standard, a traceable approval by someone other than the author, gates that block rather than warn |
| Functionality | Tests pass; the feature works in the demo | An agreed behaviour-led test set, run every release, proving the whole system still does what it should |
| Deployment | The pipeline builds, pushes, and deploys | The binary in production is provably the reviewed, tested artifact — nothing swapped, nothing hand-placed |
Same work. Different posture. The engineer is making the system work correctly; the auditor is proving the system worked correctly, to a skeptical observer, after the fact. Neither is wrong. They have simply never been handed the same vocabulary.
The two lenses, reconciled
If you read the earlier post that introduced continuous compliance, you met a different set of four — not four lifecycle stages, but four properties of trustworthy evidence: every artifact is linked to the decision that authorized it; every link is verifiable; the records are kept under control-plane separation, by people who do not write the application code; and an evidence pack is produced automatically at release time.
These are not a competing framework, and they are not a fifth stage bolted on the end. They are orthogonal to the chain. The lifecycle lens tells you where the links are — the four handoffs above. The evidence-property lens tells you what every link has to be made of to hold weight. Linked, verifiable, separated, evidence-packed: that is the required tensile strength of each link, requirements through deployment alike. One lens is the rope; the other is the metallurgy. You need both descriptions to inspect the same object — and once you have them, the engineer’s pipeline and the auditor’s checklist turn out to be two readings of one design.
A system that wired it together
None of this is theoretical. I built a live, cloud-native application — the Crisis Monitor, a macroeconomic-signal tracker — specifically to run the whole chain end to end under enterprise controls, with the work carried out by a team of AI agents rather than humans. The implementation is public, and it demonstrates every link.
The pipeline is built on stock GitHub — no bespoke compliance tooling — and enforces a four-actor model by cryptographic identity, not by good intentions:
- a Coder who can propose changes but cannot approve their own work or touch the deployment machinery;
- a Reviewer, a distinct identity, who can approve and merge but cannot author the code under review;
- a Platform Engineer who owns the pipeline and is held to the same review rules for any change to it;
- an SRE who writes no code and exists only to authorize the final release to production.
Walk the chain and each link produces its own evidence as a side-effect of the work:
- Requirements — every change is a tracked story; the worked feature (a FRED-API data integration) traces commit-to-ticket with the history intact.
- Code quality — the CI gate runs the unit tests as a required status check; branch protection physically blocks a self-approved merge. When the Coder agent tried to approve its own pull request, the platform refused it.
- Functionality — the merged artifact is deployed to an isolated Test environment and exercised by functional smoke tests before it is allowed anywhere near production.
- Deployment — the build produces a Docker image tagged with the exact commit SHA, so the artifact is pinned to the reviewed source. Production then pauses on an SRE approval gate; the distinct SRE identity has to grant the release. When the Coder agent tried to alter the pipeline files directly, the platform rejected the push.
And then the property that ties it off: at release, the pipeline writes a c3p-evidence.json artifact — story ID, commit SHA, image tag, the actor, a UTC timestamp, and a link back to the exact workflow run — and stores it with 90-day retention. The evidence pack is generated, not assembled in a six-week scramble. An auditor opens one file and reads the entire chain of custody for that release.
The most telling moment was unplanned. A deployment failed; the Platform Engineer agent had the raw capability to reach into the application code and force a fix — and instead refused, because the controls would not let it cross into the Coder’s lane. It updated the ticket, asked the SRE for diagnostics, and kicked the missing test back to the Coder and Reviewer. Cryptographic separation did not slow the team down. It made a team of autonomous agents collaborate the way a mature, controlled engineering organisation already does. That is the chain of custody doing its job when nobody is watching — which is the only time it matters.
Wrapping up
The mini-arc opened on a familiar standoff: the engineers feeling audited by people who don’t understand engineering, the auditors unable to get straight answers to fair questions. The resolution is that they were solving the same problem the whole time. Engineers build requirement traceability, code review, behavioural tests, and deployment integrity because those things make the system work. Auditors ask for linked, verifiable, separated, packaged evidence because those things make the work provable. The chain of custody is where the two finally meet — same artifacts, same handoffs, read in two languages.
Continuous compliance is not a new layer of process. It is the recognition that a well-run pipeline already produces the chain of custody as a by-product, and a decision to capture it on the way past instead of reconstructing it under deadline. The bar for the evidence is low. The bar for thinking about the right things is not — but you have now seen all four of the right things, and a system that holds all four at once.
You can find the whole series on LinkedIn and on my blog here:
Part 2: Are you sure you know how to write software?
Part 3: What is your software doing?
Part 4: Auditors don’t have an opinion on your CI pipeline.
Paul Gresham is the creator of C3P (Continuous Compliance Control Protocol) and founder of Paul Gresham Advisory LLC. He has spent thirty-five years building and governing software in regulated industries, with senior technology leadership roles at global financial institutions. He writes about continuous compliance, software engineering controls, and AI governance.