7 Building Blocks for CVE Prioritization

Welcome to part two of our three-part series on bringing a structured approach to securing embedded Linux devices.

The previous post outlined key questions you can ask to fully understand your threat landscape. Now let’s address the next step: What do you do with all the CVEs (Critical Vulnerabilities and Exposures) you encounter?

A quick look at the numbers highlights the problem. In 2022, more than 25,000 CVEs were identified. Of course, not all of these apply to every platform, but a modern-day platform can be vulnerable to 1,000 or more CVEs, based on the 100+ packages typically included in a solution.

That means vulnerabilities can’t all be fixed immediately. Research shows that firms are able to fix some 5%–20% of CVEs per month. Setting aside the time and cost of making even that comparatively small number of fixes, think about the overall risk to your organization. All it takes is one missed security breach to compromise your data, disrupt your operations, and damage your reputation.

You need a strategy for handling the CVEs your system will be exposed to. Here are 7 key building blocks to understand when prioritizing CVE remediation efforts.

1.     Impact: Understanding the potential impact of a CVE on the system starts with the affected component of the system that would be impacted. If it’s a critical component, for example the Open SSL, X.11, a kernel library, or a widely used package, the impact could be significant. The next consideration is the exploitation method, or the different attack vectors of the CVE. If the vulnerability can be exploited remotely without any user interaction at a low priority, it could have a more significant impact than a vulnerability that requires physical access to the system. You should also consider the potential use case or scenario in which the vulnerability can be exploited. For example, if the vulnerability allows an attack to execute arbitrary code, the impact could be severe.

2.     Exploitability: CVEs with publicly available exploits should be given priority over those that are not easily exploitable. There are tools available to help you gauge this. The CISA website, for example, offers a Known Exploited Vulnerabilities Catalog. Another option is the Exploit Prediction Scoring System or EPSS score, provided by the EPSS special interest group as part of FIRST.org, which assesses a CVE on the likelihood that it will be exploited. Again, the goal is to focus on high-risk vulnerabilities so you can mitigate them quickly.

3.     Criticality of the system: Assessing system criticality is a key building block because vulnerabilities that could expose sensitive data or result in financial loss should be given priority in remediation.

4.     Ease of remediation: Those vulnerabilities that can be remediated quickly, either with a vendor patch or a work-around, should be given high priority. But how do you know which ones can be remediated quickly? Wind River® has developed a professional-grade CVE scanner, a Yocto Project build layer that is publicly available and supports most, if not all, Yocto Project solutions, including Wind River Linux. The scanner can quickly identify CVEs on legacy Linux platforms and determine which have solutions readily available such that remediation can be prioritized. The scanning itself can be performed by your own staff or by Wind River experts as part of our Wind River Studio Linux Services portfolio of offerings. Try the scanner today.

5.     Compliance regulations: Government agencies are steadily increasing their security requirements, and many of them are now mandating a Software Bill of Materials (SBOM) — essentially a list of ingredients that make up software components and an outline of requirements for analyzing and remediating security vulnerabilities. This is actually good news for software providers, because an SBOM makes it easier to ensure that the software components are up to date and respond quickly to new vulnerabilities. This, in turn, makes it easier to reduce and manage technical debt.

6.     Age of vulnerability: Unpatched vulnerabilities that have been around for a long time that meet your prioritization criteria should be given significant attention. To put it another way, cleaning up your technical debt should be a high priority.

7.     Vulnerability score: The NIST’s National Vulnerability Database (NVD) provides the Common Vulnerability Scoring System, or CVSS, which qualitatively rates the severity of a vulnerability on a scale of 0–10. The score takes into account the severity of the vulnerability, the ease of exploitation, and the potential impact on the system. It can be used as a factor in the prioritization of vulnerability remediation activities. However, it's important to note that the CVSS is just one factor; you should also consider the other building blocks outlined in this post.

In our next post, we’ll discuss the importance of bringing a full lifecycle approach to securing your critical Linux devices. We hope you’ll look forward to that, and in the meantime, please take a look at our Studio Linux Services portfolio of offerings and be sure to run your SBOM through our free professional-grade CVE scanner. We can help you assess, prioritize, and resolve your cybersecurity issues and lower your technical debt — so you can keep your focus on innovating.