DEVOPSdigest

Writing more secure software code has become not just an enterprise but a national imperative. In May 2021, US President Joe Biden issued Executive Order 14028 focused on improving the nation’s cybersecurity. "There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended," stated the order. "The security and integrity of 'critical software' — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern."

A reactive approach to cybersecurity does not work. The number of disclosed software vulnerabilities has set records for the previous four years, hitting 28,000 in 2021. Anecdotally, attack severity appears to be increasing. Ransomware gangs are now targeting entire countries!

The focus of software security must be proactive. Ideally, this would mean making it easier to write more secure code and creating an environment where more secure coding practices are easier to implement and follow.

Equally important, is creating more efficient ways to scan and test code, identify and prioritize vulnerabilities to fix based on the real impact they may have on production applications. This should be a shared project between Development, AppSec, and DevSecOps teams. For the most part, these teams have continued to struggle to work together cohesively and efficiently to reduce application security risk. In order to move the needle on secure programming, there needs to be a shared understanding of the goals of an improvement program and what it will take to get there.

There are four rules we found when we analyzed results from millions of scans from May 1, 2021 through April 20, 2022.

1. Faster Scans Leads To More Scans

During the time period covered by the report, scan speed increased significantly. Average time to complete a scan fell to an average of 90 seconds, a 50 second year-over-year reduction. Scan times also fell for compiled languages, decreasing by more than 3 minutes. Compiled languages are generally more complex to scan. Faster scans in general led to more code scanning.

2. Scan code more frequently

During the survey period, AppSec teams ran daily scans 68% more frequently than in the previous period. This speed is important because when scans are faster and more frequent, developers are more likely to get the results quickly and fix issues quickly while the code is still fresh in their mind. This prevents issues from becoming technical debt.

3. Prioritize Vulnerabilities More Effectively

By applying better prioritization technology and methodology, AppSec teams can more effectively identify vulnerabilities and library updates that actually moves the needle on risk. For example, vulnerabilities that an attacker can actually leverage to breach an application should be prioritized higher than any others. We call this metric "attackability."

For the most part, AppSec teams have traditionally ranked and prioritized security scan findings based on the severity of the vulnerability or the importance of the library. This approach too often resulted in a "fix overload" that created lists of problems to be fixed that far exceeded what Dev teams could realistically ever fix. It is possible to programmatically measure attackability by analyzing results from both SCA and SAST scans, and then identify which attack vectors have clear data paths into applications. (Hint: many do not have those attacker-reachable paths and are actually not an immediate risk).

4. Fix the most vulnerable code more quickly

Using attackability criteria and deploying technology that prioritized what to fix based on this metric, Dev teams saw a whopping 97% reduction in tickets during the study period. Not surprisingly, this allowed them to complete code fixes far more quickly — on average in two sprints, during the period studied. Mean-Time-to-Remediation fell by 37%, from 19 to 12 days. In other words, Dev teams were able to focus on fixes that mattered and quickly address them, improving the ongoing security posture maintenance for applications.

Conclusion: Move Faster Without Sacrificing Code Quality

The premise of shifting security left is accelerating code production without sacrificing quality or security. The reality of software development is that the earlier and faster that issues are found, the easier it is to fix them. This is how smart organizations can operationalize shifting left.

When shifting left is done right, fixes are made while code remains fresh in the minds of developers. Application methods and data paths can be modified (or sanitized) to achieve the same result with less risk. Issues fixed faster and more comprehensively translate into less technical debt to deal with later. None of this works if developers have to wait for hours or even days to get scan results and then sift through a stack of findings that AppSec says must be fixed which, in reality, the Devs know may not be critical. For their part, DevOps practitioners also benefit when the process of adding application testing to software deployment pipelines is painless and quick.

The imperative to successfully shift security left, scan more, scan faster, and scan better grows even more urgent as applications are transitioned from monolith to microservices.

The upshot? AppSec, DevOps and Dev teams that can scan faster and prioritize better will enjoy an even greater advantage in efficiency, quality and security with less effort as the pace of software development continues to accelerate in the coming years.