The state of DevSecOps: Why upgrading your AppSec tooling is essential

DevSecOps started getting written and talked about a decade ago, and today many companies are paying attention to the best-practices recommendations put forth in the press and conferences. In fact, a report released by GitLab earlier this year showed that, as of last year, a majority of companies — 56% — say they lean on DevOps or DevSecOps methodologies.

But how good are they at blending security into DevOps practices and baking security checks and remediation into the continuous development lifecycle? Recent studies from GitLab, the SANS Institute, the Cloud Security Alliance, and, most recently, Datadog shows there's still a lot of work to do. Specifically, the studies found that organizations are relying too much on old-school application security tools and mentalities, they are beset by code complexity, and they lack visibility into the software supply chain — factors that all are blocking DevSecOps maturity.

Here's a deep dive into what's holding DevSecOps back as laid out by the most recent research — and why modernizing application security (AppSec) tooling is key in the software supply chain security era.

Get RL's new essential guide: Software Supply Chain Security for Dummies

Accelerating modern tool usage is key

Many organizations today are still struggling to modernize their security tooling to match the scale and pace of DevSecOps software delivery, as well as the attack environment.

In its "State of DevSecOps" report, Datadog examined trends across tens of thousands of applications and container images and thousands of cloud environments. It found that automated security scanners are alerting to too many attack attempts, creating a lot of inactionable noise for defenders. When just roughly 0.0065% of alerts are tied to successfully triggered vulnerabilities, the need for alert prioritization that's fueled by things such as threat intel and application runtime context is clear.

This need for prioritization trickles into AppSec work across the DevSecOps lifecycle. The study found that only a small sliver of vulnerabilities found through traditional security scans are worth prioritizing. When organizations adjust for runtime context, 63% of organizations with critical CVE severities could eliminate these critical vulnerabilities. And one in three organizations were able to use this prioritization to reduce their critical flaws by half or more.

The problem is that most organizations today use static application security testing (SAST), but other tooling such as software composition analysis (SCA) and runtime application self protection (RASP) are not the norm. The SANS Institute found in its most recent "State of DevSecOps" report that less than a third of organizations use some kind of operational runtime protection or shielding today. Meanwhile, that study found that only about 22% of organizations today use SCA for three-quarters or more of its codebase today.

Go beyond shift-left lip service and modernize your approach

Complex binary analysis is one area of AppSec tooling modernization that the Enduring Security Framework (ESF) public-private working group is promoting. It believes that complex binary analysis is a must-have backstop for AppSec's current shift-left focus.

In itself, shifting left, so that security flaws are addressed earlier in the software development lifecycle (SDLC), can be beneficial, and many DevSecOps practitioners have adopted it. The GitLab report shows that 74% of security pros say they've shifted left or plan to do so in the next year. And a similar percentage (71%) say at least a quarter of all security flaws are now being spotted by devs as a result of shifting left, way up from 53% a year ago.

At the same time, though, shifting left isn't necessarily translating to a shift in positive AppSec outcomes. In its "State of Security Remediation" report earlier this year, the Cloud Security Alliance found that one in three organizations say that over 40% of their code contains flaws. And half of the flaws that organizations address end up reoccurring within a month of remediation.

As important as it is to test early, doing it often and doing again at the end of the build is equally important for holistic visibility and management of AppSec risks. This will be a crucial way for DevSecOps teams to get beyond shift-left lip service and start achieving continuous AppSec security measures all the way to the right-hand side of that SDLC timeline.

Saša Zdjelar, chief trust officer for ReversingLabs, said that as you shift right with a final exam for any software in use in your organization before deployment, you lose some visibility — but you gain context as people add first-party and third-party commercial and open-source code.

What I think is missing in the SDLC of these producers, as well as on the consumer side, is the very, very last check of whether you are shipping a safe product when everything is built.

Saša Zdjelar

The ESF's most current recommendations specifically call out the need for using binary composition analysis as a sort of final exam before a completely assembled piece of software goes live.

Start battling software complexity

Another one of the big blockers for effectively baking security into DevOps and agile development practices is the sheer complexity and volume of code today. While trends toward microservices and containerization have made it more flexible than ever to build out modern software, it has also contributed a great deal toward code bloat — not to mention a complicated mesh of dependencies and connections — all of which keep expanding the application attack surface.

Complexity adds to the attack surface, but David Brumley, CEO of ForAllSecure, said the problem is even more insidious.

It sometimes adds to the attack surface — but it always adds to the perceived attack surface for software composition analysis and other security tools. So that bloat makes your AppSec results cluttered with false positives, erodes dev/security trust, and slows down velocity.

David Brumley

Brumley said that managing component usage and using SBOMs to validate what really needs to be included and what can be trimmed is a good step toward battling complexity, as is using "distroless" approaches to container images.

The latter was covered in the Datadog study, which provided some solid, data-backed evidence that lightweight container images lead to fewer vulnerabilities. The study showed that container images smaller than 100MB have, on average, 4.4 high or critical vulnerabilities, almost 10 times fewer than in images that sit between 250MB and 500MB. Those had 42.2 critical vulnerabilities on average. Containers bigger than that suffer from an average of 80 critical flaws.

Make those SBOMs actionable and automated

Cutting through complexity to get a bead on supply chain risks is still a huge challenge for DevSecOps.

"DevSecOps teams should continue to invest in tools that help to ensure the security and integrity of their applications and all the dependent components in their software supply chains," recommended Ben Allen and Chris Edmondson in the SANS report.

As mentioned above, the SANS study shows that SCA hasn't yet reached a critical mass for usage — but digging into its numbers a bit more, it becomes clear that momentum is rapidly building. The ratio of organizations that use it for half or more of their code improved by almost 20 points — from 25% in 2022 to 45.2% last year.

One of the keys to getting more out of this kind of tooling is to leverage software bills of materials (SBOMs) to power automated testing. There's still a lot to be done in order to make next-gen SBOMs actionable and automated. This includes improving the state of standardization and shareability of SBOMs, which will greatly aid in automation. It also potentially means getting creative with how SBOMs can be used, for example to go deeper and utilize it to inform threat modeling activity.

Chris Romeo, CEO of the threat modeling firm Devici and a co-author of the Threat Modeling Manifesto, said SBOMs can inform the threat model with better data.

As a threat modeling person, the more intelligence I can gather about the thing that's being built, the more my brain starts churning on potential threats and then ultimately mitigation.

Chris Romeo