Auditors don’t have an opinion on your CI pipeline
The fourth control point-of-focus: ensuring what is built is what is running. Let me give you a perspective, and something you can do tomorrow morning to improve your pipeline.
Continued from Part 3: What is your software doing?.
The change in production should be the change that was built, reviewed, and approved — and nothing else. That is the control point-of-focus.
After three posts of an auditor asking sharper and sharper questions, this title might come as a relief. It is. Auditors genuinely do not have an opinion on what your CI/CD pipeline looks like. They have an opinion on three things — and those three things are narrower than engineers usually fear.
The delivery team’s view
A well-run team has a build pipeline that runs tests, builds artifacts, pushes them to a registry, and deploys them. The pipeline is the team’s. It encodes their judgement about how to ship software safely. The team has spent years refining it. It is mature and it works. The last thing the team wants is an auditor showing up to tell them their pipeline is wrong.
This is reasonable. The team is right to be defensive of work they own.
The auditor’s view
The auditor agrees, and would never want to redesign your pipeline anyway. The auditor wants to verify three things, and three only:
- Is the thing running in production the thing that was actually built by the pipeline?
- Was the thing that was built the thing that was required, reviewed and approved?
- Can you prove it?
If you can answer those three questions, the auditor goes home. They are not going to lecture you about whether you should use canary deployments, what your image registry should look like, or whether your blue-green setup is best practice. None of that is their job.
If you cannot answer those three questions, the auditor has to start asking what kind of pipeline could leave such a gap — and that is when engineering teams find themselves defending choices they should not need to defend.
What each side is expecting
Same focus, two languages.
| The delivery team is expecting… | The auditor is expecting… |
|---|---|
| The pipeline runs end-to-end | The end of the pipeline produces the exact artifact that runs in production |
| Tests pass before deployment | The thing deployed is provably the thing that was tested |
| Deploys go through the pipeline | If a manual deployment ever happened, it left a documented audit trail |
| The pipeline is owned by the team | No single person can both write code and bypass the pipeline to ship it |
| Rollbacks work | A rollback restores a known-prior state, traceable to its build artifact |
The delivery team’s expectations are about running a healthy pipeline. The auditor’s expectations are about proving the pipeline did what it claimed. Same work. Different posture.
What the controls hat opens up
It sounds easy. Put your controls hat on for a minute and it isn’t.
Can you reproduce the artifact? If your build is non-deterministic — timestamps in container layers, varying dependency versions, build-time secrets that drift — the artifact in production is not strictly the same artifact that was tested.
Who has direct push access to production? If anyone does, the pipeline can be bypassed silently. The fact that nobody actually has done so this year is not the same as evidence that it is impossible.
Are build artifacts signed? Without a signature, you cannot prove that the binary running in production is the one your pipeline produced. Untrusted intermediaries could in principle swap it.
Is the deployment record immutable? Can someone re-tag, re-push, or otherwise rewrite history? If yes, the deployment log is testimony, not evidence.
What is the gap between “tested” and “deployed”? Some teams test commit N then deploy commit N+1 because “it is a tiny fix.” Each instance of that is a gap. The auditor will care about the policy, not the single instance.
None of these are exotic questions. Each one is a place where a control gap can hide.
What an auditor actually wants to see
Three specific evidence asks:
- Signed build artifacts, with the signature verifiable from the deployed system. Container image digests, signed releases — most modern registries (Docker Hub, ECR, GHCR, Harbor) support this as a setting.
- A deployment record that links each production change back to the source artifact, and from there back to the reviewed PR. Argo, Spinnaker, GitHub Actions deploy logs, GitLab CD — all of them emit this.
- An audit trail of any bypasses. If a human ever deployed without going through the pipeline (legitimately, for an emergency, or otherwise), that event is logged and visible.
That is the whole list. Nothing custom. Nothing expensive. Three evidence trails, almost all of which most teams already produce as a side-effect of doing the work. Or could produce, if you configure the tools you already use!
What you can do tomorrow
If your team is not doing this, three steps:
- Enable image digests or signed artifacts in your container registry. Most platforms have it as a setting; turn it on and start pinning deployments to digest rather than tag.
- Restrict direct production push access. Make the pipeline the only path. If you need break-glass access for emergencies, configure it explicitly — separate role, separate audit log, automatic alerting when used.
- Surface a deployment log feed somewhere queryable — what was deployed, by what pipeline run, traceable back to the PR. Most CD tools already produce this; you just need to know where to point an auditor.
Half a day’s work. None of it requires a new tool.
The reframe
The auditor isn’t redesigning your pipeline. They are asking three questions: is the binary in production the binary you built; was that binary built from reviewed code; can you prove it. Three questions. Most modern pipelines answer all three with what they already log — once you know where to look.
The next post pulls these four control points-of-focus back together as a single thesis: establishing the chain of custody of code.
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.