These four signals answer different questions. CVE names a disclosed vulnerability; CVSS describes severity; EPSS estimates near-term exploitation probability in the wild; KEV records known exploitation. None independently establishes the risk to a specific asset.
What it is
Vulnerability records and scores help teams organize technical information, but they are not interchangeable. A CVE identifier gives a shared reference for a vulnerability. A CVSS assessment represents severity under a defined version and set of assumptions. EPSS is a probability model for exploitation in the wild over the next 30 days. CISA’s KEV catalog records vulnerabilities with evidence of exploitation.
An asset-specific finding adds another layer: whether the affected product and conditions are actually present. A public service that resembles an affected technology is a candidate match, not automatically a confirmed instance. Keep the intelligence record separate from the evidence about your deployment.
Explore this topic in depth
CVE identifiers and applicability5 min readCVSS severity scores and vectors5 min readEPSS exploitation probability5 min readKnown Exploited Vulnerabilities (KEV)5 min readHow it works
Start with the identifier and the authoritative advisory. Determine the affected products, versions, configurations and prerequisites. Then use severity, exploitation evidence and likelihood information to inform the response. Finally, add the asset’s exposure, privileges, business role and available controls.
Signals have different time meanings
A CVE publication date describes disclosure in the record system, not necessarily discovery or first exploitation. A KEV date added describes catalog inclusion. An EPSS score belongs to a dated prediction. A CVSS assessment can change when the understood conditions change. Preserve these dates rather than presenting all values as timeless facts.
Applicability is a gate
A high score for an absent component does not create an affected asset. An uncertain version banner should trigger verification. Conversely, a confirmed affected, reachable system should not be ignored because one intelligence source lacks a value. Missing data is an evidence gap, not a favorable score.
| Signal | What it tells you | What it does not establish |
|---|---|---|
| CVE | A shared identifier and vulnerability record | That a particular asset is affected |
| CVSS | Severity under a stated version and vector | Exploitation probability or organization-wide risk |
| EPSS | Dated probability of exploitation in the wild over the next 30 days | The probability your organization will be breached |
| KEV | Known exploitation evidence for a cataloged vulnerability | That your own asset was exploited |
Technical references: CVE Program · Record User Guide · FIRST · CVSS v4.0 Specification
How attackers use it
Public advisories can help attackers identify weaknesses and relevant technologies, just as they help defenders plan remediation. The existence of a public identifier or proof-of-concept discussion does not establish successful exploitation against a particular organization.
Defenders should use intelligence to ask better questions: is the vulnerable feature present, can the required access path be reached and what actions could follow? The intelligence signal is most useful when connected to the actual deployment rather than treated as a substitute for that connection.
Warning signs
Prioritize review of confirmed affected internet-facing systems, credible exploitation evidence and weaknesses that expose consequential privileges or data. Also investigate inconsistent source assessments, stale intelligence and findings based only on ambiguous fingerprints.
Common interpretation errors
Severity is not probability. A percentile is not a probability. Known exploitation elsewhere is not proof of a local incident. Absence from KEV is not proof of safety. A scanner label is not the same as a vendor-confirmed affected deployment. These distinctions should remain visible in the finding record.
Business impact
Misusing signals can divert effort toward irrelevant findings while consequential exposures remain open. It can also create false urgency or false reassurance in management reports. A consistent decision model helps explain why a particular finding was addressed first.
Business consequences depend on the affected service and the access a weakness enables. The same CVE can have different operational importance across deployments. Record the local reasoning so later changes in hosting, controls or intelligence can trigger a reassessment.
Prevention and remediation
Use a structured record containing the identifier, source advisory, applicability evidence, score version and vector, dated exploitation information, asset context, owner and selected action. Avoid collapsing uncertainty into one unexplained number.
Decision sequence
- Verify the affected component and required conditions. - Establish relevant reachability and privileges. - Review known exploitation and dated likelihood information. - Evaluate business impact and compensating controls. - Select a fix, mitigation or explicitly reviewed exception. - Verify the resulting state and revisit the decision as evidence changes.
A temporary restriction and a software fix should be recorded separately. One may reduce the immediate path while the underlying affected component remains. Closure needs acceptance criteria appropriate to the action actually taken.
How Ariema detects or handles it
Ariema provides context for possible CVE matches and connects them with external service and observation evidence. This can help a reviewer assess which asset and deployment need confirmation and retain the basis for follow-up.
The documented workflow should not be assumed to calculate every CVSS assessment or ingest every intelligence feed automatically. Teams should verify the provenance and date of the signals they use. Ariema’s observation and retest records support the asset-specific part of that review without converting a possible match into confirmed exploitability.
Common questions
Which number is the risk score?
There is no universal organization-risk score among these signals. Risk assessment still needs applicability, access paths, controls and business consequences.
Can a low EPSS score override KEV membership?
No. A model estimate and evidence of known exploitation are different types of information. Known exploitation should remain an explicit input rather than being erased by a lower forecast.
Can two sources disagree about CVSS?
Yes. They may use different versions, assumptions or assessments. Preserve the source, vector and version rather than averaging incompatible numbers.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
CVE Program · Record User GuideFIRST · CVSS v4.0 SpecificationFIRST · EPSS Frequently Asked QuestionsCISA · Known Exploited Vulnerabilities Catalog