Application security teams have often struggled to keep up with the rapid code releases produced by DevOps teams. Testing inevitably falls behind as development speeds up.
It’s difficult to go back through the application code and remediate every possible issue later in the development cycle. Reviewing and fixing vulnerabilities in code that may have been written six months before isn’t easy, and developers typically don’t want to address code that works just because there may be a security risk. The result is that insecure software is often released, which increases the risk for a breach.
The solution isn’t to slow down development so security can catch up; instead, successful application development demands a synchronicity between speed and security, with both speed and security getting the constant and equal attention they deserve. The harmonization between speed and security is the reason behind the shift to DevSecOps.
Many companies are in the process of making this shift. A recent report from Gartner uncovered several key data points that demonstrate the acceleration in the transition toward this application security best practice:
- 90% of software development projects will claim to be following a DevSecOps model by 2022 as compared to just 40% in 2019
- 70% of DevSecOps initiatives will incorporate automated security vulnerability and configuration scanning by 2023 as opposed to just 30% in 2019
- 60% of rapid development teams will have embedded DevSecOps practices by 2021, compared to 20% in 2019
These plans are promising, but a true DevSecOps approach that fully integrates security into the design and development process can be challenging for many organizations. Comprehensive application security testing is time consuming and resource intensive. Analysts must assess vulnerabilities across all attack surfaces, including custom code, third-party components, and the network where the software application will reside.
AppSec teams need to run a variety of tools, including:
- Static application security testing (SAST) tools
- Dynamic application security testing (DAST) tools
- Interactive application security testing (IAST) tools
- Software composition analysis (SCA) tools
- Threat modeling tools
In addition to running the tools listed above, AppSec teams also use methods, such as:
These tools and reviews usually run at different times and frequencies, depending on where a given project is in the software development life cycle (SDLC). Many AppSec tools are complicated to configure and run. Onboarding and maintenance take time, and AppSec teams are encouraged to run multiple tools in the same category, such as multiple SAST tools and DAST tools. One software development project may require dozens of tools over the course of the SDLC, and each one has its own user interface (not to mention peculiarities).
Oftentimes, the same tools are used on multiple projects, requiring multiple configurations. Tools that don’t integrate with each other give inconsistent results, with reports in different formats. It can take weeks (or longer) to identify false positives and to correlate and prioritize results.
Additionally, many enterprises manage more than one build server. There may be hundreds of Jenkins servers, for example, in addition to multiple instances of TeamCity, Azure, and other services. It’s just not possible to bake application security into each one of these systems without orchestration.
Compounding the issue is a low ratio of security team members to developers. Developers outnumber security team members at a ratio of 100:1. When you consider how quickly each developer works, security doesn’t have much of a chance to identify and remediate all the potential vulnerabilities.
It’s no wonder AppSec can’t keep up with development teams and track vulnerabilities efficiently.