There’s been a lot of hype around the “shift left” approach of bringing security into the software development lifecycle (SDLC) earlier than with traditional methods, and rightfully so. It’s an important change, as it gives security the attention it deserves throughout the entire SDLC, while speeding up security processes and creating more secure products. 

But the shift to DevSecOps is still relatively new. The 2019 State of Web Application Security Report discovered that only 21 percent of respondents have had a DevSecOps team in place for more than two years. 

Here’s a quick look at why you should make the move to DevSecOps and a best practices guide to help you integrate security into the DevOps process. 

Why move from DevOps to DevSecOps

There’s a reason more companies are incorporating security into DevOps. It just makes sense to include security in the design and development process from day one. A DevSecOps approach is beneficial to both your internal teams and to your customers. 

The primary benefits of adopting a DevSecOps approach are:

  • A more secure product—When you integrate security into the development process from day one, issues are identified and resolved faster. This leads to more secure software being released.

  • Faster time to market—A DevSecOps approach fosters stronger collaboration between the security and development teams. Increased cooperation results in faster remediation of security issues and vulnerabilities, supporting the Agile methodology. This enhanced speed extends beyond the initial launch, with DevSecOps also enabling teams to release updates to applications at a faster pace. 

  • Cost savings—Waiting to fix security issues at the end of a build requires more time and money. When bugs and vulnerabilities are identified continuously throughout development, less code is involved in the remediation process. Fixes that involve less code are less complicated and less expensive. 

  • Improved compliance—If you operate in an industry that requires compliance with such regulations as HIPAA or PCI DSS, a DevSecOps approach checks for compliance every step of the way. You run a lower risk of a violation (and the associated fines).  

Best practices for moving from DevOps to DevSecOps

Automate as much as possible 

DevOps focuses on speed, with developers trying to produce code quickly in short Agile sprints. In order to add security development into this process, it also needs to move quickly.

Automating security testing is the first place to start. There are a wide variety of automated application security testing tools, including Static Application Security Testing (SAST) tools, Dynamic Application Security Testing (DAST) tools, and Interactive Application Security Testing (IAST) tools. SAST tools test the application from the inside out. They go through the code, line by line. DAST tools, on the other hand, test the application from the outside in. These tools try to penetrate the application while it is running. IAST tools run inside the application while it is running, looking for vulnerabilities. 

Across all of these AppSec testing tool categories, there are both open source and commercial options. But no one tool provides comprehensive coverage. For example, each SAST tool only discovers approximately 14 percent of the vulnerabilities in your code. This is why it’s so important to use more than one type of tool. However, you don’t want this to slow down the development process. Automation enables you to use all the necessary testing tools for comprehensive vulnerability coverage without sacrificing speed. 

It is possible to implement automated scans, so they help keep up with the speed of DevOps. And you don’t need to run an automated scan on your entire codebase each night. It’s more efficient (and just as effective) to run the scan only against the new code that was created since the previous test. This keeps the results manageable, so your team can take care of required fixes without slowing down the build. 

Leverage DevSecOps tools 

The results from your various application security tools can still slow security (and DevOps) down, because the results need to be de-duped and correlated before developers work on them. The right application security workflow management tool will be able to correlate the results from automated (and manual) testing tools quickly and create a single set of results. 

Some tools also have a feature that cross-references results from SAST and DAST tools, thereby identifying which potential vulnerabilities are actually exploitable. Your team can prioritize these issues, making sure the most serious threats are addressed first. 

More robust security workflow tools utilize orchestration and smart automation to give you tighter control over the AppSec process, including a consistent application security process that can be used across multiple development teams. Orchestration makes it easy to incorporate new applications into the security pipeline and reduces the time needed to install, configure, and update AppSec testing tools. 

Security teams can also run extensive tests across all build servers without slowing down the development process. In other words, AppSec can keep up with DevOps

Foster collaboration between security and development 

Historically, it hasn’t been easy to get developers and security teams to work together smoothly. Just because you tell a developer about a vulnerability doesn’t mean it will be fixed promptly. Developers are often focused on the next build, rather than on issues in the previous code release.

The best way to overcome this hurdle is to make it easier for developers to address security issues that have been identified. An application security workflow management tool can help here as well if it integrates with popular developer tools such as Azure DevOps. Developers can stay in their preferred working environment and still address security issues that arise. 

Remediation then becomes part of the workflow rather than a detour. Security testers can even assign tasks to developers and track progress to ensure issues are addressed in a timely manner. 

Educate developers to gain buy-in 

Developers often see security team members as a roadblock—something that slows them down and prevents them from meeting deadlines. When you educate your developers on secure coding practices and why they are important, they gain a better understanding of why security is an integral part of the development cycle. 

Ongoing education serves two goals: 

1. Developers write more secure code from the start, so there are fewer bugs to fix. 

2. When a vulnerability is discovered, developers are more likely (and able) to correct it, since they have a deeper appreciation for the importance of secure coding.   

Conduct code dependency checks regularly 

In order to build applications more quickly, many organizations leverage third-party open-source application components. While it is wise to save time by repurposing work that has already been done, you do need to make sure these components are secure. 

Research has shown that unpatched vulnerabilities in third-party libraries account for 21 percent of application vulnerabilities. You need to know if any of the open-source components in use contain vulnerabilities—and the impact they can have on code that is dependent on those components. Code dependency checks are the best way to make sure the open-source components don’t contain any known vulnerabilities. 

The OWASP Dependency Check is an example of such a tool. It scans your code and open-source components against a list of known vulnerabilities. Some application security workflow management tools also check third-party components for vulnerabilities through Software Composition Analysis support. 

Implement threat modeling

Threat modeling is the process of identifying and prioritizing threats and vulnerabilities in your application and helps you mitigate them. A typical threat model answers such questions as:

  • What is being built?

  • What can potentially go wrong with the product/application?

  • If something does go wrong, what should we do about it?

While this is a manual process, it’s an important part of secure design and development. A threat model helps teams accurately prioritize threats and the resources required to address them.

Threat modeling brings developers and security team members together to work on a living document. It helps developers see the application through the eyes of an attacker. This encourages more communication between these often-separate groups, and helps each side appreciate the importance of the work done by the other.  

Monitor and scale 

The DevSecOps approach needs to be scalable across the enterprise, regardless of how many development teams you have working on various projects. Scaling is streamlined once you adhere to the best practices outlined above.

Automated testing, collaboration, and the use of DevSecOps tools that optimize pipeline management make application security a repeatable and scalable process that can be integrated into a true DevSecOps approach across the entire organization. 

Organizations that adhere to these best practices will be able to make the transition from DevOps to DevSecOps faster, thereby reaping the benefits of integrating security into the development lifecycle without sacrificing speed. 

If you’d like to read more about application security, join our mailing list. We send an email each month notifying you of the latest content we have published, so you can stay on top of important AppSec issues.