The interval that matters
When a significant CVE is published, the operational question is narrow: do we run the affected thing, where, and does it matter. Answering it traditionally means a scan cycle, a spreadsheet reconciliation against an asset inventory of uncertain accuracy, and a round of emails to system owners. Eight days is a normal elapsed time for that workflow, and eight days is a long time to be uncertain about something an attacker learned at the same moment you did.
The reason it takes that long is rarely the analysis. It is that the asset inventory and the vulnerability catalogue are separate systems reconciled by people. Where the environment is already profiled continuously, a new CVE is a query rather than a project, and correlation across the estate completes in under ten minutes.
That interval is the whole use case. Everything downstream, the ranking, the patch decision, the compensating control, is work that can only start once you know where you stand.
Why CVSS alone ranks the wrong things first
CVSS describes the severity of a vulnerability in the abstract. It says nothing about whether anyone is exploiting it, whether the affected asset matters to your organisation, or whether the route to it is already closed by a control you have. Ranking by CVSS alone therefore produces a queue that is defensible on paper and wrong in practice.
Consider two findings. A CVSS 9.8 on an end-of-life gateway that sits behind strong segmentation with no reachable path, and a CVSS 7.5 that appears in the CISA known-exploited catalogue on a host adjacent to the enterprise network. The first outranks the second on severity and should not outrank it on the work queue.
Prioritisation therefore has to weigh three things together: how exploitable the vulnerability is in the real world, how much the affected asset matters, and what already stands in the way.
- Exploitability, from exploit prediction scoring and the CISA known-exploited catalogue rather than severity alone
- Asset criticality, taken from the asset record including business ownership and, where it applies, safety rating
- Network exposure, from reachability and peer breadth as actually observed rather than as designed
- Compensating controls, which subtract from the risk score rather than being noted alongside it
- Recent anomalies on the asset, decayed over time so an old finding stops dominating the score
Assessment without scanning what cannot be scanned
Parts of most estates cannot take an agent or an active scan. In industrial environments that is close to universal, and active scanning of production controllers has caused outages often enough that the practice is generally prohibited rather than merely discouraged.
Where Spharaka Signal™ is deployed, the device fingerprint is derived passively from observed traffic: stack behaviour, TLS fingerprints, hardware identifiers and protocol banners. That fingerprint is matched against the vulnerability catalogue, so a controller is assessed without receiving a single packet from the security platform.
On the enterprise side, EdgeProtect™ contributes process, network and operating system telemetry from managed endpoints, and the platform's entity profiles supply the rest. In both cases the assessment runs continuously against the inventory the platform already maintains, rather than against a snapshot taken during a scan window.
Being honest about what cannot be patched
In regulated and industrial environments, the answer to a vulnerability is frequently not a patch. Vendor-approved firmware only, change windows measured in months, and systems whose supplier no longer exists all mean that remediation is a negotiation rather than a task.
A prioritisation model that ignores this produces a permanent backlog and trains everyone to ignore it. Recording compensating controls as a factor that reduces the score is what keeps the ranking honest: a device behind enforced segmentation, with monitoring coverage and no reachable path, genuinely carries less risk than the same device without those things, and the score should say so.
It also produces the artefact an auditor asks for. When a decision not to patch for eighteen months is documented alongside what was done instead and why, it becomes a risk decision on record rather than an unexplained gap.
Where prioritisation meets the investigation
Vulnerability context is most useful when it is not a separate report. The same risk score that ranks the remediation queue appears in the investigation: when an alert fires on an asset, the analyst sees what that asset is worth, what it is exposed to, and what is known to be wrong with it, without opening another console.
It works in the other direction too. Threat intelligence enrichment maps observables to the MITRE ATT&CK framework and correlates dark web and nation-state activity into the same picture, so a vulnerability that becomes actively exploited changes its own ranking rather than waiting for someone to notice.
The result is one queue that reflects both what is broken and what is being attacked, rather than a vulnerability programme and a detection programme that meet at a monthly review.
Frequently asked questions
How quickly can a new CVE be correlated across the environment?
In under ten minutes, because the estate is already profiled continuously and the correlation is a query rather than a scan cycle. A traditional scan and reconcile workflow typically takes around eight days to answer the same question.
What is risk-based vulnerability prioritisation?
Ranking findings by the risk they actually present rather than by severity score. That means combining exploitability, from exploit prediction and the known-exploited catalogue, with asset criticality, observed network exposure, and the compensating controls already in place.
Why is CVSS not enough on its own?
CVSS describes a vulnerability in the abstract. It cannot know whether the flaw is being exploited in the wild, whether the affected asset matters to your business, or whether the path to it is already blocked. Ranking on CVSS alone routinely places an unreachable critical above an actively exploited high.
How are KEV and EPSS used?
The CISA known-exploited catalogue and exploit prediction scoring are overlaid on the severity rating so that real-world exploitation weighs on the ranking. A known-exploited vulnerability on a reachable asset outranks a higher-severity one with no observed exploitation and no path.
Can devices be assessed without scanning or installing an agent?
Yes. Where Signal is deployed, the device fingerprint is derived passively from observed traffic and matched against the vulnerability catalogue, so the device is assessed without receiving a packet. This is the default approach in industrial environments, where active scanning of production controllers is generally prohibited.
How are compensating controls handled?
As a factor that subtracts from the risk score rather than as a note beside it. Segmentation, monitoring coverage and access controls genuinely reduce exposure, and reflecting that keeps the ranking credible in environments where a great deal cannot be patched on any normal cycle.
Does this replace our vulnerability scanner?
It changes what the scanner is for. Continuous passive assessment covers the estate between scan windows and reaches equipment a scanner cannot safely touch, and the prioritisation layer consumes findings from whatever sources you already run alongside its own.
Cyber threat intelligence
The enrichment that establishes exploitability.
Spharaka Signal™
Passive assessment for equipment that cannot be scanned.
OT asset discovery
The inventory this prioritisation depends on.
Lateral movement detection
Exposure understood as a path rather than a list.
Spharaka Sphere™
Where the risk score meets the investigation.