The No-Fix Mediums? Not Having a High Priority Doesn’t Mean Low Danger

by Luke Mcbride on October 31, 2022

Development teams are using more and more open source component software every day. These components are developed and maintained outside of your organization, and are often analyzed by researchers and the software community. When a flaw or coding mistake is found that could be exploited, it’s published as a vulnerability and given a rating to assess the overall danger.

One frequently used system for acknowledging and tracking issues is the Common Vulnerabilities and Exposures or CVE. The system has been in use for over 20 years and uses a score between 0 and 10 to represent danger from low to high. Below are the CVE scale, values, and some example concerns arising from the Log4j vulnerability over the past year.

Sponsorships Available

Breakdown on the CVE numbering system and some Log4j vulnerabilities as they appear on that scale. More info on these issues.

These ratings and their priority have become a standard for the industry to help align organizations’ priorities and highlight risky software.

CVE scoring is based on a set formula called the “Common Vulnerability Scoring System” or CVSS, which takes into account the ease of exploitability, potential information exposure, and required privileges. A great CVSS calculator [first.org] is available that can quickly verify what each score means.

This means that high-scoring CVE scores are simple to execute and allow access to lots of data and systems. After all, some vulnerabilities like those affecting Log4j were easy to exploit and in use by millions of individual programs. These issues need to be broadcast as loud as possible.

Unfortunately, our data shows that high and critical priority issues don’t just take precedence but may eclipse all other concerns.