The vulnerability management dilemma: Visibility without control

Every company that builds software – whether for internal tools or SaaS products – has implemented some form of vulnerability management. Why? Because every one of these organizations understands that the software they build relies heavily on open source packages, which inherently come with vulnerabilities.

With studies showing that more than 90% of software is built with open source components, it’s no surprise that such great effort goes into minimizing inherited vulnerabilities. The problem is that as software development continues to accelerate – especially in the age of cloud and AI – the number of vulnerabilities discovered daily continues to grow. And security teams simply can’t keep up

And because security teams want to be enablers, not roadblocks, this critical issue is often overlooked, leading to growing security debt across organizations.

The universal vulnerability management struggle

Over the past few years, we’ve met with hundreds of organizations, including dozens in the Fortune 100. Regardless of size or industry, they describe the same challenge: managing vulnerabilities at scale.

Let’s break down how the process generally works today:

Today, cloud security platforms like Prisma, Orca, Aqua, and Wiz identify vulnerabilities in the cloud, while AppSec tools like Snyk, Mend, and Checkmarx discover them in the building stage. Using context from the cloud – and in more mature companies, sometimes even from runtime (if the vulnerabilities are actually running and loaded into memory) – teams go through a process of prioritizing how significant the vulnerability is to the organization, and then a ticket is opened for the developer.

Sounds straightforward, right? But what happens when the vulnerability can’t be fixed – either because there’s no patch, or applying the fix would break the application? Worse yet, what if the vulnerability originates from a base image? Now the ticket moves to the DevOps team, which may not even have a solution. Then there are times when a feature is rushed to release, leaving no time to triage tickets at all.

These are just a few ways the process breaks down. But regardless of the specific failure, the result is the same: in the era of the cloud and AI, organizations are accumulating an ever-growing backlog of unresolved vulnerabilities.

The turnover challenge

Compounding all of this is the reality that people join and leave teams all the time. And when it comes to vulnerability management, this exacerbates the challenge given that when AppSec stakeholders leave, it’s that much harder to preserve institutional knowledge and maintain a stable, effective process.

I saw this firsthand while working with one of the largest banks in the world. After months of effort, the AppSec team had finally developed a system that worked well with engineering – balancing which vulnerabilities could be safely accepted as exceptions and which ones needed to be fixed. But when two critical team members left, their replacements lacked the context and experience to manage those decisions. The process quickly unraveled, and vulnerabilities began to pile up at an alarming rate.

Code to Cloud: risk prioritization

One of the most common modern approaches to vulnerability management is known by the industry phrase "Code to Cloud." It’s a strategy focused on risk prioritization – not addressing the vulnerabilities themselves. That is to say, it’s simply been accepted that the number of vulnerabilities is only going to increase and certain ones are not worth fixing.

First, we’ll only try to fix what’s running in production, and within what’s running, we’ll prioritize the highest risks. Cloud platforms provide context about internet exposure and runtime behavior to help narrow down priorities. But these processes are highly complex and require several tools to communicate with one another, which means they usually lack the business context regarding which application is most critical for the organization to secure.

The update repeat approach

Another approach to the vulnerability management challenge actually doesn’t stem from security –  it comes from the world of software. The idea: stay updated. If developers always use the most up-to-date packages and infrastructure, security updates come automatically.

The problem? This approach requires significant ongoing effort from developers, who are already stretched thin, because it may wind up breaking the app.

The foundational solution: addressing the source

Just as organizations don’t write their own databases, the market is now seeing that they shouldn’t need to solve inherited vulnerabilities on their own. A new solution has entered the mix that provides clean infrastructure from the start – CVE-free commercial base images, open source lean distros, and clean commercial open source libraries.  

Since around 80% of vulnerabilities in containerized applications come from base images, switching to clean, enterprise-grade images can dramatically reduce your security debt. This approach can be done in-house (though it’s very tough) or be done commercially. And clean commercial open source libraries are a great way to address the other 20% of vulnerabilities that come from application code.

What’s next for container security?

Cloud security and AppSec platforms have given teams visibility like never before. But visibility alone doesn’t solve the problem – most organizations rarely have the resources or processes needed to address the vulnerabilities they see.

That’s why, as the market continues to evolve, secure-by-design approach may just be the answer – enabling teams to start clean, stay clean, and only try to fix what they can control themselves.