What is DevSecOps and how should it work? | Acunetics

DevSecOps means Development, SecurityAnd Operation. Like DevOps or SecOps, it is an idea that joins two previously separate roles in an integrated environment. DevSecOps teams are responsible for setting the conditions for the development of uninterrupted secure software.

As a new concept compared to DevOps, DevSecOps was created to emphasize the importance of IT security processes and security automation in the software development lifecycle. Although the idea of ​​merging development teams and IT operations teams is not new, until some time ago, security policies were often considered as the work of security teams. However, due to growing cybersecurity concerns it needs to be made clear that security controls are a key aspect of continuous distribution and everyone should be responsible for it, not just dedicated security teams.

The basic premise of the DevSecOps practice (as opposed to the traditional DevOps practice) is:

• Data protection practices must be an integral part of the life cycle of software development and must be applied at every stage of the workflow.
• All team members involved in the software development process must share responsibility for security, not just security professionals.
• Security issues need to be addressed as soon as possible in the development cycle.
• Security risk checks should be as automated 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 published. For the release of the next version, the process will take months, if not years. Therefore, there was very little need for automation and teams worked in silos. Developers will manually compile programs, link them, upload them to a test environment (usually a physical server), perform a QA manual test suite, test security final products, and more.

We now live in an age of agile systems. This means that development teams regularly introduce small changes and new versions of products (either internal or official) are published on a weekly or sometimes even daily basis. This means that the software needs to be compiled / built, linked, published and tested regularly. If it is done manually, it will consume so much resources that it will make rapid development impossible. To be agile, you need to automate the release cycle as much as possible.

This is why DevOps is needed: solutions that allow streaming and automation of software distribution as much as possible, and for those who manage automation. A DevOps team uses the Integration / Continuity Delivery (CI / CD) solution to create development pipelines. Involve source code from repository like Git in a CI / CD pipeline, create a virtual environment for it with the right settings (virtual machine or a container), create applications there, publish it in that virtual environment, run automated unit tests. . (Including using tools like Selenium), and providing results to all parties involved.

The problem is that security was not included in the original concept of DevOps. The DevOps pipeline always checks to see if the application behaves as expected. However, they usually do not test whether the application is secure and cannot be attacked. The security team (SecOps) worked after the application was released and often manually checked for potential vulnerabilities. If such a vulnerability is found, the version often needs to be returned to the developer from a staging or (bad) production environment. It was not agile and therefore required security integration with DevOps i.e. DevSecOps, which is sometimes called shift-left due to the extended security on the left side of the SDLC diagram.

DevSecOps for web applications and APIs

There are many security tools that help businesses maintain web application security However, very few of them are suitable for use as part of DevSecOps. DevSecOps is the future of all web application development, including APIs, web services, microservices and more.

• Web application firewalls (such as open-source ModSecurity) are useless for DevSecOps. WAFs work by monitoring actual user requests and therefore only make sense in the production environment. They do not help solve problems, they only protect against problems that cannot be fixed in time.
• Manual penetration testing tools (Metasploit, Kali Linux, etc.) are useless for DevSecOps because they are not intended to be used as part of automation. Although penetration testers are essential, they should not be considered as someone who will replace Sec in DevSecOps.
• General Web vulnerability scanners are not suitable for DevSecOps because they are not designed to integrate with CI / CD tools. This means that they cannot provide a proper way to assess safety vulnerabilities in the pipeline.

The only solutions considered as 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 referred to as a perfect fit for DevSecOps but are not essential. SAST scanners have several major drawbacks. They report a lot of false positives and are therefore ignored by developers over time. They are also meant to protect code only and are therefore completely vulnerable to security vulnerabilities related to configuration or data (for example, incorrectly configured web servers or default passwords). They do not verify the security of third party modules and libraries (and most software nowadays relies on reliability). Finally, they are confined to selected development environments and languages.
• The DAST scanner, also called the Web Vulnerability Scanner, must be used later in SDLC than in SAST scanners. They work after the application is created and placed in a runtime environment. This is often cited as their disadvantage but in reality, the location of the pipeline makes little difference in rapid 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 main disadvantage is that they can’t show exactly where the error is in the source code, so the developers have to find the error themselves.
• IAST scanners are the best solution for DevSecOps processes because they have the advantage of both SAST and DAST scanners. However, IAST scanners can be based on either SAST tools or DAST tools, so it is important to make this 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 major disadvantages of DAST which makes it virtually the perfect tool for DevSecOps pipelines.

Author

Tomas Andrej Nideki
Senior technical content writer
LinkedIn

Tomasz Andrzej Nidecki (also known as Tonid) is a senior technical content writer working for Acunetics. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz was the managing editor of hakin9 IT security magazine in his early years and ran a major technical blog dedicated to email security.