Software supply chain security risks are mounting. As noted in Veracode’s State of Software Security (SoSS) report, organizations of all sizes are drowning in security debt, and a large portion of the critical debt can be attributed to third-party vulnerabilities. With over 250,000 Common Vulnerabilities and Exposures (CVE) cataloged in the National Vulnerability Database (NVD) and with the number of CVEs increasing at an alarming rate of 10% per year over the last 3 years, it’s no wonder that companies are struggling.
The SoSS report also shows that the typical organization can only fix less than 10% of its vulnerabilities. Which means that, at best, most companies can barely tread water. Luckily, only a small fraction (2-7%) of all these CVEs are ever actively exploited. Of course, it’s not possible to know exactly which CVEs will be exploited, but an effective vulnerability management strategy can optimize those limited resources by targeting vulnerabilities that are more likely to be exploited.
Prioritization
The combination of the growing volume of CVEs and the lack of resources to address them makes prioritization more important than ever. Traditionally, organizations would turn to the Common Vulnerability Scoring System (CVSS) to help prioritize their issues. Unfortunately, because CVSS base scores are calculated assuming worst-case scenario, over 55% of these vulnerabilities have a base score in the critical or high range. (Customization of CVSS score is possible but not practical for most organizations.) As the saying goes, if everything is a priority, nothing is a priority. An application security posture management (ASPM) tool is the next generation of prioritization, and we’ll get more into this later.
Reachability
Before the term “reachability” came into vogue, Veracode pioneered the detection of what we call “vulnerable methods.” Fixing these vulnerabilities should be your top priority because they are reachable by hackers.
Vulnerable method detection starts with Veracode’s security research team. They identify which public methods are affected by a disclosed vulnerability and add those methods to Veracode’s vulnerability database. Then when you scan, SCA agent builds a call graph of your project, which it uses to detect when your first-party code is calling one of those vulnerable methods. For more detail on vulnerable methods, check out this blog.
Exploited in the wild
Next, you can use the past to predict the future, and if a vulnerability has already been exploited in the wild, it has a higher likelihood of being exploited again. To identify these vulnerabilities, Veracode has added to its SCA results two new fields related to exploitability that can be used for prioritization: Exploit Observed and Exploit Source. These fields indicate whether a CVE is known to have been exploited in the wild. For example, if a CVE appears in Cybersecurity & Infrastructure Security Agency’s Known Exploited Vulnerabilities (KEV) catalog, the Exploit Observed field will be set to True, and Exploit Source will show KEV. Similarly, if Offsec’s Exploit-DB lists a CVE as actively exploited or has a publicly available proof-of-concept (POC), these fields will also provide the relevant information. This approach allows security teams to quickly identify which vulnerabilities should be prioritized due to real-world exploitation.
EPSS
The Exploit Observed field, however, is focused on the past. The Exploit Prediction Scoring System (EPSS) is focused on the future. EPSS is a statistical model developed by the Forum of Incident Response and Security Teams (FIRST) organization, which is the same organization that developed CVSS. EPSS provides two numbers: probability (aka score) and percentile. The probability estimates the likelihood that a particular vulnerability will be exploited in the next 30 days. The percentile is the proportion of probabilities less than or equal to the vulnerability’s current ranking.
Since last year, Veracode has provided EPSS data via the Issues API for SCA Agent scans and via the Findings API for SCA Upload scans. This data also appears in the JSON file the SCA agent generates and in the new SCA Portfolio user interface (UI). Veracode recommends initially prioritizing vulnerabilities with EPSS scores over 10%, which should cover 80% of vulnerabilities with the potential for exploitation in the next 30 days. As your application security program matures, however, you may consider gradually dropping the EPSS threshold to 1% or even 0.1%, especially for your mission-critical applications.
Remaining Priorities
If you’ve fixed all vulnerabilities that are reachable, exploited in the wild, and above your EPSS threshold, then vulnerabilities that enable Anonymous Code Execution (ACE) and Remote Code Execution (RCE) should be given extra attention. Most ACE and RCE vulnerabilities will have a CVSS score in the critical or high range, however, so if this remaining cohort of vulnerabilities is not too large, it may be simpler to rely on CVSS severity to prioritize the remaining vulnerabilities.
Summary
With limited resources, an overwhelming and ever-growing number of vulnerabilities, and an imperfect vulnerability scoring system (CVSS), Veracode recommends that organizations use the reachability and exploitability data included in its SCA results to prioritize what to fix first. Overall, this vulnerability management strategy can be summarized as follows:
- Act Yesterday – Obviously if a zero-day vulnerability is released, you will need to drop everything and address it.
- Act Now – First priority should be fixing vulnerabilities that have vulnerable methods and/or are known to be exploited (KEV, exploitDB)
- Act Soon – Second priority should be vulnerabilities that are above your threshold for EPSS score
- Schedule – Third priority should be Anonymous Code Execution (ACE) and Remote Code Execution (RCE) vulnerabilities and other vulnerabilities with a critical or high CVSS score
- Monitor – Even low and medium-severity vulnerabilities can have a surprisingly high EPSS score, so don’t get lulled to sleep by severity.
Next Level Vulnerability Management for Software Supply Chain Risks (& More)
Ultimately, the strategy outlined in this article is quite basic, but it is a good start for those who have been focusing solely on CVSS scores and whose application security programs have stalled as a result. It is important to emphasize that there is no one-size-fits-all strategy for vulnerability management. For example, vulnerabilities from a mission-critical, web-facing application should be prioritized differently than vulnerabilities from an internal app. If you are ready for a much more sophisticated method of prioritization – one that incorporates many more data points from a wide variety of sources to determine priority and urgency – check out Veracode Risk Manager.
Additionally, to secure the software supply chain even further, Veracode recently acquired Phylum’s technology for malicious package detection, which you can read more about here.