What Is DevSecOps? Six Steps to Secure Your Software Delivery

While the DevOps approach to software delivery has positively revolutionized the IT industry, the security requirements have largely been left unattended. This is what DevSecOps aims to fix.

DevSecOps is one of the most important DevOps trends of 2018. It is an approach to IT operations security, allowing developers to utilize the principles and best practices of DevOps to ensure better, faster, and more secure software delivery. This essentially means that all security requirements are codified and weaved into the automated unit tests from the start, instead of having to deal with them before the product release.

DevSecOps is the trend to automate all security checks by codifying them in the unit tests and using them from the very beginning of the software development, not at the end of the cycle.

How is it different from DevOps? It is actually the same thing, the only point is that with DevOps the goal is to deliver the software as reliably and frequently as needed, not to mention ensuring its stable operation in production. With DevSecOps, security requirements are simply added to the fray, but the general workflow does not change a bit. How can this be done?

Here are six simple steps to DevSecOps. They are not easy, nor are they simple, but they help get the job done:

1. Audit the existing IT infrastructure and deal with flaws
2. Automate your security testing
3. Check the code dependencies frequently
4. Break the checks into manageable chunks
5. Integration with other DevOps tools is critical
6. Continuously train your developers to code securely

Below we briefly cover these main requirements and challenges on the path to DevSecOps.

Audit the Existing IT Infrastructure and Deal With Flaws

Before implementing something new, it’s useful to identify your current standing and the ongoing processes. Performing the audit of the existing IT infrastructure, systems and tools, processes and practices in place is a generally advisable idea. It is even more useful when you are planning to change the existing security procedures and checks.

The correct way to assess your infrastructure and its issues is to perform threat modeling — look at your systems from the attacker’s point of view and try to find the weakest spots. This allows designing the effective countermeasures for potential security breaches, removing the bottlenecks in the processes or removing the weak chains altogether. Threat modeling cannot be automated, yet it is an extremely useful exercise to keep your developers on the lookout for potential security vulnerabilities and avoid creating new points of breaching the product code.

Automate Your Security Testing

The next step after identifying the potential security issues and developing the solutions for them is codifying these solutions to be the part of automated unit testing for the new code features. This way, the security requirements are met from the start of the software development process, not left to be dealt with as the last thing before the release. As a matter of fact, the results of the Sonatype survey on QA and testing automation in 2017 show that nearly 40 percent of more than 2,300 QA specialists surveyed already run the automated software tests across the whole software delivery pipelines. Does your team do it, too?

However, this automation must be implemented with great care and caution. While running the Static Application Security Tests (SAST) in the testing and staging environments, make sure these tests are run against the latest additions to the codebase only. Otherwise, these tests will be too lengthy to be done during the nightly Canary deployments and will actually slow, not improve the software delivery process.

Do consider introducing the Dynamic Application Security Testing (DAST) practices to your workflows, if you did not do this already. Rather than checking the code in development and testing, this practice concentrates on checking the health and performance of the apps that run in production. There is quite a huge list of application vulnerabilities by OWASP, and protecting your product against them is a generally great practice. The tools like Sonatype, Selenium, Splunk, InSpec, Tanium, and others can help your QA team handle this step effectively.

Check the Code Dependencies Frequently

Cloud transition fueled the unprecedented growth of software development, as the IT industry was able to complete the projects faster and meet their customer requirements rapidly. To further empower this approach, using open-source software and modules become the main approach to software delivery because developing every module from scratch is essentially a waste of time and resources. However, using the third-party code means being dependent on its security flaws and vulnerabilities.

GitHub introduced the security alerting in 2017, so each project member is notified if the project they are dependent on is updated. Another way to do it is by using the OWASP Dependency Checker tool, which can be added as a plugin to most of the browsers.

Break the Checks Into Manageable Chunks

The biggest problem of introducing DevSecOps practices is the need to introduce them a bit at a time. There can be quite a long list of the required checks, but implementing them all in rapid succession will be a very daunting challenge for your developers. Instead, implementing only a couple of checks during each of the product development sprints allows the process to be much smoother and meet less resistance. This essentially gives the team time to cope with new tasks and weave them into the daily routine of the software delivery workflows.

Integration With Other DevOps Tools Is Critical

In order to be efficient, the security integration tool of your choice should work well with the rest of DevOps tools used in your company. This allows seamlessly integrating the security checks into your software delivery CI/CD pipelines and the cloud monitoring solutions used to maintain the performance of your production environment.

The best way to integrate these systems is through API interactions, which reduce the amount of configuration for each separate tool. Solutions like Splunk, Selenium, and other tools have clean and simple integrations with Kubernetes and Terraform, Jenkins and Ansible, ELK stack, Prometheus+Grafana, and other popular DevOps software.

Continuously Train Your Developers to Code Securely

Let’s take a brief look at the progress thus far. The system audit has been completed and the threat modeling helped detect and remove the potential security breaches; the automated QA and testing is in place, and the code dependencies on third-party modules are checked regularly; the security checks are gradually implemented across the software delivery pipelines, and the security monitoring tools are integrated with the other parts of your DevOps team toolkit.

One might think we are nearing the finish line… and they would be wrong. Because DevSecOps, just like any other process in the digital transformation endeavor, is not a one-time effort, but a long-term journey and company commitment. That being said, the next step of the cycle is ensuring that developers are using all the aforementioned tools and approaches permanently so that the security requirements are really taken into consideration from the very beginning of each project. Only when following this workflow becomes the only possible way of developing new software, you can be sure you are doing DevSecOps right.

Final Thoughts on DevSecOps

DevSecOps is not a tool, methodology, or project. It is the tectonic shift in business processes and corporate attitudes towards a DevOps culture, shifting the security checks to the left across the whole software delivery lifecycle. This is a complex and lengthy process, yet the rewards are quite tangible — better software delivery quality, more secure products, fewer issues in production, and mitigation of multiple other risks of software engineering.