Most vulnerability reporting in Australian organisations still terminates in a severity histogram. Forty-one criticals, two hundred and eighteen highs, a chart in three colours. Everyone nods. Nothing about that slide tells anyone what to do on Monday, and nothing about it would survive a serious question from a director.
The reason is structural. CVSS measures how bad a vulnerability would be if exploited. It does not measure whether anyone is exploiting it. Only a small fraction of published vulnerabilities are ever observed being exploited in the wild. A list sorted by severity is therefore, for the most part, a list sorted by hypothetical.
The good news is that the three signals needed to convert that list into a decision are all free, all public, and all API-accessible today.
Signal one — KEV: confirmed exploitation
CISA’s Known Exploited Vulnerabilities catalogue lists vulnerabilities with documented in-the-wild exploitation. Inclusion requires evidence and human verification, which makes it high-precision and low-volume — KEV covers well under one per cent of all published CVEs.
Its value is that it carries no model lag. When Oracle disclosed CVE-2026-35273 in PeopleSoft on 10 June 2026, CISA added it to KEV two days later. Anything on KEV that exists in your environment is not a prioritisation question. It is a work order.
Published as CSV and JSON, updated continuously, free.
Signal two — EPSS: probability of exploitation
The Exploit Prediction Scoring System, maintained by FIRST, produces a daily probability between zero and one that a given vulnerability will be exploited in the next thirty days. It is trained on observed exploitation signals rather than on theoretical impact, which makes it the useful counterweight to CVSS.
Two operational points that are routinely missed:
EPSS v4 changed the eligibility rules. Since March 2025, EPSS scores CVEs sitting in the NVD analysis backlog that do not yet carry an official CVSS score. This closed a real gap — previously, brand-new CVEs awaiting NVD analysis could not be scored at all. If your enrichment pipeline requires a CVSS score before it queries EPSS, it is silently discarding the newest vulnerabilities in your environment, which are frequently the ones that matter. Query EPSS by CVE identifier directly, regardless of NVD status.
EPSS lags fresh exploitation waves. Because it is a model trained on propagating threat signal, a CVE that entered active exploitation yesterday may still score low today. This is not a defect — it is why KEV must remain a separate first-tier check rather than being folded into a composite score. Anyone who has collapsed KEV and EPSS into a single weighted number has engineered out the one signal with no lag.
Signal three — SSVC: the decision, not the score
This is the piece most Australian programmes are missing, and it is the piece a board actually needs.
The Stakeholder-Specific Vulnerability Categorization model does not produce a number. It walks a decision tree and produces an action. CISA publishes SSVC decision points through its Vulnrichment programme, and the data is free — it is written into the Authorized Data Publisher container of the standard CVE JSON record. If you are already pulling CVE data from the CVE Services API or the public CVE list repository, you are already downloading Vulnrichment data. It is a parsing exercise, not an integration project.
The decision points that carry the weight:
- Exploitation — none, proof-of-concept exists, or active in the wild
- Automatable — can an attacker reliably automate reconnaissance and exploitation at scale? This is the distinction between a targeted risk and a mass-scanning risk, and it is the one executives understand immediately
- Technical Impact — partial or total control of the affected component
- Plus a KEV block where the vulnerability appears in the catalogue
The output is a decision category — Track, Track*, Attend, Act — that maps to a defined response timeframe rather than to a colour.
What it answers: is it confirmed exploited, right now, in the wild?
Inclusion requires evidence and human verification, which makes it high-precision and low-volume. Its value is that it carries no model lag. When Oracle disclosed CVE-2026-35273 in PeopleSoft on 10 June 2026, CISA added it two days later.
How to use it: anything on KEV that exists in your environment is not a prioritisation question. It is a work order. Published as CSV and JSON, updated continuously, free.
What it answers: how likely is exploitation in the next thirty days?
Two operational points routinely missed. Since EPSS v4, the model scores CVEs sitting in the NVD backlog that have no official CVSS score yet. If your enrichment pipeline requires a CVSS score before querying EPSS, it is silently discarding the newest vulnerabilities in your environment.
Second: EPSS lags fresh exploitation waves. A CVE that entered active exploitation yesterday may still score low today. That is why KEV must remain a separate first-tier check rather than being folded into a composite score.
What it answers: so what do we actually do?
SSVC does not produce a number. It walks a decision tree and produces an action. CISA publishes the decision points through Vulnrichment, written into the Authorized Data Publisher container of the standard CVE JSON record.
If you already pull CVE data from the CVE Services API or the public CVE list repository, you are already downloading Vulnrichment data. It is a parsing exercise, not an integration project.
The decision point that carries the most weight with executives is Automatable — the distinction between a targeted risk and a mass-scanning risk.
A working triage order
Applied consistently, in this sequence:
- 1. Is it on KEV? Confirmed exploitation. Act now. No further analysis required.
- 2. Is SSVC Exploitation active, or Automatable yes? Act or Attend. Mass exploitation is either occurring or trivially achievable.
- 3. Is EPSS elevated? Attend. The model sees signal even without confirmed reporting yet.
- 4. Is it internet-facing? This is the multiplier that overrides the rest. A moderate vulnerability on an exposed asset outranks a critical one on a segmented internal host, every time. June 2026 made that argument better than any framework document could.
- 5. Everything else. Track to the standard remediation cycle, documented.
Note where CVSS sits: it is the input that gets a vulnerability onto the list, and a record auditors expect to see. It is not the thing that determines order.
Why this is a governance instrument, not a tooling upgrade
Australian directors are being asked with increasing directness to demonstrate that cyber risk decisions were reasoned. Not that every vulnerability was closed — that has never been the standard — but that the ones left open were left open deliberately, on a documented basis.
A severity histogram cannot support that. It records that something was known and does not record why it was deferred. A KEV/EPSS/SSVC triage produces the missing artefact: for every finding not remediated, a recorded decision, a rationale drawn from public exploitation evidence, and a date. That is the difference between a security report and an assurance record, and it is the difference that matters if the question is ever asked after an incident rather than before one.
The signals are free. The data is public. The only real work is deciding to stop shipping the histogram.