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 fast as possible."

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)
• 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

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
• 1-Init
  • 1-1-Shape-the-team
    • 1-1-1-Security-champions
  • 1-2-Training
    • 1-2-1-Secure-coding
    • 1-2-2-Security-CICD
• 2-Pre-commit
  • 2-1-Pre-commit
  • 2-2-Threat-modeling
  • 2-3-Repository-hardening
  • 2-4-Secrets-Management
  • 2-5-Linting-code
• 3-Commit-CI
  • 3-2-Interactive-Application-Security-Testing
  • 3-1-Static-analysis
    • 3-1-1-Static-Application-Security-Testing
    • 3-1-2-Software-Composition-Analysis
    • 3-1-3-Container-Security
      • 3-1-3-1-Container-scanning
      • 3-1-3-2-Container-hardening
    • 3-1-4-Infastructure-as-code
• 4-Continuous-delivery-CD
  • 4-1-Dynamic-Application-Security-Testing
  • 4-2-Mobile-Application-Security-Test
  • 4-3-API-Security
  • 4-4-Miss-Configuration-Check
• 5-Deploy-CD-Golive
  • 5-1-Key-and-certificate-management
  • 5-2-Cloud-Native-Application-Protection-Platform
• 6-Operation
  • 6-1-Runtime|Continuous-test
    • 6-1-1-Infra-scanning
      • 6-1-1-1-Could-resources
      • 6-1-1-2-K8S-resources
    • 6-1-2-Image-scanning
  • 6-2-Breach-and-attack-simulation
  • 6-3-Logging-and-Monitoring
  • 6-4-Pentest
  • 6-5-VDP|Bug-bounty
• 7-Governance
  • 7-1-Compliance-Auditing
    • 7-1-1-Compliance-Auditing
    • 7-1-2-Policy-as-code
    • 7-1-3-Security-benchmarking
  • 7-2-Data-protection
  • 7-3-Reporting
    • 7-3-1-Tracking-maturities
    • 7-3-2-Central-vulnerability-management-dashboard

The project page on the OWASP website is here