Home / Knowledge hub / Exploit maturity
Knowledge hub
Exploit maturity
How developed and available attack code is for a given flaw.
What it means
Exploit maturity describes how far along the attack code for a vulnerability is. At one end, a flaw is known only in theory. In the middle, someone has published a proof of concept. At the other end, reliable tools exist and the flaw is being used against real targets.
It is a property of the flaw's current state in the world, not of the code itself, and it changes. A flaw with no known exploit on Monday can have a working one on Thursday, so any record of it needs a date and a source.
Why it matters
Two flaws with the same severity score can deserve very different urgency. The one that attackers are already using needs action now. The one with no known code can wait for the normal cycle. Ignoring maturity treats them alike and spends effort in the wrong order, often on the loudest score instead of the likeliest attack.
It also explains why 'critical' does not always mean 'drop everything'. Maturity, together with exposure and the value of the system, is what moves a flaw from a number on a report to a ticket with a deadline and an owner who has to answer for it.
How it shows up
CVSS records it as a metric. In version 3.1 it is called exploit code maturity, with values from unproven to high. In CVSS 4.0 the Threat group has one metric, exploit maturity, with values for attacked, proof-of-concept and unreported. Scores that include it describe the situation now.
Data sources include the CISA KEV catalog for known exploitation, EPSS for predicted likelihood, public exploit databases and vendor advisories. None is complete. And for your own application code, no public data exists at all, so the only way to learn maturity is to try the proof of concept yourself.
Questions people ask
Exploit maturity, answered
Does a public proof of concept mean it is being used?
Not necessarily, but it lowers the effort needed and makes use more likely. Treat it as a warning.
Active exploitation reports are a stronger signal.
Where do I find exploit maturity data?
CISA's KEV catalog lists flaws known to be exploited. EPSS gives a probability. Vendor advisories sometimes say whether exploitation was seen.
Combine them, since each misses some cases.
Is exploit maturity the same as exploitability?
No. Exploitability describes how easy a flaw is to use, such as network access and no login needed. Maturity describes how available working code is.
Both feed the priority.
Does it matter for flaws in our own code?
Yes, but nobody publishes data for them. The question becomes: can someone make this work today? A test that exploits it gives you the answer.
That proof is your maturity rating.
How often does it change?
Often, especially in the first days after a disclosure, when researchers publish code quickly. Re-check high-severity items on a schedule.
Some feeds update daily, so automate the check where you can.
Sources
Where this comes from
Related
Terms that sit next to this one
Exploitability
How easily and reliably a flaw can be used in practice.
EPSS
A score estimating how likely a vulnerability is to be exploited in the next thirty days.
CISA KEV catalogue
A government list of vulnerabilities known to be exploited in real attacks.
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
CVSS 4.0
The newest CVSS version, adding clearer threat and supplemental metrics.
Can it be used today?
For flaws in your own code, nobody publishes exploit data, so we exploit the finding to confirm it and show the request and response. Maturity becomes a fact. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.