A few years ago, I started noticing a pattern: organizations wanted to shift security left, but nobody could agree on what that actually meant in practice. There were plenty of blog posts and conference talks, but very little structured, vendor-neutral guidance that an engineering team could actually follow from beginning to end.
That was the gap the OWASP DevSecOps Guideline was built to fill. As the project leader, I initiated and have been driving this effort under the OWASP Foundation — alongside contributors from across the security and engineering community.
What the Project Covers
The guideline is structured around the stages of a secure development pipeline. Rather than prescribing a single toolchain, it maps out the security controls that belong at each stage, explains why they matter, and provides a comparison of the tools available to implement them — factoring in things like development stack, existing infrastructure, and budget.
The major areas covered include:
Pre-commit — developer-side controls before code reaches the repository: secrets detection, pre-commit hooks, IDE security plugins, and secure coding standards.
Commit / CI — what should happen automatically on every push: SAST (Static Application Security Testing), SCA (Software Composition Analysis) to catch vulnerable dependencies, IaC scanning, and container image analysis.
Build and registry — artifact security: image signing, SBOM generation, and supply chain integrity controls.
Test — DAST (Dynamic Application Security Testing) and API security testing integrated into the pipeline against a running environment.
Deploy and runtime — infrastructure hardening, secrets management, Kubernetes security policies, and runtime security monitoring.
Monitoring and response — log aggregation, alerting, and incident response playbooks that close the loop on the pipeline.
For each area, the guideline explains the threat it addresses, the controls available, and a comparison of open-source and commercial tools — so teams can make informed decisions rather than defaulting to whatever is easiest to install.
Why OWASP?
The OWASP Foundation is the right home for this kind of work because it’s genuinely vendor-neutral. The guideline doesn’t favor any particular tool or platform. Every recommendation is evaluated on its merits, documented openly, and subject to community review.
As the OWASP Berlin Chapter leader, I also see firsthand what practitioners are struggling with — the questions that come up at meetups, the gaps between what organizations want to achieve and what they’re able to implement. That feedback has directly shaped the priorities in the guideline.
Who It’s For
The guideline is written for people who are hands-on: security engineers designing DevSecOps programs, platform engineers building internal pipelines, and developers who want to understand what’s expected of them at each stage. It assumes you’re working in a real environment with constraints — not a greenfield project with unlimited time.
It’s not a compliance document. It’s a practical reference.
Get Involved
The project is built entirely on community contributions. If you’re working on DevSecOps at your organization, the best way to contribute is to bring your real-world experience — tool evaluations, implementation notes, corrections, and additions that reflect what actually works in practice.
Pull requests, issues, and discussions are open on GitHub.