What Is DevSecOps and How Should It Work?

Third Pillar of Security

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 application 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 was often treated as a side-task. 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.
  • All team members involved in the software development process must be responsible for security, not only the security professionals.
  • Security issues must be found as early as possible in the development cycle.
  • Security 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.

We now live in the age of agile development. 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 software delivery to be automated as much as possible and for people who would handle the automation. A DevOps engineer uses continuous integration / continuous delivery (CI/CD) solutions to create development pipelines. A 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.

DevSecOps for Web Applications and Web Services

There are a lot of security tools that help businesses maintain web 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 development.

  • 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 on production environments. They do not help to resolve issues, they protect against issues that could not be resolved 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 tools that are fit for use in a DevSecOps environment 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 their reports tend to be ignored by developers with time. They are also 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 such modules and libraries). Finally, they are limited to selected development languages.
  • DAST scanners, also called web vulnerability scanners, must be used later in the development lifecycle compared to SAST scanners. They work after the application is built and deployed in a testing 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 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 pipelines 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.
Share this post
Tomasz NideckiTomasz Andrzej Nidecki Technical Content Writer
LinkedIn: https://mt.linkedin.com/in/tonid

Tomasz Andrzej Nidecki (also known as tonid) is a 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.