DevSecOps: shift left, assume breach

Security as everyone’s job, in the pipeline.

DevSecOps is the practice of making security a continuous, shared, automated part of building and running software — not a gate at the end run by a separate team. The name captures the shift: security joins development and operations as a first-class concern, embedded in the pipeline rather than bolted on before release. For the supply chain specifically, it means the checks that establish trust — scanning, signing, provenance, verification — run automatically on every change, owned by the whole team.

Shift left

"Shift left" means moving security earlier in the timeline — left on the diagram from production toward the developer. A vulnerability caught in the editor or the pull request costs minutes to fix; the same issue found in production costs an incident. So DevSecOps pushes checks as early as they can run: secret detection and SAST at commit and merge, dependency and image scanning at build, provenance at release, and verification at admission. Each control sits at the earliest point it can catch its class of problem.

Assume breach, automate trust

Two principles run through everything that follows. Assume breach: design so that a single compromised dependency, token, or build step does not automatically win — defense in depth, least privilege, and independent verification at each stage. And automate trust: the controls must be automatic and unskippable, because a security step that depends on someone remembering to run it will eventually be skipped. The chain of trust this course builds only holds if the pipeline enforces it by default.