OWASP DevSecOps Guideline

The OWASP DevSecOps Guideline explains how we can implement a secure pipeline and use best practices and introduce tools that we can use in this matter. Also, the project is trying to help us promote the shift-left security culture in our development process. This project helps any companies of each size that have a development pipeline or, in other words, have a DevOps pipeline. We try to draw a perspective of a secure DevOps pipeline during this project and then improve it based on our customized requirements.

The Ideal goal is "detect security issues (by design or application vulnerability) as early as possible."

How the guideline is organized

The guideline is built around three pillars:

• People — teams, roles, culture, and training.
• Process — security activities woven into every SDLC stage: Design, Develop, Build, Test, Release, Deploy, Operate.
• Governance — compliance, policy as code, reporting, ASPM, and AI governance.

The current edition is refreshed for 2025/2026 and aligned with frameworks such as NIST SSDF, OWASP SAMM, OWASP DSOMM, and SLSA. See the Table of Contents below, or browse the current version.

Initial steps

DevSecOps is all about putting security into DevOps. But to keep up with the pace of CI/CD, security has to be injected early into software writing and testing.

OWASP Proactive Controls lists the top 10 security controls every developer has to implement while coding any application. Consider this set as the starting point when you have to design, write or test code in the DevSecOps cycle.

You can also follow the OWASP Software Assurance Maturity Model (SAMM) to establish what to consider for security requirements (and more) according to your maturity level.

What to add in a pipeline

At first, we consider implementing the following steps in a basic pipeline:

• Scan git repositories for finding potential credentials leakage.
• SCA (Software Composition Analysis)
• SAST (Static Application Security Test)
• IaC Scanning (Scanning Terraform, HelmChart code to find misconfiguration)
• Software supply-chain security (SBOM, artifact signing and provenance, CI/CD pipeline security)
• IAST (Interactive Application Security Testing)
• API Security
• DAST (Dynamic Application Security Test)
• CNAPP (Cloud Native Application Protection)
• Infrastructure scanning
• Continuous Scanning from other tools
• Compliance check and policy as code
• Security gates (quality gates that block risky builds and releases)
• Centralized reporting and ASPM (Application Security Posture Management)
• AI/LLM security and AI governance (securing AI-assisted development and AI-powered features)

We can customize the steps of our pipeline according to our Software Development Life Cycle (SDLC) or software architecture and add automation progressively if we are starting. For instance, we can switch from SAST/DAST to a regular test suite with built-in security controls or add an audit script checking for known vulnerable dependencies.

CI/CD is an advantage for SecOps, a privileged entry point for security measures and controls. However, when using CI/CD tools to provide automation, keep in mind that the tools themselves often expand your attack surface, so put security controls on building, deployment, and automation software.

---

Table of Contents

• 0-Intro
  • 0-1-Intro
  • 0-2-Overview
  • 0-3-Frameworks-and-Standards
  • 0-4-Regulatory-Mapping-CRA-NIS2-SSDF
• 1-People
  • 1-1-Shape-the-team
    • 1-1-1-Security-champions
    • 1-1-2-Roles-and-Responsibilities
    • 1-1-3-Security-champions-playbook-templates
  • 1-2-Training
    • 1-2-1-Secure-coding
    • 1-2-2-Security-CICD
    • 1-2-3-Security-culture-and-awareness
• 2-Process
  • 2-1-Design
    • 2-1-1-Threat-modeling
    • 2-1-2-Secure-design-and-requirements
  • 2-2-Develop
    • 2-2-1-Pre-commit
      • 2-2-1-1-Pre-commit
      • 2-2-1-2-Secrets-Management
      • 2-2-1-3-Linting-code
      • 2-2-1-4-Repository-Hardening
    • 2-2-2-IDE-and-AI-assisted-development
    • 2-2-3-Secure-Code-Review
    • 2-2-4-Developer-Workstation-and-Dev-Container-Security
    • 2-2-5-AI-Agent-and-MCP-Security
  • 2-3-Build
    • 2-3-1-Static-Analysis
      • 2-3-1-1-Static-Application-Security-Testing
    • 2-3-2-Software-Composition-Analysis
      • 2-3-2-1-Software-Composition-Analysis
      • 2-3-2-2-Dependency-Management-and-Cooldown-Policies
    • 2-3-3-Container-Security
      • 2-3-3-1-Container-Scanning
      • 2-3-3-2-Container-Hardening
    • 2-3-4-Infrastructure-as-Code-Security
      • 2-3-4-1-Infrastructure-as-Code-Scanning
    • 2-3-5-Security-Gates
    • 2-3-6-Supply-Chain-Security
      • 2-3-6-1-SBOM
      • 2-3-6-2-Artifact-Signing-and-Provenance
      • 2-3-6-3-CICD-Pipeline-Security
  • 2-4-Test
    • 2-4-1-Interactive-Application-Security-Testing
    • 2-4-2-Dynamic-Application-Security-Testing
    • 2-4-3-Mobile-Application-Security-Test
    • 2-4-4-API-Security
    • 2-4-5-Misconfiguration-Check
    • 2-4-6-AI-LLM-Application-Security-Testing
  • 2-5-Release
    • 2-5-1-Release
  • 2-6-Deploy
    • 2-6-1-Deploy
    • 2-6-2-Secrets-in-Kubernetes-and-GitOps
  • 2-7-Operate
    • 2-7-1-Cloud-Native-Security
    • 2-7-2-Logging-and-Monitoring
    • 2-7-3-Pentest
    • 2-7-4-Vulnerability-Management
    • 2-7-5-VDP-and-Bug-bounty
    • 2-7-6-Breach-and-attack-simulation
    • 2-7-7-Kubernetes-Runtime-Policy-Enforcement
    • 2-7-8-WAF-WAAP-and-RASP
    • 2-7-9-Serverless-and-PaaS-Runtime-Security
    • 2-7-10-Incident-Response-and-Detection-Engineering
• 3-Governance
  • 3-1-Compliance-Auditing
    • 3-1-1-Compliance-Auditing
    • 3-1-2-Policy-as-code
    • 3-1-3-Security-benchmarking
  • 3-2-Data-protection
  • 3-3-Reporting
    • 3-3-1-Tracking-maturities
    • 3-3-2-Central-vulnerability-management-dashboard
    • 3-3-3-ASPM
    • 3-3-4-Exposure-Management-CTEM
  • 3-4-AI-Governance-and-Risk

---

Contributing

Contributions are welcome: fix a typo, add a tool, or propose a new topic by opening an issue or pull request. Please keep tool lists vendor-neutral and alphabetically ordered, and update the Table of Contents when adding or renaming files (see doc-utilities for the TOC generator).

Running the checks locally

CI runs pre-commit (Markdown lint, trailing whitespace, end-of-file newline, YAML/JSON validity) on every pull request. Running the same hooks locally before you push avoids a red CI run:

python3.13 -m pip install pre-commit
pre-commit install          # run the hooks automatically on every commit
pre-commit run --all-files  # or run them once across the whole repository

On pull requests CI only checks the files you changed; pushes to master check the whole repository.

Previous versions

Earlier editions are kept in old-versions (V0.1, V0.2, V0.3).

License

This project is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

The project page on the OWASP website is available at OWASP DevSecOps Guideline Project