Vulnerabilities you shouldn’t fix

While most discussions around vulnerabilities focus on which vulnerabilities you should prioritize, this one takes a different approach. Here, we'll be exploring the vulnerabilities that you shouldn't fix, shedding light on a less discussed but equally important aspect of vulnerability management.

1. Unused transitive packages

Most Software Composition Analysis (SCA) and container scanning tools report vulnerabilities in packages by scanning package manager manifest files. However, it's important to note that not all reported packages pose a real risk. Specifically, unused transitive packages, though identified as vulnerable, do not actually present a threat. This is because they are not utilized in the application's operation and are not loaded into memory during runtime.

Recommendation: Don’t fix. Remove the dependency for hygiene reasons (if possible).

Reduction rate: 40-70% of packages.

2. No network reachability

Many Software Composition Analysis (SCA) and Static Application Security Testing (SAST) tools report vulnerabilities that cannot be exploited through any application flow or network flows. It's crucial to understand that these vulnerabilities do not pose a risk of being exploited by remote or local attackers since there is no flow that reachs the the vulnerable code.

Recommendation: Don’t fix.

Reduction rate: 90-99% of vulnerabilities on internet-facing components do not have network reachability.

3. Non-Internet-Facing components

Vulnerabilities found on a computing host that is not directly exposed to the internet are generally less vulnerable to internet-based attacks. However, they could still be at risk if connected through another interface that is internet-facing (in multi-tier architecture).

Recommendation: Reduce prioritization.

Reduction rate: depends on scan surface.

4. Using non-vulnerable function

Many Software Composition Analysis (SCA) and container scanning tools report vulnerabilities in packages even when the vulnerable portions (functions or methods) of code are not in use. Importantly, if the application does not utilize the specific vulnerable functions, these vulnerabilities do not pose a real risk.

Recommendation: Reduce prioritization. Upgrade the dependency to prevent future use (if possible).

Reduction rate: 20-90% of usage instances.

5. Development dependencies

Packages used exclusively for development purposes, such as NPM "Jest" used for unit testing do not contribute to runtime vulnerabilities. These are not included in the final build and, despite potential vulnerabilities, do not pose a risk to the deployed application

Recommendation: Don’t fix if the CVSS attack vector is network-based.

Reduction rate: depends on scan surface.

6. With conditions

These packages are vulnerable only when running on a specific operating system (OS) or set of configurations. For instance, security advisories from Red Hat often adjust the severity scores for vulnerabilities that do not impact the Red Hat OS environment. This reflects a more nuanced approach to assessing risk, recognizing that the same vulnerability may not present a uniform threat across different systems.

Recommendation: Don’t fix if conditions don’t match.

Reduction rate: 5%-10%.

7. Low exploitability likelihood

Vulnerabilities without existing exploits in the wild present a significantly reduced risk, as they require attackers to invest more effort to develop and execute an attack. Notably, fewer than 2% of vulnerabilities are documented with exploits by sources such as Exploit-DB and CISA's Known Exploited Vulnerabilities (KEV) database, indicating that the vast majority of vulnerabilities are less likely to be exploited in a “spray attack” which is not targeted.

Recommendation: Prioritize lower.

Reduction rate: 98% of vulnerabilities.