CVE Severity & How To Respond To CVEs in Builds

In a-near perfect world, you would instantly fix your application every time a relevant CVE was issued. (In a truly perfect world, of course, there would be no security incidents, and hence no CVEs in the first place.)

But in the real world, reacting to CVEs requires a careful calculation. You need to assess whether each CVE is serious enough to warrant the rejection of a build and a delay of a release. That’s a careful balancing act — on the one hand, you don’t want to release code with serious known vulnerabilities, but on the other, you want to avoid constant delays caused by unexpected CVE announcements.

While there’s no one-size-fits-all answer about how to decide which CVEs are serious enough to warrant the rejection of a build, there are some key considerations that can help you make this decision. Keep reading for an overview of how to assess CVE severity.

Quick CVE recap

First, though, a brief definition of CVEs. Short for Common Vulnerabilities and Exposures, a CVE is a known vulnerability in a certain piece of software.

(Read our full CVE guide.)

The concept of CVEs were introduced in 1999 in an effort to provide a universal framework for identifying security issues. The idea is that whenever a vulnerability is discovered, a CVE entry will be created for it. The CVE entry can then be accessed and shared by the public. The official CVE list is maintained by MITRE, a nonprofit group who’s also known for the MITRE ATT&CK methodology.

The big caveat here is that the official CVE list does not include an assessment of the severity of each CVE. Other organizations that maintain their own lists of CVEs, most notably NIST’s National Vulnerability Database, assign severity categories (such as “medium,” “high” and “critical”) and/or numerical severity scores to CVEs.

How to react to a CVE

There are a variety of tools that will automatically monitor and scan your application code, dependencies or environments in an effort to detect components that are subject to known CVEs, then alert you to them. Thus, it’s relatively easy to find CVEs that are relevant to an application you develop or manage.

The harder task is what to do when you discover a CVE that impacts your application. As noted above, it’s not always practical to delay the release of your application until the CVE is addressed. Importantly, though, patches to correct CVEs sometimes appear almost as quickly as a CVE is announced. In some cases, it can take months or longer before a CVE solution becomes available (and it’s not always clear how long it’s going to take for a fix to arrive). You may not be able to wait that long.

Also, you may simply get so many CVE alerts that delaying a release in response to each one is not feasible. If your application is complex and has lots of dependencies, you could get multiple CVE alerts each week. Delaying your release pipeline in response to each one would create a lot of confusion and impact your ability to deliver continuously.

So, how should you react when a CVE is announced? Let’s look at the three most common approaches:

• Policy-based CVE management
• Case-by-case CVE management
• The hybrid approach

A conservative approach: Policy-based CVE management

The first approach to CVE management is to maintain a consistent policy where, based on a CVE’s severity rating, you always handle a CVE announcement in the same way. For example, you could enforce a rule where any CVE with a severity ranking of medium or greater means your delivery pipeline will be put on hold until the issue is addressed.

This approach is conservative because it involves applying a blanket policy to all CVEs. You assume that every CVE of a certain type is serious until proven otherwise. The upside of this approach is that:

• It’s consistent and therefore easy to automate.
• It also allows you to err on the side of prioritizing security over delivery speed, which may be desirable if you’re particularly risk averse.

The downside to strict policy-based CVE management is that you’ll likely end up delaying your releases in response to CVE announcements that don’t have an actual impact you. The severity assessments from NIST and other organizations are useful but they’re also generic and subjective. Just because a given CVE is deemed critical, for example, doesn’t mean it’s actually critical for your particular configuration.

Keeping all this in mind, if you require all CVEs with a certain severity level to be addressed before you resume software delivery, you may end up with unnecessary delays.

A flexible approach: Case-by-case CVE management

The other CVE management strategy is to assess each CVE on a case-by-case basis, then determine a course of action. This strategy is more flexible — and it also involves taking more risks.

This strategy can’t really be automated. It requires your security engineers to:

1. Read each relevant CVE alert, no matter the time of day or night.
2. Make a decision about whether it’s serious enough to delay a release.

This approach may also be inconsistent. One security engineer may have a different take on the seriousness of a given CVE for your project than another.

On the other hand, a case-by-case approach is more flexible and provides the ability to maintain release speed even in the face of recurring CVEs. It’s the only way to react to CVEs based on how much they impact your application or configuration, rather than on the basis of generic assessments from third-party organizations.

The hybrid approach

It’s worth noting, of course, that the two strategies described above don’t have to be an either/or proposition. You can combine them to develop a hybrid CVE management strategy.

For example, you could…

• Use a policy-based approach where you delay the release for all CVEs with a critical severity ranking, and then a use case-by-case assessment to make determinations about those that fall between medium and critical.
• Provisionally delay releases in response to all CVEs with a severity ranking of medium or higher, and then assess them individually in order to decide what you want to do on a case-by-case basis.

How to manage CVEs

At the end of the day, your team must manage CVEs in their own way. There’s no universal advice about which of the strategies described above works best. However, considering these factors can help you determine your most appropriate approach.

(Understand how CVEs fit into overall vulnerability management.)

How serious is a security issue for you?

Security issues are always bad. But, they tend to be worse for some organizations and industries than others. If you’re developing a finance app, for example, you’ll probably need to be more conservative in the way you handle CVEs than you would if your vertical is less regulated.

How easily can you roll back a release?

Some delivery pipelines make it easier to roll back a problematic release than others. If you use immutable infrastructure, for example, it’s probably easier to replace one version of your app with another.

If you can roll back quickly and easily, you may be able to take more risks when it comes to CVEs because you have a greater ability to pull a release quickly in the event a CVE you chose to ignore turns out to be serious.

How much in-house security expertise do you have?

Not everyone is equally qualified to interpret the severity of a CVE.

• If you don’t have the right (or enough) security experts in house to assess a CVE’s impact quickly, you may be better off taking a conservative approach and assuming that all CVEs should be treated seriously.
• If, on the other hand, you have the expertise to interpret CVEs quickly and meaningfully, you’re better positioned to assess them on a case-by-case basis.

(See how DevSecOps builds security into code earlier.)

How often do you release?

Finally, consider how quickly you typically release application updates. Continuous delivery means wildly different things to different teams.

You might only be releasing once a week in which case delaying a release by a day or two in response to a CVE isn’t a big deal. On the other hand, if you release every hour, hitting the pause button due to a CVE is much more disruptive to your routine (and to your users, who are probably accustomed to rapid updates).

CVEs can sometimes be tolerated

CVEs are serious business. But just how serious a CVE is for your team and project can range widely. Having a healthy perspective on your ability to tolerate CVE-related delays is critical for ensuring you successfully navigate the straits separating CVE obsessiveness from a fundamentally insecure CVE policy.

What is Splunk?

This article was written by Chris Tozzi. Chris Tozzi has worked as a journalist and Linux systems administrator. He is particularly interested in open source, agile infrastructure and networking. He is Senior Editor of Content and a DevOps Analyst at Fixate IO. His book For Fun and Profit: A History of the Free and Open Source Software Revolution was published in 2017.

This posting does not necessarily represent Splunk's position, strategies or opinion.