Skip to content

OWASP DevSecOps Guide

OWASP DevSecOps Guideline

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

DevSecOps pipeline

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.

DevSecOps cycle

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 to implement the following steps in a basic pipeline:

  • Take care secrets and credentials in git repositories
  • SAST (Static Application Security Test)
  • DAST (Dynamic Application Security Test)
  • Infrastructure scanning
  • 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 just starting out. 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, being 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 too.

OWASP Proactive Controls

What is This?

The OWASP Top Ten Proactive Controls describes the most important control and control categories that every architect and developer should absolutely, 100% include in every project.

OWASP Top 10 Proactive Controls 2018

Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be security flaws inherent in the requirements and designs. When it comes to software, developers are often set up to lose the security game.

The OWASP Top Ten Proactive Controls 2018 is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important. This document was written by developers for developers to assist those new to secure development.

OWASP SAMM

Software Assurance Maturity Model

Our mission is to provide an effective and measurable way for you to analyze and improve your secure development lifecycle. SAMM supports the complete software lifecycle and is technology and process agnostic. We built SAMM to be evolutive and risk-driven in nature, as there is no single recipe that works for all organizations.

Check out the OWASP SAMM v2 model online:

SAMM Model

Reference: https://owasp.org/www-project-samm/