Snyk’s severity levels aren’t just a score; they’re a dynamic reflection of a vulnerability’s potential impact on your specific application, not just its theoretical danger.
Let’s see this in action. Imagine you’ve just scanned a project with Snyk and it flags a high-severity vulnerability.
{
"vulnerabilities": [
{
"id": "SNYK-JAVA-COMFASTERXMLJACKSONCORE-1042138",
"packageManager": "maven",
"packageName": "com.fasterxml.jackson.core:jackson-databind",
"version": "2.10.0",
"severity": "high",
"title": "Jackson Databind: Deserialization of malicious JSON can lead to Remote Code Execution",
"cvssScore": 9.8,
"exploitability": "low",
"impact": "high",
"path": "com.fasterxml.jackson.core:jackson-databind:2.10.0",
"isUpgradable": true,
"isPatchable": false,
"fixedIn": "2.10.1",
"from": [
"com.fasterxml.jackson.core:jackson-databind:2.10.0",
"org.springframework.boot:spring-boot-starter-json:2.2.0.RELEASE"
]
}
]
}
Here, Snyk tells us about a critical RCE vulnerability in jackson-databind, version 2.10.0, with a CVSS score of 9.8. The severity is "high". This score is based on the Common Vulnerability Scoring System (CVSS), a standardized way to assess the severity of computer system vulnerabilities. It considers factors like attack vector (how the vulnerability can be exploited), complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability impacts. A score of 9.8 is right at the top of the "Critical" range.
But Snyk doesn’t stop there. It also looks at your project’s context. If this vulnerable jackson-databind library is used in a backend service that only processes trusted internal data and never directly exposes an API to the public internet, its actual risk to your organization might be lower than a similar vulnerability in a public-facing web application. Snyk’s severity, while often aligning with CVSS, can be influenced by factors like reachability and exploit maturity.
The core problem Snyk’s severity levels address is information overload and the difficulty of prioritizing fixes. Developers are bombarded with alerts, and not all vulnerabilities pose an equal threat. A CVSS score of 9.8 sounds terrifying, but if the vulnerable component is isolated and not exposed, the immediate threat is reduced. Snyk aims to cut through the noise by providing a nuanced severity rating that balances the theoretical CVSS score with practical exploitability and potential impact within your project.
Internally, Snyk uses a combination of CVSS scoring, its own vulnerability intelligence (which includes exploit maturity, availability of proof-of-concept code, and known attack patterns), and contextual information about your project (e.g., whether a package is used in a production environment, its dependencies). When you see "high" severity for a CVE, it means Snyk’s analysis has determined it’s a significant risk for your specific use case.
The cvssScore field is the raw CVSS v3.1 score. The exploitability and impact fields are Snyk’s interpretation, often derived from the CVSS vector string, but also informed by Snyk’s own research. A high cvssScore with "low" exploitability might mean it’s theoretically severe but difficult to exploit in practice. Conversely, a medium cvssScore with "high" exploitability could be more immediately dangerous.
The path and from fields are crucial for understanding how the vulnerability reached your project. In the example above, jackson-databind:2.10.0 is directly included, but it’s also a transitive dependency brought in by spring-boot-starter-json:2.2.0.RELEASE. This tells you that upgrading spring-boot-starter-json might also resolve the jackson-databind issue.
The fixedIn field provides the exact version you need to upgrade to. For jackson-databind, the fix is available in 2.10.1. Snyk also indicates if the vulnerability is isUpgradable (meaning a newer version exists) or isPatchable (meaning Snyk can provide a code patch without a full version upgrade, typically for transitive dependencies where upgrading the direct dependency would break compatibility).
Most people don’t realize that Snyk’s severity can be further refined by its "reachability" analysis, especially for code vulnerabilities. If Snyk finds a vulnerable function in your code, but that function is never actually called by any user-facing endpoint or critical process, its practical severity is significantly lower. Snyk attempts to determine if a vulnerable code path is "reachable" based on your application’s execution flow, making its severity assessments more context-aware than a simple CVSS lookup.
The next step after understanding Snyk’s severity levels is to learn how to leverage Snyk’s remediation advice to automatically create pull requests for dependency upgrades.