Prioritization on steroids with Snyk’s new Priority Score

Snyk’s new Priority Score helps to drastically simplify one of the biggest challenges in using open source securely—working out which vulnerabilities to tackle first.

For most organizations, fixing all vulnerabilities is simply not feasible. Each change comes at a cost, and that cost often rises with the age and complexity of the software. The average repository has over 35 vulnerabilities on the day it is first imported to Snyk, with container projects having over 130 each on average.

How the score works

Our Priority Score algorithm processes a range of data points (factors) to generate a score between 0 and 1000. We started with 0-100, quickly realising that companies aren’t just prioritizing within a project, they’re prioritising over _all_their projects. Granularity is key to avoiding the problem faced when using only severity or even CVSS—everything being top priority! We’ve calculated the weighting of the various factors to ensure that scores have an even spread whilst ensuring that those that pose the greatest risk end up with the highest score.

Scores can be seen on each issue in the Projects view, with all issues now sorted by the Priority Score, to show you the most pressing issues first. Issues can also be filtered by score range.

Scores are also shown in the Issues tab within the Reports section (for our customers who are on a paid plan) and includes the Priority Score as its own sortable column. By default the table is already sorted by the score, helping you to immediately prioritize your time. Issues can also be filtered by the score.

The last-place scores can currently be seen via the various issue-related API calls (for customers on paid plans)—these now return scores in the response, and support filtering by the score.

Read more about the relevant API calls:

• Get the list of latest issues

• Get the list of issues

• List all issues

How the score is calculated

The first version of the algorithm processes up to 10 factors per issue, a daunting task if someone were asked to do manually (or even in spreadsheets) for often thousands of vulnerabilities across all of a company’s projects. In the future, Snyk plans to add many more factors to help better advise where time can most valuably be spent to reduce security risk.

Here are just a few of the factors we already include—but is by no means an exhaustive list!

CVSS is the foundation of most vulnerability triage, and while it already takes in a wide range of factors, it does not account for that specific vulnerability in the context of your specific project. Further, prioritization with CVSS alone is hard when over 23% of vulnerabilities found by Snyk have a CVSS over 8.0. Our Priority Score, on the other hand, ensures a much better distribution, with less than 5% scoring over 800 out of 1000. Still, the value of CVSS is indisputable and so it carries a high degree of weight in the Snyk’s scoring algorithm.

Next, severity. While this has an absolute correlation with CVSS, in certain ecosystems CVSS is not possible, and in some cases, is no longer accurate. With Snyk’s Security Policies comes the ability to alter the severity of an issue based on information even Snyk isn’t able to determine—such as whether the service is business critical or not. Changing the severity allows the prioritization to take this into account, and reduce the score given.

An obvious inclusion is Snyk’s Exploit Maturity. Snyk’s industry leading security team uses manual and automated methods to track which vulnerabilities are exploitable, and to what extent. That information plays a crucial role in determining the risk that a vulnerability poses.

New to Snyk in general, we’re also including Reachable Vulnerabilities information in the Priority Score. By looking at the code paths called within a project, we’re able to help our users identify which vulnerabilities are actually reachable within the code.

While the availability of a fix doesn’t change the risk a vulnerability poses, it does change the cost of fixing it—dramatically so. Without a safer version to upgrade to, or a handy Snyk patch, the only resort for mitigating a vulnerability is to patch it yourself or use an alternative package in your software. Neither is easy, or quick, and vulnerabilities that cannot be fixed are often treated as an unavoidable risk.

Then, time—one of hardest factors to gauge the impact of. Before diving into data we hypothesized that vulnerabilities might pose a greater risk when first published, but may equally grow in “popularity” as time progresses. As it turned out, the former has a far greater impact on the risk a vulnerability poses and so that also forms a factor in the score.

Beyond these, there are several algorithm factors we’re working on, such as static code analysis to identify which vulnerabilities are in code paths that are actually used.

Getting started

Snyk’s Priority Score is now available to every Snyk user. To get started, take a look at the vulnerabilities in any of your projects, or head to the Issues tab within the Reporting section and see which of your issues to tackle first.

Find out more in the Snyk Knowledge Center.