Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What is the difference between a vulnerability, an exploit, and risk?
Updated
A vulnerability is a weakness in software, configuration, or process. An exploit is code that abuses that weakness. Risk combines exploitability with the value and exposure of the specific asset — the same CVE can be near-zero risk on one system and severe on another.
This page, last verified 10 September 2026, distills public terminology from NIST CSF 2.0, NIST SP 800-30, MITRE's CVE Program, FIRST's Exploit Prediction Scoring System (EPSS), and CISA's Known Exploited Vulnerabilities (KEV) catalog. It is not legal advice and does not determine that any control, standard, or scoring scheme applies to YOU.
Three different questions, not three names for one thing
Audience: an engineer, security lead, or manager who has heard 'vulnerability,' 'exploit,' and 'risk' used interchangeably in a stand-up or a scanner report, and wants the actual boundary between them. This page is not legal advice. It does not start a clock. Reading it does not start a clock. This product does not patch YOUR estate — a named human still owns triage, remediation, and any risk-acceptance decision.
'Vulnerability' answers: what is the weakness? 'Exploit' answers: does a way to abuse it exist, and how automatable is it? 'Risk' answers: given exposure, asset value, and exploitability, how much should we actually worry, right now, about this specific instance? Conflating the three is the single most common way a vulnerability-management program produces an unworkable backlog: severity gets treated as risk, and a low-exposure critical outranks a high-exposure medium that is actively being hit.
Comparison table
Each row states a definition, who typically measures or publishes it, and a concrete example. None of these definitions is this page's invention — each is attributed. Last verified 10 September 2026. Not legal advice.
| Term | Definition | Who measures / publishes it | Example |
|---|---|---|---|
| Vulnerability | A weakness in a system, process, or control that could be exploited or triggered by a threat source. NIST's Computer Security Resource Center glossary and NIST CSF 2.0 use this framing; MITRE's CVE Program assigns identifiers to publicly disclosed instances. | MITRE (the CVE Program, funded by CISA) assigns CVE IDs. NIST's National Vulnerability Database (NVD) enriches most CVE records with a CVSS score and CWE classification. | CVE-2021-44228 (Log4Shell) — a flaw in Apache Log4j2 that lets JNDI lookups load and execute attacker-controlled code from a remote LDAP server. |
| Exploit | A technique, script, or tool that takes advantage of a vulnerability to produce an unintended or unauthorized effect, such as code execution, privilege escalation, or data exposure. | No single registry catalogs every exploit. Exploit-code availability and automatability feed into CVSS Threat metrics (v4.0) and Temporal metrics (v3.1), and into FIRST EPSS as one input among many. | For Log4Shell, working proof-of-concept exploit code was public within days of disclosure, and mass automated scanning-and-exploitation followed almost immediately — an unusually short gap between vulnerability and exploit. |
| Risk | The combination of the likelihood a threat exploits a vulnerability and the resulting impact, evaluated for a specific asset in its specific context. NIST SP 800-30 frames risk assessment as threat, vulnerability, likelihood, and impact together, not any one of those alone. | No external body scores YOUR risk for YOU. FIRST EPSS estimates population-level exploitation probability; CISA KEV records confirmed in-the-wild exploitation; asset exposure and business value are yours to assess. | The same Log4Shell CVE was severe risk on an internet-facing, unpatched, internet-reachable JNDI-lookup-enabled service, and comparatively low risk on an air-gapped internal batch job with no network egress and the lookup feature already disabled. |
Worked example: one CVE, two very different risk levels
Take a single hypothetical CVE with a CVSS v3.1 base score of 9.8 (critical): network attack vector, no privileges required, no user interaction, full confidentiality/integrity/availability impact — a serious vulnerability by any severity measure. The CVSS base score does not change between the two systems below. The risk does. Last verified 10 September 2026. Not legal advice.
- The lesson is not 'internal systems don't matter.' It is that CVSS answers 'how bad if exploited,' not 'how likely, here, right now' — and risk requires both.
- This page does not score YOUR asset. Confirming actual reachability, not assumed network topology, is the step that turns this table into a real decision.
| Factor | System A — internet-facing, KEV-listed | System B — isolated internal, not in KEV |
|---|---|---|
| Exposure | Publicly reachable on the open internet; discoverable by mass internet scanners within hours of a CVE's disclosure. | Reachable only from an internal network segment with no internet route and restrictive firewall rules; no external attacker can reach it directly. |
| CISA KEV status | Added to the KEV catalog — CISA has reliable evidence of active exploitation in the wild against this CVE. | Not listed in KEV. That is weak evidence it is not being exploited, not proof; KEV is a lagging indicator by construction. |
| FIRST EPSS score | High EPSS percentile — the model estimates a high probability of exploitation in the next 30 days, consistent with the KEV listing and public exploit code. | Same published CVSS score, but EPSS for that CVE reflects the population-wide probability, not this system's isolation; EPSS does not know this instance is unreachable from the internet. |
| Practical risk | Severe. Internet exposure plus confirmed active exploitation plus a critical CVSS score together justify the shortest remediation clock the program has. | Materially lower, driven by exposure, not by the CVE's published severity. Still worth scheduled remediation — an internal network is not a permanent shield, and lateral movement from a compromised adjacent host remains possible. |
Where CVSS, EPSS, and KEV each fit
These three public signals answer different halves of the risk question. None of them is a determination that YOUR instance is or is not at risk. Last verified 10 September 2026. Not legal advice.
| Signal | What it measures | Publisher | What it does not measure |
|---|---|---|---|
| CVSS (Common Vulnerability Scoring System) | Intrinsic technical severity — how bad exploitation would be, given the vulnerability's technical characteristics. | FIRST (Forum of Incident Response and Security Teams). Individual base scores are commonly published by NVD or the CVE record itself. | Whether anyone is actually exploiting it, and whether YOUR specific asset is exposed. |
| EPSS (Exploit Prediction Scoring System) | A data-driven, machine-learning estimate of the probability a given CVE will be exploited in the wild in the next 30 days, across the population of systems generally. | FIRST. | Certainty. EPSS is a probability, retrained daily on population-level exploitation telemetry — not a verdict about YOUR estate, and not a guarantee for any single CVE. |
| KEV (Known Exploited Vulnerabilities catalog) | Confirmed, evidenced active exploitation in the wild, for specific CVE IDs CISA has verified. | CISA (US Cybersecurity and Infrastructure Security Agency). | Exploitation that has not yet been observed and verified. KEV is a lagging indicator; a CVE under active exploitation this week may not be listed yet. The how-to-prioritize guide on this site discusses combining these signals. |
Legal requirement, framework guidance, or best practice?
None of the terminology on this page is a legal mandate in itself. The table below labels each source. Not legal advice. Last verified 10 September 2026.
| Text | What it is | What this page does not do |
|---|---|---|
| NIST CSF 2.0 and the NIST CSRC glossary definition of 'vulnerability' | Voluntary NIST framework and reference glossary. Not a regulation. | Does not require YOU to adopt CSF 2.0 terminology. |
| NIST SP 800-30 (risk-assessment guidance) | Voluntary NIST guidance on conducting risk assessments. Not a regulation. | Does not run YOUR risk assessment or determine that SP 800-30 applies to you. |
| MITRE CVE Program and CWE Program | Community-run cataloging efforts, sponsored by CISA. Identifiers and classifications, not a legal mandate. | Does not classify YOUR software; assigning a CVE ID to a public disclosure is not this page's act and not this product's act. |
| FIRST EPSS | A published statistical model with no formal version numbers, retrained daily. Not a regulation. | Does not tell YOU whether YOUR instance will be exploited; it is a population-level probability. |
| CISA KEV catalog | CISA guidance and, separately, a binding mandate for US federal civilian agencies under a current CISA Binding Operational Directive. For everyone else, KEV listing is guidance and best-practice signal, not a legal mandate. The what-is-KEV guide on this site is that distinction in full. | Does not bind private-sector organizations by itself. Does not determine that any directive applies to YOU. |
What to do now
As of last verification on 10 September 2026, the definitions above have not changed. The list below is operational, not a determination that any standard applies to YOU.
- Stop treating a CVSS severity band as a priority order by itself. It answers impact, not likelihood or exposure — combine it with EPSS and KEV, as the how-to-prioritize guide on this site walks through.
- For any finding you are about to escalate as urgent, confirm actual network and business-context exposure before the CVSS score alone decides the SLA. The worked example above is the reason.
- Do not wait for a CVE to appear in KEV before treating high-EPSS, internet-facing findings seriously. KEV is confirmation, not the earliest signal.
- Keep 'vulnerability,' 'exploit,' and 'risk' as three separate fields in your own tracking — not three labels for the same severity number.
Where this shows up in ShipReady Metrics
Signed-in app → Security → Findings ingests vulnerabilities from connected sources (Dependabot, code scanning, secret scanning, DAST, and first-party SAST where configured), deduplicates the same underlying vulnerability across sources, and ranks findings using KEV status, EPSS score, and CVSS together rather than CVSS alone. Transitive-npm blast-radius analysis identifies which repositories actually resolve an affected package version through their lockfiles.
None of that changes the definitions on this page. The product surfaces the vulnerability, EPSS, and KEV signals; it does not calculate YOUR business risk, does not decide exposure for you, and does not patch YOUR estate. A named human still assesses context and owns the remediation decision.
This page does not document a public demo URL. There is no public vulnerability-management demo path.
Primary sources (last verified 10 September 2026)
Every terminology or scoring claim on this page is taken from one of these. NIST Cybersecurity Framework (CSF) 2.0 and the NIST Computer Security Resource Center glossary; NIST Special Publication 800-30 (Guide for Conducting Risk Assessments); MITRE's CVE Program and CWE Program (both sponsored by CISA); FIRST's Exploit Prediction Scoring System (EPSS); CISA's Known Exploited Vulnerabilities (KEV) catalog. These are not a complete world list. Not legal advice.
The what-is-KEV guide on this site covers the current CISA directive landscape in full. The CVE-vs-CWE-vs-CVSS guide on this site is the scoring-scheme comparison. The how-to-prioritize guide on this site is the decision-order page. A dedicated what-is-vulnerability-management pillar is not on this site yet. Naming it is not a link.
Frequently asked questions
Is a vulnerability the same thing as a risk?
No. A vulnerability is a weakness that exists whether or not anyone ever exploits it. Risk is that weakness combined with exploitability and the specific exposure of the asset it sits on. The same vulnerability can carry very different risk on two different systems, as the worked example on this page shows.
If a CVE has a critical CVSS score, is it automatically high risk for us?
Not automatically. CVSS scores intrinsic technical severity, not whether your specific instance is exposed or whether anyone is exploiting it. Combine the CVSS score with actual exposure, FIRST EPSS, and CISA KEV status before deciding urgency. This page does not run that assessment for you.
Does 'exploit exists' mean 'we are being attacked'?
No. Published or theoretical exploit code existing is different from confirmed active exploitation. CISA's KEV catalog specifically tracks the latter — confirmed, evidenced in-the-wild exploitation — while exploit-code availability is one input among several into scoring schemes like CVSS Threat metrics and FIRST EPSS.
Who decides our risk level — CVSS, EPSS, or KEV?
None of them, by itself. Each is a published, population-level signal. Deciding your organization's actual risk for a specific finding on a specific asset is a judgment a named person on your team makes, informed by those signals plus your own exposure and business-context knowledge. This product does not make that determination for you.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.