You can't ship without a human in the loop if you don't know what you're shipping.

Continuous deployment is often sold as a pipeline problem. Write the tests, automate the stages, remove the approval button. But in a regulated environment, the approval button rarely exists because someone distrusts the tests. It exists because nobody can say, with evidence, what is inside the thing being deployed.

That's the question I kept returning to while writing the chapter on securing containers for the 4th edition of The Ultimate Docker Container Book. My conclusion: supply-chain security isn't a security topic you bolt onto delivery. It's the precondition for taking the human out of the loop at all.

What a person at the gate is really checking

When a release needs a manual sign-off, the reviewer is trying to answer three questions. What's in this image? Where did it come from? Has it been changed since we tested it? A person can't answer those reliably by looking. They end up trusting a ticket, a spreadsheet, or a colleague's word. That's slow, and it isn't much of a control either.

The tooling that has matured since the previous edition answers all three questions mechanically:

• What's in it: a software bill of materials (SBOM) lists every package and library in the image. Tools like Syft generate it at build time, and BuildKit can now attach SBOMs and provenance by default.
• Is it safe: scanners like Trivy or Docker Scout check that inventory against known vulnerabilities, on every build and not once a quarter.
• Is it the same thing we tested: signing with Cosign ties the image to the pipeline that built it. The cluster can refuse to run anything unsigned.

Once the pipeline produces this evidence and the platform enforces it, the reviewer's three questions are answered before anyone asks them. The approval step has nothing left to approve.

Enforce it in two places

Generating SBOMs and signatures is the easy part. The value comes from enforcing them twice: in CI/CD, where an unsigned or vulnerable image fails the build, and at runtime, where admission policy keeps it off the cluster. If you skip the second, someone will eventually deploy around the pipeline. If you skip the first, you find problems after they reach production.

On top of that, the hardening basics still matter: non-root users, dropped capabilities, read-only filesystems, minimal or distroless images, and secrets injected at runtime instead of baked in. Runtime detection with a tool like Falco catches what the earlier layers miss. No single layer is enough, but together they give you defense in depth that you can show an auditor.

Why this matters beyond security

I've seen this play out at a Swiss logistics company and a US consumer lender. Both teams started with continuous delivery and a person signing off each release, and moved to continuous deployment with no human in the loop once the pipeline had earned that trust. They earned it through tests and automation. Supply-chain evidence is how regulated teams can earn that same trust today. I wrote earlier about the organisational side of this in From Gatekeepers to Guardrails. This is the technical side.

Auditors don't want fewer controls. They want controls that run every time and leave a record. A signed image with an SBOM and a passing scan is a better audit trail than a signature on a change request. That's the argument that finally moves compliance teams. Automation isn't a risk to the control. It's the control, applied without exceptions.

The book's epilogue says the true value of containers "is not just technical. It is cultural." Supply-chain security is where that's most visible. Teams stop asking for permission to deploy and start producing proof that it's safe to.

If you want the hands-on version, with SBOMs, scanning, signing and runtime enforcement worked through step by step, it's in chapter 13 of The Ultimate Docker Container Book, 4th edition (Packt, 2026). The Ultimate Docker Container Book, 4th edition on Packt

May your builds stay reproducible and your deployments uneventful.

Originally published on LinkedIn on 14 Oct 2026: https://www.linkedin.com/pulse/proof-beats-permission-gabriel-n-schenker-uoqse/