Vulnerability Management: Best Practices for Patching CVEs

You’ve done your due diligence and followed best practices for scanning your environment to identify common vulnerabilities and exposures (CVEs). Now you’re staring at a long list of things to fix, with limited time and resources to boot. What next?

Once you’ve identified CVEs in your environment, it’s important to deploy patches as quickly as possible to mitigate risk and improve your security posture. In this article, we will offer some best practices and recommendations for patching CVEs as well as setting your teams up for success throughout the entire vulnerability management process.

Prioritize by Relevance and Severity

Software composition analysis and vulnerability scanners drown engineering teams in lots of detected vulnerabilities as each dependency of software libraries is scanned. To manage this, it is important to consider both the relevance and severity of the identified CVEs.

Relevance refers to how applicable a vulnerability is to the system or software package. A vulnerability that directly affects critical components or commonly used features should be given higher priority over less relevant vulnerabilities. For example, if a vulnerability in an SSL library is discovered in a software component that uses TLS/SSL to secure communications with other applications, the relevance of this vulnerability would be considered high.

Severity, on the other hand, pertains to the potential impact of a vulnerability if exploited, commonly known as the Common Vulnerability Scoring System (CVSS) score. Vulnerabilities with higher severity ratings, such as those that allow remote code execution or provide unauthorized access to sensitive data, should be addressed with greater urgency.

We recommend addressing critical and high severities first before moving to mediums and lows. Oftentimes, medium and low vulnerabilities are patched “in passing” as a result of addressing higher severity CVEs. Low and medium CVEs also have a higher chance of being disputed, reducing the criticality of the CVE.

Patch First, Analyze Later

Every CVE is unique in detail, attack vector, severity and impact/relevance to an application. Ideally, security analysts would analyze CVE details to determine whether identified CVEs are applicable to their software. For example, a CVE might only affect a function in a software dependency that is not being called or used, which would reduce the significance of the CVE to the application.

Vulnerability analysis is an important first step to determine the criticality of patching the vulnerability. Lower-priority patches still need to be addressed, but there might be higher-priority ones that need to be completed first.

In a perfect world, you would analyze all CVEs first to determine the priority order for patching. But this just isn’t scalable due to the sheer number of vulnerabilities and how frequently CVEs are discovered.

In reality, only a handful of CVEs actually affect your software. Of course, there’s no way to know for certain how a CVE affects your application until it has been analyzed, but because there are so many, including those from transitive dependencies, it is nearly impossible to analyze them all before new CVEs are discovered or in the time between a tight release schedule. Instead, we recommend you start by patching all critical and high-severity CVEs without analysis.

Shift Left

Preventing, detecting and patching CVEs needs to be a shared responsibility between developers and security teams. It is not sustainable for security teams to bear the responsibility of managing and patching CVEs alone. Development teams can often be hesitant to push frequent updates for fear that updates to software libraries will create bugs in their software.

It is important to be in agreement with development teams to have a testing program in place to ensure software quality is not affected by frequent updates and that frequent updates can be tested with ease.

To avoid a lengthy resolution process when it comes to patching CVEs, it is key to shift visibility and push vulnerability scanning closer to developers. This will ensure that processes are already in place to empower developers to proactively address CVEs and help monitor for secure code from the beginning of the development lifecycle.

For more on shifting left, read this free guide. 

Implement a Defense-in-Depth Approach

To implement an approach to reduce the risks of vulnerabilities in your software:

• Regularly scan your code libraries and base image at least once a week — ideally using more than one vulnerability scanner — to ensure libraries are not outdated. Note: It can take time after a CVE is discovered until it is added to the NVD database. In order to compensate for time delays/gaps between CVE discovery and publication, you should scan your code as often as possible, review potential vulnerabilities, and continuously update your software.
• Reduce your attack surface by trimming your base image of unnecessary or unused libraries to significantly reduce the number of vulnerabilities that would be detected in your application.
• Implement security policies and access controls to restrict access to reduce the risk of CVEs in your software by minimizing attack vectors in the application.
• Ensure proper authentication mechanisms are used between software components to reduce the impact of CVEs where authentication is required to exploit a vulnerability in the application.

What If There’s No Patch Available?

If there’s no patch available, you’ll need to carefully analyze the vulnerability and determine whether your software is affected by it. If it is, you’ll need to determine the extent of the risk (severity level), and then decide whether to remove or add mitigations to the affected components or wait for a patch to be released.

There are many factors that would determine your next steps, including how your software is consumed and whether the vulnerability affects your end users or customers. A software security company would likely be more conservative in its approach due to the risk of having an unresolved CVE in its software or application components that would affect customer systems. It is important to ensure that a vulnerability management playbook is in place to handle these situations that affect internal or external users, to give assurance and actionable steps to resolve these scenarios.

Read our guide to learn more about container vulnerability scanning.