The five stages of vulnerability management
Nearly every organization today builds a lot of software, and the majority of that software is developed by cobbling together open source components. When using open source and trying a software composition analysis (SCA) scanner for the first time, it is not uncommon for those organizations to be surprised at what they learn about their open source usage. Many times it quickly comes to light that they have a large load of new and unplanned work to address in the form of security issues in dependencies. They need to fix these issues not just for the organization itself but also to stay compliant with certifications such as PCI or SOC2.
That’s when these organizations begin to experience the five stages of vulnerability management.
Denial
“What do you mean there are 1000 different vulnerabilities deployed across my infrastructure? That can’t be right!”
Sadly, this is true, and especially in legacy codebases, this can be a common occurrence. Code that hasn’t been touched or maintained in years and has out-of-date dependencies may suddenly become vulnerable to a newly discovered issue. If you haven’t tried to keep track of where vulnerabilities may affect your organization, you may be shocked as to what you see.
But shock quickly turns to…
Anger
“Look at all these vulnerabilities! Open source security is a mess!” The thing is… open source security really is not a mess.
We just don’t see many random open source vulnerabilities causing the latest round of data breaches and ransomware attacks. The majority of high-profile breaches in the last year have been caused by things like missing 2FA and reused accounts of ex-employees. The biggest, most expensive, risks to your organization aren’t from the vulnerabilities found by these SCA scanners. It’s from internal misconfigurations, bad policies, and other issues. No criminal is going to enter a house via a loose floorboard if they have access to a key.
But even looking at actual open source vulnerabilities… An analysis of over 120,000 widely-used packages shows that less than 0.21 percent of them have an unfixed vulnerability, and over half of those are because the package is not being maintained at all. When maintainers have the ability to maintain the software, vulnerabilities get fixed and patched regularly.
If you have 1,000 instances of vulnerabilities showing up in your software, it’s not because the open source you’re using is insecure. It’s likely because you’re not actually staying up to date on recent releases that actually have fixes.
So, once the anger subsides, we move to…
Bargaining
“Well maybe I don’t have to fix them! I’m sure we’re not affected by them all; we’ll just fix the ones that are high priority. We can justify where we’re not affected.”
Fixes can be overwhelming and it would be easy to try to just fix the high priority vulnerabilities. And it’s true; not every vulnerability will affect you in every situation. Some may be false positives. Others may impact code paths that you’re not using. Or maybe it’s a low severity vulnerability, and you’re willing to live with the risk. You might even use formats such as VEX to document where you don’t think you’re affected.
So you eliminated a set of false positive and low priority vulnerabilities.That’s great: you’ve cut the number from 1,000 down to, say, 60. But you’ve still got 60 high priority vulnerabilities to fix across your infrastructure.
When staring at those 60 vulnerabilities, which could be in multiple software systems, you may feel…
Depression
“What am I going to do? We’ll never get this work done!”
Why does the thought of applying a number of fixes for vulnerabilities cause you to feel depressed? This is a sign that something is wrong in your engineering organization. After all, the goal of the engineering organization is to build and operate code, and that requires being able to perform change on a weekly, daily, and hourly basis.
To get past this stage, you’ll need to diagnose and fix what’s causing your organization’s engineering brain to not function properly.
Is your team unable to ship changes because they’re constantly under stress from the organization’s conflicting needs? Well, you’ll need to change your deadlines and expectations to ensure that engineers have the time to get work done.
Is your team unable to verify new versions with a vulnerability fix because there is no confidence that a change will work? You’ll need to have tests that allow you to verify any change easier.
Is your team unable to perform fixes because your developers don’t have the information that they need? You’ll need to figure out how to communicate security information to them in the tools where they work.
There are no quick answers or easy fixes in this stage. Many organizations get stuck in this phase, where there’s a constant pull between the security organization and the engineering department. Meanwhile, the backlog just gets larger.
However, if you are able to build this sort of resiliency and engineering velocity, you can then move to…
Acceptance
“OK, we’re up to date. That was painful, but we’re ready for the next vulnerability whenever it happens.”
Mature organizations accept the reality of dealing with vulnerabilities. When you're in a mature organization, you don't deny that vulnerabilities occur, don't succumb to anger when informed of them, don't attempt to bargain your way out of fixing things, and aren't depressed about having to do the work.
You know how to be reliably informed about what vulnerabilities you may have to deal with. You know how to prioritize what the most important thing is to fix. You know you have the capacity to deal with sudden events and ship fixes throughout your organization at a moment’s notice.
Congratulations: you’ve reached the end stage! When the next Log4Shell or Heartbleed is discovered, you know you’ll be ready.
Image Credit: Elnur / Dreamstime.com
Bill Nottingham is a principal product manager at Tidelift. He has 20+ years of experience in development and product management, and has served on security response teams at multiple organizations.