Snyk

---

Key Facts

• Four products: Snyk Open Source (SCA), Snyk Code (SAST), Snyk Container (image scanning), Snyk IaC (Terraform/Helm/Kubernetes misconfiguration).
• Priority Score runs 0-1000; inputs are CVSS base score, exploit maturity, reachability, fix availability, social trends, and dependency depth (transitive vs direct).
• Risk Score is a newer ML-based layer (open beta as of 2024-2025) that replaces Priority Score as the primary signal; it models probability of exploitation rather than static factor weighting.
• Reachability analysis builds a call graph of the application's own code, then checks whether the call graph includes paths to the vulnerable function — if not, the issue is deprioritized.
• A vulnerability introduced transitively (your dep's dep) is statistically less likely to be reachable than a direct dependency; Snyk weights this via transitive depth.
• CVSS is an input, not the output — Snyk treats CVSS Base Score as one data point among many, not the final verdict.
• Social trend signal: Snyk monitors social media and security community activity; elevated discussion can predict imminent exploitation before a PoC is published.
• Integration surfaces: CLI (snyk test), GitHub/GitLab/Bitbucket PR checks, IDE plugins (VS Code, JetBrains, Eclipse), and CI/CD pipeline steps.
• Fix guidance is embedded alongside findings: Snyk identifies the minimal dependency upgrade that resolves the CVE, and can open automated fix PRs.
• Snyk maintains its own vulnerability database (separate from NVD), with manual curation by security researchers — NVD publication lag is a known problem Snyk partially sidesteps.

---

Detail

Product suite

Snyk Open Source performs software composition analysis (SCA): it reads manifest files (package.json, requirements.txt, pom.xml, go.mod, etc.), resolves the full dependency tree, and matches packages against the Snyk vulnerability database. It reports CVEs, license issues, and fix paths for each affected dependency.

Snyk Code is a static analysis tool (SAST) that scans proprietary source code for security issues such as SQL injection, XSS, hardcoded secrets, and insecure deserialization. It uses dataflow analysis rather than pattern matching, which reduces false positives relative to regex-based scanners.

Snyk Container scans Docker images and base image layers for OS-level CVEs (from distro advisories) and application-level vulnerabilities. It reports the base image that introduced an issue and recommends a less-vulnerable base image as a fix path.

Snyk IaC scans Terraform, Helm, Kubernetes YAML, and CloudFormation for misconfigurations: overly permissive IAM roles, missing network policies, containers running as root, etc.

Priority Score — computation

Priority Score (0-1000) is Snyk's original contextual severity signal, replacing the raw CVSS number as the actionable metric. Inputs:

Score granularity is deliberately high so that issues rarely tie — the intent is a strict ordering, not a band.

Risk Score — ML layer

Risk Score is Snyk's second-generation scoring model, developed by the Snyk Security Data Science team. Key differences from Priority Score:

• Uses a regression model trained on historical exploitation data to identify which factors are statistically significant predictors of real-world exploitation — not all factors that sound relevant actually predict exploitation in practice.
• Incorporates all Priority Score inputs plus business criticality context and environment-specific signals where available.
• Models probability of exploitation rather than producing a weighted sum of severity signals. The output is still 0-1000 for continuity, but the computation is fundamentally different.
• Explicitly acknowledges that ML-based scoring reduces auditability: you cannot fully reproduce the score by hand from published inputs. Snyk accepts this tradeoff for internal triage tools; it is a reason not to use Risk Score as the basis for a public, third-party scorecard (see mcpindex relevance below).

Risk Score is available in open beta across all Snyk plans including Free, enabled via Snyk Preview settings.

Reachability analysis — mechanics and value

Reachability is the feature that most differentiates Snyk from tools that apply CVSS scores uniformly. Without reachability:

• A project with 50 CVEs in its dependency tree may have only 5 where the vulnerable function is ever called.
• All 50 appear at the same severity band. Teams waste time patching the 45 unreachable ones.

With reachability, Snyk constructs a call graph by statically analyzing the application's source code. It maps every function call chain and compares it against a database of vulnerable functions (keyed to specific CVE/package/version tuples). If no call path reaches the vulnerable function, the issue is flagged as "Not Reachable" and sorted to the bottom of the queue regardless of CVSS score.

A "Reachable" finding means: this specific vulnerable function is called, directly or transitively, from application code. This is a meaningful signal; it is not a proof of exploitability (additional conditions such as attacker-controlled input may still be required), but it is a strong triage filter.

Reachability analysis is currently supported for Java, JavaScript/TypeScript, Python, and Go in Snyk Open Source. Container and IaC scanning does not use call graph reachability (the concept does not map to OS-level CVEs or configuration issues).

Snyk vs CVSS-only scoring

CVSS Base Score measures intrinsic, context-free severity. It answers: "how bad is this vulnerability in the worst-case deployment?" It does not answer: "is this vulnerability exploitable in my application right now?"

The gap matters because:

1. A CVSS 9.8 (Critical) vulnerability in a library where the vulnerable function is never called is practically inert in that application.
2. A CVSS 5.9 (Medium) vulnerability in a library where the vulnerable function is on the hot path for unauthenticated requests may be the most urgent issue.
3. CVSS Temporal/Threat score adjustments exist (exploit code maturity, report confidence) but are rarely applied by NVD — only Base Scores are published by default.

Snyk operationalizes the Temporal/Threat adjustments automatically and adds reachability on top. The Priority Score or Risk Score is what you actually triage from; CVSS remains in the report as the industry-standard severity reference.

The limitation: Snyk's scores are not reproducible in the way CVSS Base Scores are. CVSS Base Score is a deterministic formula over published inputs. Snyk's scores incorporate proprietary database curation, ML models, and signals (social trends, fix availability) that are not fully public. This is acceptable for internal developer tooling but is a problem for public third-party scorecards that need auditability.

Snyk vs OpenSSF Scorecard

OpenSSF Scorecard and Snyk are complementary, not competing:

• OpenSSF Scorecard assesses the security posture of a project's development practices: branch protection, code review, dependency pinning, CI/CD security, secrets detection, and whether known vulnerabilities exist. It is about how a project is maintained.
• Snyk assesses vulnerabilities in the dependencies a project pulls in and in the project's own code. It is about what a project contains.
• OpenSSF Scorecard's Vulnerabilities check uses OSV data to flag known CVEs, producing a pass/fail signal. Snyk's SCA does the same job with more granularity, prioritization depth, and fix guidance.
• A mature DevSecOps pipeline uses both: OpenSSF or similar for posture scoring, Snyk (or equivalent) for vulnerability triage and remediation workflow.

Integration patterns

Snyk is typically deployed at multiple points in the SDLC:

1. IDE — developer sees issues inline while writing code, before commit.
2. PR check — Snyk runs on every pull request and posts findings as GitHub/GitLab status checks; configurable fail thresholds (e.g., fail PR if any Critical/High issues with no fix available).
3. CI pipeline — snyk test step runs post-build; can be configured to break the build on severity thresholds.
4. Production monitoring — Snyk monitors imported projects for newly published CVEs that affect the current dependency snapshot, without requiring a new scan.

The snyk test CLI exit codes follow Unix conventions: 0 = no issues above threshold, 1 = issues found, 2 = configuration error.

Relevance to mcpindex scorecard design

Snyk's Priority Score is the canonical production example of a composite 0-N security score that goes beyond CVSS. Key design lessons for mcpindex:

• Factor decomposition is the right architecture: score = f(severity, context factors). CVSS alone is one of those factors.
• Reachability is the highest-ROI noise reducer: the analogous concept for an MCP server scorecard would be filtering generic CVEs based on whether the vulnerable dependency is actually used in the server's exposed functionality.
• ML scoring (Risk Score) trades auditability for predictive accuracy: appropriate for internal tooling; not appropriate for a public third-party scorecard where any maintainer must be able to reproduce and challenge their own score. Snyk's own docs acknowledge this tension.
• Fix availability as a factor: deprioritizing unfixable issues prevents alert fatigue — a useful mcpindex heuristic when flagging CVEs in packages that have no available upgrade.
• Transitive depth weighting: a CVE in a direct dependency is more urgent than the same CVE appearing only in a second-level transitive dep.

---

Connections

• security/security-scorecard-methodology — Snyk Priority Score is a reference implementation for composite security scoring; the scorecard-methodology page uses it as a comparator for the mcpindex scoring model
• security/owasp-wstg — vulnerability classes Snyk Code detects (injection, XSS, insecure deserialization) overlap with WSTG test categories
• security/mcp-cves — CVE data that Snyk-style SCA scanning would surface in MCP server dependencies
• security/threat-modelling — Snyk's factor model (impact × likelihood of exploitation) mirrors the OWASP Risk Rating approach; reachability is a likelihood modifier
• cs-fundamentals/python-packaging — Snyk Open Source scans PyPI dependencies via requirements.txt and pyproject.toml; PyPI package hygiene directly affects Snyk scan noise
• cloud/container-security — Snyk Container addresses OS-level CVEs in base images, complementing Snyk Open Source's application-layer SCA
• protocols/mcp — MCP servers are the scanning target for any mcpindex Snyk-style check; MCP-specific attack surfaces require custom checks beyond what Snyk covers out of the box

---

Open Questions

• Snyk Risk Score is described as using a regression model trained on historical exploitation data — the exact feature set and training corpus are not publicly documented. Is there a published paper or methodology doc? [unverified: no public academic paper found as of 2026-05-04]
• Does Snyk's reachability analysis extend to dynamically-dispatched calls (e.g., Python's getattr-based dispatch)? Static call graph construction is known to miss dynamic dispatch patterns. [unverified]
• What is Snyk's NVD publication lag delta — how many days ahead of NVD does Snyk typically publish a CVE in its own database? This is claimed as a differentiator but no benchmark figure was found in the search results. [unverified]
• For mcpindex: would Snyk's API (via snyk test --json) be a viable data source for dependency vulnerability data on MCP servers that publish open-source code, or does the licensing model restrict programmatic consumption at scale?
• As of 2026, has Risk Score fully replaced Priority Score as the default, or are both available? Snyk docs as of 2024-2025 described Risk Score as "open beta" enabled via Snyk Preview. Current status unclear.

---

Sources

• Snyk User Docs — Priority Score: https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/priority-score
• Snyk User Docs — Risk Score: https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/risk-score
• Snyk Blog — Introducing Snyk's new Risk Score: https://snyk.io/blog/introducing-new-risk-score/
• Snyk Blog — Developer-first prioritization capabilities: https://snyk.io/blog/snyks-developer-first-prioritization-capabilities/
• Snyk Blog — Priority Score on steroids: https://snyk.io/blog/snyk-priority-score/
• Snyk Blog — EPSS v3 scores in Snyk: https://snyk.io/blog/improved-risk-assessment-with-epss-scores-in-snyk/
• Snyk Learn — What is CVSS: https://learn.snyk.io/lesson/what-is-cvss/
• OpenSSF Scorecard: https://scorecard.dev/