Risk Score
.Risk Score is currently in Open Beta for Snyk Open Source and Snyk Container. Use Snyk Preview to replace the Priority Score with the new Risk Score. See Snyk feature release process for more details.
The Snyk Risk Score is a single value assigned to an issue, applied by automatic risk analysis for each security issue. Risk Score is based on the potential impact and likelihood of exploitability. Ranging from 0 to 1,000, the score represents the risk imposed on your environment and enables a risk-based prioritization approach.
Since real risk is scarce, you should expect a significant drift in the distribution of scores, as can be seen in this example of Project score distributions:
Example Project scores distribution
As part of the Open Beta, the Risk Score replaces the Priority Score directly. See the priority score docs for how to interact with the Risk Score in the UI, API, and Reports, where the Risk Score is now introduced when enabled. Risk Score is not available in the CLI.
The Priority Score will be replaced with the Risk Score when Snyk Open Source and Snyk Container Projects are re-tested
Note that in the API, the relevant fields are still named with
priority.When Risk Score is enabled, the scores and factors populated in these fields are based on the Risk Score model as part of the beta, When looking at Issue card information, hover over the Risk Score to see the subscore and Risk Factors contributing to the score.
Risk Score tooltip showing Impact and Likelihood
The Snyk Risk Score Model
The model that powers the Risk Score applies automatic risk analysis for each security issue based on the potential impact and likelihood of exploitability.
The Risk Model results from extensive research conducted by the Snyk Security Data Science team and experienced security researchers. The model draws on expertise gained over the years in developing the Snyk Vulnerability Database.
Objective impact factors are the CVSS impact metrics, Availability, Confidentiality, Integrity, and Scope, calculated based on the CVSS impact subscore. For Container issues, Provider Urgency is also taken into account.
The business criticality Project attribute will be taken into account as a contextual impact factor, increasing or decreasing the impact subscore. For more information, see Project attributes.
Objective likelihood factors are taken into account:
- Exploit Maturity
- Exploit Prediction Scoring System (EPSS)
- Age of advisory
- CVSS exploitability metrics: Attack vector, Privileges required, User interaction, and Scope
- Social Trends
- Malicious Package
- Provider Urgency (Snyk Container)
- Package popularity (Snyk Open Source)
- (Forthcoming) Disputed vulnerability
Contextual likelihood factors then increase or decrease the likelihood subscore:
- Reachability (Snyk Open Source Java only, JavaScript to be supported)
- Transitive depth
- (Forthcoming) Insights such as
Deployed,OS conditionandPublic Facing
Fixability is no longer considered part of the Score Calculation, as the effort needed to mitigate a security issue does not affect the risk it imposes. To focus on actionable issues, use Fixability filters and then use the Risk Score to start with the riskiest issues.
Represents the impact on customer’s data confidentiality, based on CVSS definition.
Possible input values:
None, Low, HighRepresents the impact on customer’s data integrity, based on CVSS definition.
Possible input values:
None, Low, HighRepresents the impact of customer’s application availability based on CVSS definition.
Possible input values:
None, Low, HighIndicates whether the vulnerability can affect components outside of the target’s security scope, based on CVSS definition.
Possible input values:
Unchanged, Changed. How would these affect the score?
The objective impact subscore is calculated based on the CVSS impact subscore. For more information, see these references on CVSS impact definitions and subscore equations.
Urgency rating as provided by the relevant operating system distribution security team. For more information, see External information sources for relative importance in severity levels of detected Linux vulnerabilities.
Possible input values:
Critical, High, Medium, and Low. When neither CVSS nor Importance Rating is provided, Provider Urgency is set to Low by default.How would this affect the score?
Critical - Impact subscore will increase significantly
High - Impact subscore will increase
Medium - Impact subscore will decrease significantly
Low - Impact subscore will decrease significantly
Note that Provider Urgency will also affect the Likelihood subscore. Business criticality
User-defined Project attribute representing the subjective business impact of the respective application. For more information, see Project attributes.
Possible input values:
Critical, High, Medium, Low.How would this affect the score?
Critical - Impact subscore will increase
High - Impact subscore will not be affected
Medium - Impact subscore will decrease
Low - Impact subscore will decrease significantly
When no Business Criticality is assigned, the Impact subscore will not be affected. When you apply a business criticality attribute to a Project, a retest is required for the Risk Scores to incorporate the new data.
Represents the existence and maturity of any public exploit retrieved and validated by Snyk. For more information, see View exploits, How exploits are determined.
Possible input values:
No Known Exploit, Proof of Concept, Functional, High.How would this affect the score?
High - Impact subscore will increase significantly
Functional - Impact subscore will increase
Proof of Concept - Impact subscore will decrease slightly
No Known Exploit - Impact subscore will decrease significantly
The likelihood subscore will increase significantly according to the level of exploit maturityExploit Prediction Scoring System (EPSS), predicting whether a CVE would be exploited in the wild, based on an elaborated model created and owned by the FIRST Organization.
The probability is the direct output of the EPSS model and conveys an overall sense of the threat of exploitation in the wild. This data is updated daily, relying on the latest available EPSS model version. See the EPSS documentation for more details.
Possible input values:
EPSS score [0.00-1.00]How would this affect the score?
The likelihood subscore will increase significantly according to the EPSS score
Represents the context by which vulnerability exploitation is possible, based on the CVSS definition.
Possible input values:
Network, Adjacent, Local, PhysicalHow would this affect the score?
Network - Likelihood subscore will increaseAdjacent, Local, Physical - Likelihood subscore will decrease according to the level of remote access needed to exploit the vulnerabilityRepresents the level of complexity defined by the conditions that must exist to exploit the vulnerability, based on the CVSS definition.
Possible input values:
Low, HighHow would this affect the score?
Low - Likelihood subscore will increaseHigh - Likelihood subscore will decreaseRepresents the level of privileges an attacker must possess before successfully exploiting the vulnerability, based on the CVSS definition.
Possible input values:
None, Low, HighHow would this affect the score?
None - Likelihood subscore will increase Low, High - Likelihood subscore will decrease according to the level of privileges required Represents the need for action from a user as part of the exploitation process, based on the CVSS definition.
Possible input values:
None, Required How would this affect the score?
None - Likelihood subscore will increase Required - Likelihood subscore will decrease Represents the social media traffic regarding this vulnerability. Snyk research has shown that greater social media interaction can predict future exploitation or point to existing exploitation. For more information, see Vulnerabilities with social trends.
Possible input values:
Trending, Not trendingHow would this affect the score?
Trending - Likelihood subscore will increase Not trending - Likelihood subscore will not changeMalicious code deployed as a supply chain dependency is considered highly exploitable.
Possible input values:
True, FalseHow would this affect the score?
The Likelihood subscore will increase significantly for Malicious Packages
A new vulnerability (up to one year) is more likely to be exploited than an old vulnerability (more than one year since publication)
Possible input values: Days since the vulnerability was first published.
How would this affect the score?
Less than one year old - Likelihood subscore will increase
Over one year old - Likelihood subscore will decrease
If a package is relatively more popular for its ecosystem, it is more likely to be exploited as hackers benefit from a wider pool of potential targets.
Possible input values:
High, Medium, Low How would this affect the score?
High - Likelihood subscore will increase Medium - Likelihood subscore will not change Low - Likelihood subscore will decreaseThese are CVEs that have been acknowledged as being disputed by their Project maintainer or the community at large. Snyk research shows that none of the disputed CVEs in the Snyk Vulnerability DB have been exploited in the wild.
Possible input values:
True, FalseHow would this affect the score?
True - Likelihood subscore will decrease significantly False - Likelihood subscore will not changeImportance rating as provided by the relevant operating system distribution security team. For more information, see External information sources for relative importance in severity levels of detected Linux vulnerabilities.
Possible input values:
Critical, High, Medium, and Low. When neither CVSS nor Importance rating is provided, provider urgency is set to Low by default.How would this affect the score?
Critical - Impact subscore will increase significantly
High - Impact subscore will increase
Medium - Impact subscore will decrease
Low - Impact subscore will decrease significantly
Note that Provider Urgency will also affect the Impact subscore. Building on past studies, Snyk research has shown that if a vulnerability is introduced to a Project transitively rather than directly, it is less likely that an exploitable function path will exist.
Possible input values:
Direct dependency, Indirect dependency, Great transitive depth (forthcoming)How would this affect the score?
Direct Dependency - Likelihood subscore will not change
Indirect Dependency - Likelihood subscore will decrease
Great transitive depth - Likelihood subscore will decrease significantly (coming soon)
Snyk static code analysis determines whether the vulnerable method is being called. This is currently supported only in Java; JavaScript support is coming soon. For more information, see Reachable vulnerabilities.
Possible input values:
Reachable, No path found
When Reachability is not enabled, the Likelihood subscore will not change, and the factor will not show up.How would this affect the score?
Reachable - Likelihood subscore will increase, and transitive depth will not be considered. No path found - Likelihood subscore will not changeWhether or not the operating system and architecture of a given resource are relevant to this specific issue
Possible input values:
Condition not met, Condition met, No dataHow would this affect the score?
Condition not met - Likelihood subscore will decrease significantlyCondition met, No data - Likelihood subscore will not change. Whether or not the container image introducing this issue is deployed.
Possible input values:
Deployed, Not Deployed, No dataHow would this affect the score?
Deployed - Likelihood subscore will increaseNot Deployed - Likelihood subscore will decreaseNo data - Likelihood subscore will not changeWhether or not the asset introducing this issue is exposed to the Internet.
Possible input values:
Public Facing, Not Public Facing, No dataHow would this affect the score?
Public Facing - Likelihood subscore will increaseNot Public Facing - Likelihood subscore will decreaseNo data - Likelihood subscore will not changeAll factor names and their effect on the score are subject to change during the beta period.
Last modified 14d ago