SBN

DevSecOps vs. SecDevOps

DevSecOps is a relatively new approach to continuous software development processes in agile environments. It is an extension of DevOps (Development + Operations) that includes the automation of security. The order of component terms in the DevSecOps name, however, may lead to incorrect application security approaches. That is why some sources propose SecDevOps as a better term.

Traditional DevOps processes do not include security. This means that many application development businesses that practice the DevOps culture initially have no security teams at all! Such businesses may perceive DevSecOps as a process in which they first develop the application, then test it for security in a staging environment, and then deploy it in production. Even worse, they may attempt a DevOpsSec approach where the application is tested only after it is deployed. Both these approaches may cause major delays in development and are not fit for agile DevOps practices with security included.

Inefficient DevSecOps approach

In an inefficient DevSecOps approach to continuous development, the business has a separate security team that is responsible for security testing and is not part of the development. In such a case, the development team builds an application using a CI/CD (Continuous Integration / Continuous Delivery) solution. New code is automatically compiled using such a solution and then tested (but this does not include security testing). When the code is ready, the application is deployed on a staging environment and that is when the security team starts working on it (either manually or using automated tools).

The problem with this approach is that security issues are found late in the process. If the security team finds a security concern, the application must be corrected and go through the entire process again. This is not agile and it also creates a bottleneck for the security team. In the worst case, there is no time left to correct the application because the project managers or product/service owners cannot cater to potential delays caused by the necessity to go back to the development and build process due to security risks. If so, the application may have to be released with security issues!

SecDevOps – security best practices

The correct way to include cybersecurity in the development workflow is to see information security as the number one priority. Security practices should be included in every stage of application development. There should be a minimal security team that focuses on security policies, oversees continuous deployment, and performs advanced manual penetration testing. As many security tasks as possible should be performed by other teams in the DevOps pipeline.

A SecDevOps approach begins with education. Security teams should provide training on secure coding and secure development practices. For example, developers should be taught never to trust user input and to use parameterized queries or stored procedures in the source code to avoid SQL injection vulnerabilities. Test developers and QA teams should be taught how to use dynamic analysis tools and how to create security tests for the development cycles. Operations teams should be taught how to make regular security vulnerability scanning part of the operations.

Educated teams can handle most of build security themselves. Operations engineers can integrate products such as the Acunetix vulnerability scanner with CI/CD tools. This way, every build delivered by the development team is immediately scanned in real-time for issues and the developer is notified about issues that they need to correct. Operations engineers can also integrate vulnerability scanners with issue tracking systems so that every issue is automatically retested after being closed by the developer. IAST tools like Acunetix with AcuSensor are best suited in such cases because they report much fewer false positives than SAST tools and they provide more information to the developer than DAST tools.

A recipe for secure software

As an afterthought, no matter what name you choose for your secure DevOps, the important thing is to realize that security should not be an isolated island in your development and deployment processes but an integral part of every activity in the software development lifecycle. To deliver secure products, you need wide-reaching security policies and it is recommended that you follow cybersecurity frameworks. It’s not about which tools you choose, how many security professionals you employ, but how you ensure that every member of the team (developers, QA engineers, project managers, product/service owners, administrators, operations engineers – everyone) does their job with potential security challenges in mind. Only with rugged DevOps and suitable security controls everywhere can you be sure that your company name does not end up in the hall of shame after a security breach.

Frequently asked questions

DevSecOps is a set of practices that combines software development (Dev), security (Sec) and IT operations (Ops). It is an extension of DevOps. In practice, it means testing the security of software as part of continuous integration (CI) or continuous deployment (CD).

Learn more about DevSecOps.

SecDevOps is very similar to DevSecOps but security is placed as the first priority of the process. It means that security should not only be tested during CI/CD but should be the first priority in software development. SecDevOps helps to eliminate security issues before they appear.

Read more about secure coding practices.

SecDevOps is better than DevSecOps because it describes a mindset where everyone involved in DevOps understands security. This means that much fewer security vulnerabilities are introduced into software, which reduces the risks and the time needed to fix issues.

Find more best practices for web application security.

Implementing SecDevOps is not simple and begins with education. Everyone involved in software creation should be aware of security risks introduced by vulnerabilities: all developers, operations engineers, product owners, administrators, etc. Then, you can implement verification, for example, by including a vulnerability scan in your CI/CD builds.

Learn how to include a vulnerability scan in a Jenkins pipeline.

THE AUTHOR
Tomasz Andrzej Nidecki
Technical Content Writer

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.

*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: https://www.acunetix.com/blog/web-security-zone/devsecops-vs-secdevops/