From Commit to Production: What a Secure-by-Design Delivery Pipeline Actually Looks Like

Plenty of teams agree security should "shift left." Fewer can show you the pipeline that makes it real. The gap between the principle and the plumbing is where most security programs stall.

This post is about the plumbing. It walks a change from a developer's keyboard all the way to production, stage by stage, and shows where security is wired into each step — not as a gate bolted on at the end, but as a series of checks the change simply can't skip. Everything here is described generically, so you can map it onto your own stack and change-management process.

The shape of the pipeline

A mature delivery pipeline usually moves a change through four environments:

BUILD & SECURITY  →  QA  →  UAT  →  PRODUCTION

BUILD & SECURITY  →  QA  →  UAT  →  PRODUCTION

Each boundary between environments is a promotion, and each promotion is gated. The key design idea: the same artifact is promoted across environments — it is never rebuilt. What you tested in QA is bit-for-bit what reaches production. Rebuilding per environment quietly reintroduces risk and destroys your provenance story.

Here is the same pipeline stage by stage — each gate and the evidence it produces, top to bottom:

Let's walk the stages.

Before the first commit: provisioning is a security event

It's tempting to think security starts at commit. It actually starts earlier — at provisioning.

Infrastructure provisioning. New infrastructure shouldn't be clicked into existence. A request is raised, reviewed, signed off, and then provisioned through infrastructure-as-code and automation. The security value is twofold: a human review happens before resources exist, and the actual creation is automated and repeatable rather than manual and ad hoc.

Repository provisioning and access. Who can create a repository, and who can access it, is a governance decision. A good model enforces:

Two-level approval for access (for example, a team lead and a manager).
Scoping rules — access within the same team/cluster is straightforward; access across trust boundaries is restricted or denied by default.
Elevated or "premium" repositories requiring higher approval.
Automated granting once approvals are in place, so the policy is enforced by the system, not remembered by a person.

Getting provisioning right means every downstream stage inherits a clean, least-privilege foundation.

Build & Security: catch it at the source

Commit. The developer pushes a branch and opens a pull request. Pre-commit hooks and push protection stop secrets before they ever land in history — the cheapest possible place to catch them.

CI + security scanning. On every pull request, the build runs a layered set of checks:

Automated static code analysis for code-level vulnerabilities.
Secret scanning to catch credentials that slipped past push protection.
Open-source dependency analysis for known-vulnerable and non-compliant third-party components.

A critical finding fails the build. This is fail securely in action — the application vulnerability check must be green to progress. No green, no merge.

Artifact creation and signing. Only signed-off images make it into the artifact repository. A build-image sign-off gates the upload, so you always know what you're shipping and that it hasn't been tampered with. A worthwhile addition most teams miss: an automated, scheduled cleanup of stale images. It's partly hygiene and partly a real cost saving — artifact storage grows silently and forever if you let it.

Architecture and change review (shift-left governance). A recurring review of architecture and upcoming changes — from a security and risk standpoint — happens before work is promoted toward QA. Catching an architectural risk at design time is dramatically cheaper than catching it at the production gate.

QA: security rides with quality

Automated deployment to QA. Deployment is automated through reusable pipeline components. A critical control here: no direct access to the runtime environment. Nobody hand-deploys. Database access, where needed, goes through role-based access with just-in-time elevation rather than standing permissions.

QA testing. Beyond functional and regression tests, this stage runs:

Dynamic testing against the running application, probing it the way an attacker would.
Image vulnerability checks on what's actually deployed.

The QA sign-off produced here becomes a piece of evidence that later promotions depend on. Security testing isn't a separate track — it rides along with quality assurance.

Promotion gates: where governance gets real

Promotion to higher environments (UAT, then production) is where a secure pipeline earns its keep. A well-designed promotion gate validates a bundle of evidence before anything moves:

QA sign-off — the change passed quality and security testing.
Open-source / license approval — dependencies are vulnerability- and license-clean.
System vulnerability assessment — the hosting environment is clean.
Application vulnerability assessment — the code and APIs are clean.

Only when that evidence is complete does an automated promotion run. The deploy itself is triggered by the approved change request — automation executes policy, humans approve risk. Those are two different jobs, and keeping them separate is the whole point.

UAT sign-off. Business and QA validate against acceptance criteria, and the sign-off is recorded as evidence attached to the change. Evidence, not promises.

The production gate: risk, exceptions, and change orders

Production is where the strongest controls live.

Change control board review. A cross-functional board reviews the change for risk and grants exceptions where genuinely needed. A quorum-based vote (for example, a minimum of three of five members approving) prevents any single person from waving a risky change through. This is separation of duties at the organizational level.

Change order for new architecture or APIs. If a change introduces new architecture or a new public interface, it should trigger a heavier review requiring explicit approvals: security architecture sign-off, system and application vulnerability assessments, and configuration assessment when new infrastructure is involved. The scan reports are attached as evidence before the change order can progress — so the approval is backed by artifacts, not assertions.

Change types matter. Not every change deserves the same ceremony. A good model distinguishes:

Standard changes — pre-approved, low-risk, and allowed to skip the heavyweight board.
Normal changes — the full approval path.
Emergency changes — an expedited path for genuine incidents, reviewed after the fact.

Right-sizing the process to the risk is what keeps security from becoming the thing everyone routes around.

Production and beyond: the job isn't done at deploy

Automated production deployment. Same automated, no-direct-access model as the lower environments, driven by the approved change request. Same artifact, controlled rollout.

Runtime monitoring. Deployment is the start of the security story, not the end:

System vulnerability assessment across the live fleet of clusters.
Configuration / policy compliance assessment against hardening baselines.
Aggregation and correlation of findings in a single, centralized view of security posture — and cross-referencing against public feeds of actively exploited vulnerabilities so you fix what's actually being attacked first.

Runtime is where new vulnerabilities in old code get discovered. A pipeline that stops caring at deploy is blind to most of its real-world risk window.

What makes it "secure by design" and not just "a pipeline with scans"

Three things distinguish a genuinely secure-by-design pipeline from one that just has some security tools bolted on:

The checks are unskippable. They're required gates, not optional steps a busy team can click past. Fail securely is the default.
Evidence is a by-product of the workflow. Sign-offs, scan reports, approvals, and audit trails accumulate automatically. Compliance becomes something you have, not something you scramble to assemble.
Automation executes; humans approve. The pipeline runs the mechanics identically every time, while people make the risk decisions. No direct environment access, no manual deploys, no heroics.

Map every stage against the functions a security program needs — prevent, detect, govern, protect, respond, measure — and you'll find each one is exercised somewhere across the lifecycle. That full-grid coverage, enforced automatically, is secure by design.

Where to start if you're building this

You don't need the whole pipeline on day one:

Make one security check a required merge gate — and actually enforce it.
Stop manual deploys to one environment; replace them with an automated, access-controlled pipeline.
Start attaching evidence (scan reports, sign-offs) to your change records, even manually, so the habit forms before you automate it.

Each piece delivers value on its own, and together they compound into a pipeline where shipping securely is simply the only way to ship.

Curious how other teams structure their promotion gates and change-control boards — especially how you balance rigor against developer velocity. What's working for you?

Contents