All guides
← All guides

Shift-left & DevSecOps

Cross-cutting
On this page

In plain terms

Picture your delivery process as a line running left-to-right: write code → review → build → deploy → run in production. Historically, security happened all the way on the right, a manual audit or pen-test right before release, or worse, after. Shift-left means moving those checks leftward: into the pull request and the continuous-integration (CI) pipeline, so issues surface while the code is still fresh and cheap to change. DevSecOps is the broader culture of making security a shared, automated part of delivery rather than a gate someone else owns at the end.

The line the term is named after Delivery as a line running left to right: write code, review, build, deploy, run in production. Above the line sits the single audit or penetration test security used to be, at the right-hand end, just before or after release, so everything it found was a change to code that had already shipped. Below the line sit the checks as they are placed now: secret scanning and fast static analysis while the code is being written, dependency, static and infrastructure analysis at review, header and dynamic checks against a preview deployment, and posture and certificate checks on a schedule against production. Nothing moved earlier than the artifact it reads. WHERE SECURITY USED TO SIT one audit, at the end Everything it found was a change to code that had already shipped, months after the moment it would have been cheap to change. DELIVERY, LEFT TO RIGHT write code review build deploy run in production WHERE THE CHECKS SIT NOW secret scanning fast SAST SCA SAST IaC image scanning nothing new to read that a scan has not already seen headers DAST against a preview, never production posture, TLS on a schedule, because a clean system today drifts tomorrow Nothing moved earlier than the thing it reads. A check runs at the first point its artifact exists, and that is the whole trick.
The right-hand end does not empty out, because a running system is the only place some questions can be asked. What changes is that it stops being the first place anybody looks.

Why it matters

A vulnerability caught in a pull request is a code-review comment. The same vulnerability caught in production is an incident. Plus the cost of the emergency fix, the redeploy, and possibly a breach. The earlier a problem is found, the cheaper and less disruptive it is to fix. Automating security checks into the pipeline also means they happen every time, consistently, instead of depending on someone remembering.

Where it fits

Shift-left is less a single control and more where you run the controls in this handbook:

Where it runsWhat belongs there
In the editor / pre-commitsecret scanning, fast SAST.
On the pull requestSCA, SAST, IaC, image scanning, as a CI gate.
Against a preview/staging deployheaders, DAST.

How gating works

The mechanism is simple: a scan runs in CI and exits non-zero when it finds something that violates policy, which fails the pipeline and blocks the merge or deploy. The art is in the policy, gate on what matters (see prioritization) so the gate stays trusted instead of being routed around.

What becomes of a gate, depending on what it blocks Two policies for the same check. Failing the build on the whole findings wall makes the build red for things nobody decided mattered; somebody routes around it once, and from then on the check still runs and nobody reads what it says. Failing on a short ranked list means red carries a decision that a person made, so it keeps its meaning, and the rest of the findings are still in the report where they can be worked through without holding a merge. SAME CHECK, TWO POLICIES, AND WHAT BECOMES OF EACH Fail on every finding the whole wall blocks the merge red means something nobody decided to care about somebody routes around it, once and the check runs forever after with nobody reading it Fail on priority a short ranked list blocks the merge red means a judgment somebody made and wrote down it gets fixed, or it gets excepted and everything else is still in the report, not holding anybody up Blocking on more is not stricter. A gate is only as strict as the number of times people are willing to obey it.
Reporting and blocking are separate decisions, and the reason to keep them separate is that a gate spends credibility every time it turns red for nothing.

Common pitfalls

The pitfallWhy it bites
Gating on everythingBlock on the whole findings wall and developers will disable or bypass the check. Gate on priority; report the rest.
Slow checksA scan that adds ten minutes to every PR gets removed. Keep PR-time checks fast; run the heavy ones on a schedule.
Security as someone else's jobDevSecOps works when the team owns its findings, not when they're thrown over a wall.
How Draugr fits. Draugr is built to be a CI gate: one draugr scan runs the controls that apply to your app and exits non-zero on a failing verdict, so it blocks a pipeline directly. The gate blocks on P1 by default, which folds in what you declared about each component, and --fail-on takes a severity instead where you want the scanner's own rating. Results publish to code scanning as evidence. See running Draugr in CI in the docs.

Keep learning