Every time Snyk's vulnerability database adds a new CVE, it also assigns a field most users skim past without a second thought: exploit maturity. That field — set to No Known Exploit, Proof of Concept, or Mature, or in Snyk's newer CVSS v4.0-aligned model, Not Defined, Proof of Concept, or Attacked — quietly reshapes how a vulnerability shows up in a team's backlog. A critical CVSS 9.8 finding with no known exploit can rank below a medium-severity bug that already has a working exploit circulating publicly. Understanding Snyk exploit maturity rating research — what gets checked, who checks it, and how the label changes over time — matters because it directly determines which of the dozens of vulnerabilities flagged in a scan get patched this sprint and which get deprioritized for months. This post walks through the publicly documented mechanics behind that rating, without speculating about anything Snyk hasn't disclosed.
What Exactly Is Snyk's Exploit Maturity Rating?
Snyk's exploit maturity rating is a field attached to most vulnerabilities in its database that answers one narrow question: has a working exploit for this specific flaw actually been published, and if so, how usable is it? It is distinct from CVSS base severity, which measures theoretical impact and complexity, not whether anyone has actually built and released working attack code. The rating appears on individual vulnerability pages in the Snyk Vulnerability Database (security.snyk.io), in issue lists inside the Snyk product, and as a filterable attribute so teams can, for example, surface every open container vulnerability with an "Attacked" or "Mature" label regardless of its CVSS score. Snyk has published this field for years specifically because customers kept asking to prioritize by "is this actually being used against people" rather than by CVSS alone.
What Are the Possible Values, and What Changed With CVSS v4.0?
Snyk currently exposes two overlapping value sets: a legacy three-tier scale and a newer scale aligned to the CVSS v4.0 Exploit Maturity (E) threat metric that FIRST (the Forum of Incident Response and Security Teams) published in November 2023. In the legacy scale, Mature means Snyk has identified a published exploit that is reliable and readily usable, such as a Metasploit module or a fully weaponized proof-of-concept on Exploit-DB; Proof of Concept means a published, detailed write-up or demo exists that shows how the vulnerability could be exploited but isn't turnkey; and No Known Exploit means neither was found publicly at the time of review. In the CVSS v4.0-aligned scale, the values become Attacked (Snyk has evidence the vulnerability is being actively exploited in the wild), Proof of Concept (PoC code or a detailed exploitation write-up is public but no active exploitation has been reported), and Not Defined/Unreported (no evaluation or no evidence exists yet). The newer scale mirrors CVSS v4.0's own Exploit Maturity metric almost value-for-value, which is a deliberate alignment rather than a coincidence.
Who Actually Does the Research Behind the Label?
The rating starts as manual analysis by Snyk's security research team, cross-checked against modeling work from Snyk's Security Data Science team, the same groups responsible for curating entries in the Snyk Vulnerability Database. Snyk has described the process as researchers evaluating two things: whether an exploit has been published at all ("is it in the wild?") and whether that published exploit genuinely makes the vulnerability easier to abuse in practice, rather than being a theoretical writeup that overstates the risk. In practice this means researchers monitor sources like Exploit-DB, Metasploit modules, GitHub proof-of-concept repositories, vendor security advisories, and security researcher blog posts and conference disclosures, then validate whether the code actually functions against the vulnerable code path before assigning Mature or Attacked. Snyk has been explicit that this is not a single automated feed dumped into a database field — it's analyst judgment layered on top of public signal, which is also why the label can lag behind the first GitHub commit of a PoC by days or weeks.
How Does This Differ From CVSS's Own Exploit Metric?
CVSS already has a built-in mechanism for exactly this — the Exploit Code Maturity temporal metric in CVSS v3.1 (values: Not Defined, High, Functional, Proof-of-Concept, Unproven) and the Exploit Maturity threat metric in CVSS v4.0 (values: Not Defined, Attacked, Proof-of-Concept, Unreported) — so Snyk's rating is best understood as filling a gap rather than inventing a new concept. The gap is that the National Vulnerability Database (NVD) and most CVE Numbering Authorities rarely populate temporal or threat metrics for a given CVE; the base score gets calculated, but the metric that's supposed to capture real-world exploit availability is usually left at "Not Defined" indefinitely because it requires ongoing analyst attention that a public feed doesn't provide by default. Snyk's exploit maturity field is essentially a continuously maintained, manually researched substitute for that missing CVSS temporal data, applied consistently across the roughly hundreds of thousands of open source, container, and code vulnerabilities the company tracks.
How Does Exploit Maturity Feed Into Snyk's Priority Score and Risk Score?
Exploit maturity is one direct, weighted input into a composite score rather than a standalone ranking. In Snyk's original Priority Score (0–1000), exploit maturity is combined with the CVSS score, whether a fix is available, how new the vulnerability is, and reachability signals; Snyk's own analysis has noted that only around 36% of exploits it tracks ever reach the "Mature" tier, meaning the label is meant to be a meaningful filter rather than something most vulnerabilities hit by default. Snyk's newer Risk Score (also 0–1000, released in Early Access for Snyk Open Source and Snyk Container) splits the calculation into an Impact subscore, built from CVSS Confidentiality/Integrity/Availability/Scope metrics and business-criticality attributes, and a Likelihood subscore, which folds in exploit maturity alongside EPSS, vulnerability age, CVSS exploitability sub-metrics, social/community attention, malicious-package flags, and package popularity, with reachability and dependency depth applied as contextual adjustments. In both scoring models, moving a vulnerability from No Known Exploit/Not Defined to Mature/Attacked measurably increases where it lands in a prioritized queue — it's designed to be one of the stronger signals in the formula, not a minor tiebreaker.
What Are the Limitations of Relying on an Exploit Maturity Label?
The biggest limitation is lag and coverage: a rating can only reflect exploits that Snyk's researchers have found and validated as of the last review, so a newly weaponized PoC posted publicly this morning won't be reflected until someone manually confirms it works. It also says nothing about whether the vulnerable code path is reachable in a specific application, which is why Snyk treats reachability as a separate signal layered on top rather than folding it into the exploit maturity label itself. The Apache Struts vulnerability behind the 2017 Equifax breach illustrates why that gap matters: the flaw (CVE-2017-5638) was patched and disclosed on March 7, 2017, exploit code appeared publicly within days, and attackers began exploiting it against Equifax by mid-May 2017, roughly two months later, ultimately exposing personal data belonging to around 147 million people. A vulnerability's exploit maturity can go from "no known exploit" to "mature" in a matter of days, and that transition window is often when organizations are most exposed but least aware anything has changed.
How Safeguard Helps
Exploit maturity ratings like Snyk's are genuinely useful signal, but they're one data point among several — EPSS scores, CISA's Known Exploited Vulnerabilities catalog, vendor advisories, and internal reachability all need to be reconciled before a team can confidently decide what to fix first. Safeguard helps engineering and security teams pull these signals together into one place: ingesting exploit intelligence alongside SBOM data, dependency graphs, and provenance information, then layering in reachability and business-context checks so a "Mature" or "Attacked" label doesn't get evaluated in isolation from whether the affected code actually ships in a running service. Instead of manually cross-referencing a Snyk exploit maturity tag against an EPSS percentile and an internal criticality tier for every finding, teams using Safeguard get that correlation done automatically, so remediation effort goes toward the vulnerabilities that are both exploitable in the wild and actually reachable in their environment.