All guides
← All guides

Shift-left & DevSecOps

Cross-cuttingDraugr: available today

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.

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:

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.

Common pitfalls#

  • Gating on everything. Block on the whole findings wall and developers will disable or bypass the check. Gate on priority; report the rest.
  • Slow checks. A 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 job. DevSecOps 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. --fail-on and --fail-on-priority let you gate on exactly what matters, and results publish to code scanning as evidence. See running Draugr in CI in the docs.

Keep learning#