Development teams are using more and more open source software every day. These components, which can be entire frameworks like Log4j 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 (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.
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.
During the development of the 8th annual State of the Software Supply Chain report, we detailed how a surprising number of people are still downloading vulnerable software, even when a fix is readily available. In fact, only 38% had no other option for that software, while 62% were clearly downloading the wrong version.
In essence, development teams are falling short of best practices to remediate software, but it's not always intentional. It can be due to a set-it-and-forget-it mentality, but it can also be caused by issues outside of their immediate control like a lack of tooling or other resources. Some simply don't have what they need to see that their software contains vulnerabilities.
This number represents downloads of vulnerable software that were scored as either high or critical danger. Our analysis of remediation for medium-priority vulnerabilities was much lower. Download statistics from Maven Central Repository estimate that 82% are not remediating medium-priority vulnerabilities, again where a fix is available.
Since these ratings can't consider every development team and configuration, it's possible for dangerous vulnerabilities to be marked as "medium." But if you're one of these teams using software or an uncommon configuration, you may have vulnerabilities in your software that are just as dangerous as Log4j issues.
Looking at only the most crucial software vulnerabilities in your development lifecycle means taking on additional risk. With the rise of more targeted software supply chain attacks, a medium-priority vulnerability sticks around longer and becomes easier to spot. An attacker familiar with your development practices, such as an intruder, unhappy employee, or contractor could cause downtime, a breach, or worse.
One example is the medium-priority JDBC Appender (CVE-2021-44832) issue mentioned above. This vulnerability was assigned "medium" priority in part because it only applied to non-standard configurations. In this case, there is a possible hazard if an attacker also has control of an LDAP server. Skilled attackers who can manage this compromise could cause just as much harm as higher-scoring vulnerabilities. The playbook for attackers performing breaches is to use any available vulnerability to advance further in software.
It should go without saying that development teams under time and budget pressure are doing their best and they must continue putting the majority of their energy toward finding and repairing the most dangerous concerns. This means a strong focus on widespread attacks and performing critical updates.
Additionally, the task of fixing vulnerabilities is a considerable undertaking and the requirements are only getting more complex. Modern applications are made up of approximately 90% third-party, open source component projects. Each of these projects is, on average, seeing 14 releases per year. So it's no wonder that so many teams push anything but the most dire concerns to the bottom of their to-do list.
It's not easy for project managers or developers, but allocating bandwidth to issues outside of potential disasters is good security hygiene. Teams that set aside time to address medium-priority vulnerabilities can both patch holes in your perimeter and reduce overall risk.
Best of all, software with vulnerable components is also frequently outdated, so this process can also mean more features, faster operation, and more.
Because updating dependencies is often a tedious process, it can sometimes get treated as an unwelcome maintenance task. As such, development teams will look for ways to delay addressing them, and some organizations are likely to only solve this in an ongoing way via automation.
Sonatype Lifecycle offers integrated tools to automate dependency management for addressing outdated software and remediating vulnerabilities. It also offers more information to evaluate components, enforces policy, and delivers transparency to show which projects are used and where.
Even if you aren't a Sonatype customer, we offer a free vulnerability scanner you can download or use online. The report will detail the usage of all known-vulnerable software in your repositories, including medium-priority concerns.
–
Thanks to Vlad Drobinin, Jeff Wayman, and Ilkka Turunen for their assistance on this article. More detail on the CVE issues mentioned above: