Embedding security into the delivery pipeline

Findings arrived too late to be cheap

A security finding that surfaces after a change ships is expensive in the obvious way and demoralising in a less obvious one: the engineer who wrote the code has moved on, and the fix now competes with new work. The same holds at the other end of the pipeline — learning that an unsigned image is running is far worse than never letting it start.

The goal was to move both checks earlier and make them mechanical, so that the answer to "is this safe to ship" is produced by the pipeline rather than by a person with a queue.

What the design had to live with

• Developer trust is the budget. My read is that a noisy gate gets disabled, or routed around with an exception that never expires — so signal quality mattered more to me than coverage breadth on day one.
• FedRAMP obligations. Controls had to satisfy the compliance bar the environment is held to, not merely be defensible internally.
• Existing pipelines, mid-flight. Nothing could require teams to restructure how they build and deploy.
• Security does not scale by adding reviewers. Anything whose throughput depended on headcount was not a real solution.

Two gates and a self-service path

• Static analysis in the pipeline. Code scanning runs against changes as they move toward merge, so vulnerable patterns surface while the author is still in the code rather than in a report weeks later.
• Signature verification at the cluster. Container images are signed in the build pipeline, and the Wiz Admission Controller validates that signature before workloads are admitted — enforcing workload integrity at the boundary rather than auditing it afterwards.
• Self-service review. Multi-agent security workflows built in Claude Code automate first-pass risk assessments, code reviews, and vulnerability assessments, so teams can get a useful answer immediately instead of waiting on the security queue.
• A Security Champions Program put a named person on each team who could triage findings locally — the organisational half of the same idea.

Tradeoffs worth naming

• Block at admission, not at deploy time. Enforcing at the cluster boundary catches everything that reaches the cluster, including paths that bypass the normal pipeline. The cost is that a misconfigured policy fails loudly — which is exactly why the rollout is gradual.
• Automate the first pass, not the verdict. The agent workflows do triage and drafting; a human still owns anything consequential. That keeps throughput high without pretending the automation is accountable.
• Distribute ownership rather than centralise review. A named person on each team who cares about findings changes remediation in a way another scanner does not.

Where it stands

• Static analysis runs in the delivery pipeline rather than as a review step after the fact.
• Container images are signed in the build pipeline and verified by the Wiz Admission Controller at the cluster boundary.
• Teams can run a first-pass security review themselves rather than queueing for one.
• Findings have a local owner on each team through the Security Champions Program.

What I learned

Every gate spends developer goodwill, and the balance is not replenished quickly. The version of this that works is the one where the gate is quiet, the finding is real, and the fix is obvious — which is mostly a rule-writing problem, not a tooling problem.

The Security Champions Program taught me more than any of the automation. Distributing ownership outperformed centralising review, and it is the pattern I reached for again when building the AI security program.

Details here are limited to what is approved for public disclosure. Happy to go deeper in conversation.