What is DevSecOps and how should it work?

DevSecOps stands for development, security, and operations. Similar to DevOps or SecOps, it is a concept that joins two previously separate roles into a unified environment. DevSecOps teams are responsible for providing conditions for continuous secure software development.

Being a newer concept than DevOps, DevSecOps was coined to emphasize the importance of IT security processes and security automation in the software development lifecycle. While the idea of merging development teams and IT operations teams is not that new, until some time ago security policies were often treated as the job of security teams only. However, the increasing cybersecurity concerns made it necessary to clarify that security controls are a key aspect of continuous delivery and that everyone should be responsible for it, not only dedicated security teams.

The key assumptions of DevSecOps practices (as opposed to traditional DevOps practices) are:

• Information security practices must be an integral part of the software development lifecycle and enforced at every stage of the workflow.
• All team members involved in the software development process must assume shared responsibility for security, not only the security professionals.
• Security issues must be found as early as possible in the development cycle.
• Security risk checks must be automated as much as possible to maintain agile development.

History of DevOps and DevSecOps

In the past, software development mostly followed the waterfall model. There was a long analysis phase, a long design phase, a long development phase, and then finally the software was compiled, tested, and released. For the next version to be released, the process would take months if not years. Therefore, there was very little need for automation, and teams used to work in silos. Developers would manually compile programs, link them, upload them to a test environment (usually a physical server), QA would perform manual test suites, security would test the final product, etc.

Sponsorships Available

Sponsorships Available

Sponsorships Available

We now live in the age of agile methodologies. This means that the development teams introduce small changes regularly and new versions of products (either internal or official) are released on a weekly or sometimes even daily basis. This means that software needs to be compiled/built, linked, published, and tested on a regular basis. If this was to be done manually, it would consume so many resources that it would make agile development impossible. To be agile, you must automate release cycles as much as possible.

This is why a need for DevOps emerged: for solutions that would allow to streamline and automate software delivery as much as possible and for people who would handle the automation. A DevOps team uses continuous integration / continuous delivery (CI/CD) solutions to create development pipelines. A CI/CD pipeline involves taking source code from a repository such as git, creating a virtual environment for it with the right settings (virtual machine or a container), building the application there, publishing it in that virtual environment, running automated unit tests (including using tools such as Selenium), and providing the result to all parties concerned.

The problem is that the original concept of DevOps did not include security at all. The DevOps pipelines always contained tests for whether the application behaves according to the expectations. However, they usually did not contain tests for whether the application is safe and can’t be attacked. Security teams (SecOps) used to work after the application was released and often manually check for potential vulnerabilities. If such a vulnerability was found, the version would need to go back to the developer often from a staging or (worse) production environment. This was not agile and hence the need for integration of security with DevOps i.e. DevSecOps, sometimes called shift-left due to expanding security to the left side of SDLC diagrams.

DevSecOps for web applications and APIs

There are a lot of security tools that help businesses maintain web application security. However, only very few of them are fit to be used as part of DevSecOps. These are the tools of the future because market expectations require more and more automation and integration so DevSecOps is the future for all web application development, including APIs, web services, microservices, and more.

• Web application firewalls (such as the open-source ModSecurity) are useless for DevSecOps. WAFs work by monitoring real user requests and therefore only make sense in production environments. They do not help with issue remediation, they just protect against issues that could not be remediated in time.
• Manual penetration testing tools (Metasploit, Kali Linux, etc.) are useless for DevSecOps because they are not meant to be used as part of the automation. While penetration testers are indispensable, they must not be perceived as someone who will replace the Sec in DevSecOps.
• Simple web vulnerability scanners are not fit for DevSecOps because they are not made to be integrated with CI/CD tools. This means that they cannot provide a suitable means of security vulnerability assessment in pipelines.

The only solutions that are considered DevSecOps tools are enterprise-class SAST (static application security testing), DAST (dynamic application security testing), and IAST (interactive application security testing) scanners:

• SAST scanners, also known as code analysis tools, are often mentioned as a perfect fit for DevSecOps but that is not necessarily the case. SAST scanners have several major disadvantages. They report a lot of false positives and therefore they tend to be ignored by developers with time. They are also meant to secure code only and therefore they are completely helpless against security vulnerabilities associated with configurations or data (for example, misconfigured web servers or default passwords). They do not verify the security of third-party modules and libraries (and most software nowadays heavily relies on dependencies). Finally, they are limited to selected development environments and languages.
• DAST scanners, also called web vulnerability scanners, must be used later in the SDLC compared to SAST scanners. They work after the application is built and deployed in a runtime environment. This is often cited as their disadvantage but in reality, the position in the pipeline makes little difference to agile development (as long as they are included in the pipeline). Business-class DAST scanners also include built-in functionality for integration with CI/CD tools. Their major disadvantage is that they cannot show exactly where the error is in the source code, so developers need to find errors themselves.
• IAST scanners are the best solution for DevSecOps processes because they have the advantages of both SAST and DAST scanners. However, IAST scanners can either be based on SAST tools or DAST tools, so it is important to make that distinction. An IAST scanner based on a SAST tool still carries most of the disadvantages of that SAST tool, although it eliminates some false positives. An IAST scanner based on a DAST tool, however, eliminates the main disadvantage of DAST making it practically the perfect tool for DevSecOps pipelines.

THE AUTHOR

Tomasz Andrzej Nidecki
Sr. Technical Content Writer

Tomasz Andrzej Nidecki (also known as tonid) is a Senior Technical Content Writer working for Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.