7 tips for prioritizing container and web application vulnerabilities

Since fixing each and every web application vulnerability in your backlog is simply impossible, you have to prioritize. Prioritization helps you focus on the issues that matter most to your organization and thus enables you to make the most out of the limited time and resources at your disposal for the best security impact.

Where does one start with vulnerability prioritization?

There are various prioritization methods and which one you end up using will depend on the security approach you have chosen to implement. To help you understand the different parts of the prioritization puzzle, below is a list of some of the most popularly used tools for web application vulnerabilities prioritization to help you on your prioritization journey.

1. CWE

What is CWE?

CWE stands for Common Weakness Enumeration,  an online glossary that categorizes software and hardware weaknesses into different types. For example: CWE-20 (Input Validation), CWE-125 (Out-of-bound Read), CWE-79 (XSS), and CWE-200 (Information Leak/Disclosure).

Maintained by MITRE, the stated purpose of CWE is to provide an effective way of identifying, finding, and resolving software security issues as soon as possible but CWE can also be used specifically for web application vulnerabilities prioritization in a number of ways:

• If you’re pressed for time and cannot afford to dive deeper into the vulnerabilities found in your code, use the CWE Top 25 list as a starting point to prioritize fixing those CWEs the community has marked as the most important.

• Use CWE to prioritize by impact - CWE entries include information about the resulting technical impact for a weakness. Instead of trying to fix everything, use this information to focus on the CWEs that are more dangerous for your specific organization.

• Use CWSS and CWRAF - two scoring systems for CWEs that will allow you to prioritize based on relevancy to your business.

2. CVSS/Severity

The most commonly used method for prioritization, the Common Vulnerability Scoring System (CVSS) is an industry-standard for assessing the severity of vulnerabilities. Based on how easily a web application vulnerability can be exploited and the level of impact if a successful exploit were to occur, CVSS assigns a score between 0 and 10, 10 being the most severe score that can be assigned.

According to the NVD, a CVSS (v3) base score of 0.0-3.9 is considered "Low" severity; a base CVSS score of 4.0-6.9 is "Medium" severity, and a base score of 7.0-8.9 is "High" severity, and a base score of 9.0-10.0 is “Critical” severity.

While a good starting point, keep in mind that CVSS does not represent an accurate enough picture of the risk posed by a vulnerability. As the official CVSS documentation states, “CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk...The CVSS Base Score should be supplemented with a contextual analysis of the environment and with attributes that may change in time”

3. Exploitability

One of the ways to determine the actual risk a vulnerability poses to your organization is by understanding how easy it is to exploit it. One factor that makes it extremely easy for hackers to exploit a vulnerability is the availability of exploit code. As soon as such code is published, this is known as an “exploit in the wild”.

Knowing whether there are “exploits in the wild” for the issues in your backlog will help you focus on a risky subset of issues. Distinguishing between the different types of published exploits will help you narrow your focus even further - there is a difference between the risk posed by an exploit that is mature, published, and practical and an exploit that is academic and theoretical. You can read more about the importance of exploitability for prioritization here.

4. Reachability

Developers will pull in entire open source components into their codebase but only actually use a small portion of these components as part of the application’s logic. This means that some vulnerabilities might not be called as part of the application’s execution path and therefore pose less of a risk and can be deprioritized.

If your AppSec tool provides this insight, use it to focus on these more urgent issues. Rather than prioritizing a high-severity vulnerability in a function not called by your application, it is much more effective to prioritize a medium-severity vulnerability that lies in the execution path poses more of a risk.

You can prioritize with either, or both, of the following complementary approaches:

• Determining reachability with static analysis of your source code

• Determining whether vulnerabilities are actually being called in runtime

Keep in mind, this does not mean vulnerabilities not being reached are not important and can be disregarded. They also need to be triaged and fixed, especially the high-severity ones. But what it does mean is that reachability will help you better differentiate between what’s important and what’s urgent.

5. Age

Try to factor in the age of vulnerability when making your prioritization decision. The more recent a vulnerability, for example, the less of a chance of an available fix. Hackers are also usually attracted to bright and shiny new vulnerabilities which, again, makes them all the more riskier. The algorithms powering Snyk’s Priority Score, for example, incorporate age into the final score following this exact same logic.

6. Fixability

One security approach is to try to fix as many issues as possible within a given timeframe. If speed is of the essence, consider prioritizing the issues that are the easiest, quickest, and cheapest to fix.

To do this, try to answer these questions:

• Can the vulnerability be fixed with a minor upgrade?

• Is there a patch available for the vulnerability?

• Can the vulnerable component be easily replaced?

7. Automation

The only way to prioritize and de-prioritize hundreds, if not thousands, of issues across the different projects in your organization, is with the help of automation. If your security tools provide you with this capability, use policies to automatically set the parameters guiding prioritization decisions in your fix efforts.

For example, you might want to raise the severity of all vulnerabilities with a specific CWE. Or you might want to automatically decrease the severity of issues with no know exploits.

These decisions are business-specific and will change from organization to organization, team to team, but the automation and granular control that policies provide make them a must in any prioritization strategy.

The benefit of effective web application vulnerabilities prioritization

Effective prioritization will help you stay focused on the vulnerabilities that pose the greatest risk to your organization and maximizes the value of the time and effort you spend, ultimately strengthening your overall security posture.

But as we’ve seen above, to prioritize well organizations need a bit more than CVSS. They require solutions that provide more and deeper context. The easier and more developer-friendly these tools are, the more likely they will be adopted by developers - key for the success of your prioritization and remediation efforts. This is precisely what Snyk provides.