SecOps
Vulnerabilities, severity and exploit likelihood
A security finding is a report that something may need attention. This guide explains the identifiers and scores you see in SecOps so you can decide what to investigate without treating a score as the whole risk assessment.
A finding, a CVE and a CWE
These describe different things:
| Term | Meaning | Why it matters |
|---|---|---|
| Finding | A report from a tool about a particular target | The same underlying flaw can produce findings on several repositories or systems |
| CVE | A shared identifier for a publicly disclosed vulnerability | Lets you recognise the same vulnerability across advisories and tools |
| CWE | A category of weakness, such as a type of input-validation problem | Describes the kind of mistake behind vulnerabilities |
A code or cloud-configuration finding may have no CVE. Its absence does not invalidate the finding. Read the CVE Program glossary and MITRE's CWE explanations for the official terminology.
Severity and CVSS
Severity is the app's Critical, High, Medium, Low or Info label, normalised from the source. It determines the remediation deadline. SecOps does not automatically derive that label from the displayed CVSS number.
The Common Vulnerability Scoring System, CVSS, describes vulnerability severity on a scale from 0 to 10. Its version and metric groups matter; it is not a probability that your organisation will be attacked. See FIRST's CVSS user guide.
Use the advisory and source context to understand impact, exposure and affected versions. A high score on an unreachable component and a lower score on an exposed login service may need different responses.
EPSS probability and percentile
FIRST's Exploit Prediction Scoring System, EPSS, estimates whether a published CVE will be exploited in the wild during the next 30 days. Its probability is between 0 and 1; 0.02 means 2%. Its percentile is a rank relative to other CVEs, not the probability itself. A 95th percentile score does not mean a 95% chance of exploitation. See FIRST's EPSS documentation.
SecOps flags Likely exploitable when the available EPSS probability is at least 0.5, or 50%. That is an app threshold, not a claim that exploitation has been observed on your system. EPSS is supplied by your data or optional exploit lookup; a missing score is not proof that exploitation is unlikely.
Prediction and known exploitation are different
CISA's Known Exploited Vulnerabilities catalogue records vulnerabilities supported by evidence of exploitation. It answers a different question from a probability estimate. SecOps's EPSS flag does not mean a finding was matched to that catalogue, and the app does not automatically ingest KEV through the GitHub scratch path.
A worked triage example
Suppose one finding has a CVSS score of 9 and an EPSS probability of 0.02. Another has a CVSS score of 7 and EPSS of 0.7. The first has higher scored severity; the second has higher predicted exploitation likelihood. Neither number alone tells you which system is exposed, what data it handles or whether a fix is safe to deploy.
Read the affected versions, exposure, owner and deadline, then check the advisory. Record a decision or start a fix. In SecOps, Most urgent first sorts breached deadlines first, then severity and the earliest deadline. It is not an EPSS ranking.
What a finding cannot prove
A scanner report is evidence to assess, rather than proof of a breach. Conversely, no reported findings does not prove that a system is secure. Missing scans, coverage gaps and unreported weaknesses remain possible.
Continue with Working findings and Remediation deadlines.