Interactive demo
Try the triage.
Three findings from an invented estate. Pick one and see why it scores what it scores — every point attributable to a named factor, which is the whole argument for ranking this way.
Synthetic data. Every host and advisory below is invented.
Hostnames use example.com, reserved for documentation, and the
advisory identifiers are deliberately not real CVE numbers. This page runs
entirely in your browser, talks to no system, and changes nothing. It is not a
live console and no customer data appears in it.
Ordered by CVSS
- 1Remote code execution in edge VPN appliance9.8
- 2Privilege escalation in kernel package7.8
- 3Deprecated TLS version accepted5.3
Ordered by Exploit Hound
- 1Remote code execution in edge VPN appliance96
- 2Deprecated TLS version accepted40↑ 1
- 3Privilege escalation in kernel package36↓ 1
The kernel bug is the more severe vulnerability and ranks last here, because reaching it needs a foothold on the host first. Last is not harmless — it is a local escalation to root on a build runner, and it stays on the list until it is patched. Ranking says what to do first, not what to drop.
Ranked by what the score says
Select a finding to see the arithmetic behind its rank. Every number below is a sum of the factors listed with it.
Conditions on the selected finding
Each box is ticked when the statement beside it is true of the finding shown — untick one to see the same finding under different circumstances.
Remote code execution in edge VPN appliance
vpn-edge-01.example.com · EXAMPLE-2026-0001
96 Fix now
| Base severityCVSS 9.8 | +34 |
|---|---|
| Exploitation likelihoodListed as known exploited; public exploit available | +24 |
| ExposureReachable from the Internet | +18 |
| Business contextCritical asset: remote access for all staff | +10 |
| ConnectivityParticipates in 3 attack paths to a domain controller | +8 |
| Evidence strengthSafely validated — negotiated version confirmed | +2 |
| Total | 96 |
How it is reachable
- Internet
- vpn-edge-01
- fileserver-02
- dc-01 (domain controller)
Recommended fix
Apply the vendor firmware update, then re-check from outside.
Internet-facing and known exploited: this is the one to do first.
Deprecated TLS version accepted
mail-01.example.com
40 Moderate
| Base severityConfiguration weakness | +14 |
|---|---|
| Exploitation likelihoodNo known exploitation in the wild | +2 |
| ExposureReachable from the Internet | +18 |
| Business contextNormal criticality | +4 |
| Evidence strengthSafely validated — TLSv1.0 negotiated | +2 |
| Total | 40 |
How it is reachable
- Internet
- mail-01
Recommended fix
Disable TLS 1.0 and 1.1 on the listener; keep 1.2 and 1.3.
Reachable, but nothing is exploiting it. Schedule it; do not drop the VPN appliance to do it.
Privilege escalation in kernel package
build-runner-04.example.com · EXAMPLE-2026-0002
36 Low
| Base severityCVSS 7.8 | +27 |
|---|---|
| Exploitation likelihoodNo public exploit observed | +4 |
| ExposureInternal only — no route from the Internet | +0 |
| Business contextNormal criticality | +4 |
| Evidence strengthDetected from installed package version | +1 |
| Total | 36 |
How it is reachable
- Foothold inside the network
- build-runner-04
Recommended fix
Patch the kernel package on the next maintenance window.
Ranked last, not dismissed. This is a local escalation: it needs an attacker already on the host, and it gives them root on a build runner if they get there. It is scheduled work, not ignorable work.
This is an illustrative model, not the production one. The six
factors above are a teaching example with fixed weights, chosen so the arithmetic
fits on one screen. The platform’s scoring engine is a versioned model
(currently 1.0) recorded on every finding it
scores: more factors, inputs read from collected evidence rather than typed in,
and negative factors for accepted risk and compensating controls. What the two
share is the shape of the claim — a total that is the sum of named,
inspectable factors — and the band thresholds.
How the risk score is built, factor by factor →
What happens next
The panel above answers why a finding ranks where it does. This is the part after that: the change is raised, the verification comes back partial, and one of the fixes comes back a fortnight later. Same three invented hosts throughout.
Every step here is drawn, not run. This page reaches no scanner, no PSA, no RMM and no host. There is no API behind it — the tickets, scans and verifications below are pictures of what the console does, on invented data.
Step 1 of 4Simulated
Something urgent is at the top
The queue opens on the finding with the highest score, not the highest CVSS.
- vpn-edge-01.example.comFix now · 96Internet-facing, known exploited, and on three attack paths to a domain controller.
- mail-01.example.comModerate · 40Reachable, but nothing is exploiting it.
- build-runner-04.example.comLow · 36Local escalation. Needs a foothold on the host first — scheduled work, not ignorable work.
One change is worth doing today. The other two are on the list and stay there until they are done.
Step 2 of 4Simulated
The work is raised and run
Fix First groups the findings into the change a technician performs, and that change is what gets ticketed.
- vpn-edge-01.example.comTicket raisedOne ticket for the firmware update, not one per finding. Re-running the recommendation would update it rather than open a second.
- mail-01.example.comTicket raisedDisable TLS 1.0 and 1.1 on the listener, scheduled for the next window.
- build-runner-04.example.comLeft queuedDeliberately not actioned today, so the walkthrough can show what an unverified asset looks like.
Approved actions run from a fixed catalogue. Nothing here runs anything: this step is a drawing of a ticket, not a ticket.
Step 3 of 4Simulated
Verification comes back partial
The asset is re-checked and the exposure graph recalculated. Three assets, three different answers — which is the normal case, not the awkward one.
- vpn-edge-01.example.comVerified fixedRe-checked from outside: the vulnerable version no longer negotiates. Two of the three attack paths to the domain controller are gone with it.
- mail-01.example.comStill affectedThe change was applied to one listener and the finding is on another. The ticket stays open; nothing was closed on the strength of the RMM reporting success.
- build-runner-04.example.comCould not verifyThe agent has not checked in since before the work started, so there is no current evidence either way. Reported as unverified — never as fixed.
An RMM reporting success is not evidence. The re-check is, and where there is no re-check the platform says so.
Step 4 of 4Simulated
A fortnight later, one of them comes back
A fix this platform verified, found open again on the same asset. That is a different event from a finding that was never fixed.
- vpn-edge-01.example.comRegressionThe appliance was restored from a pre-update configuration backup during unrelated maintenance, and the firmware went with it. Verified fixed on the 3rd, open again on the 17th.
- mail-01.example.comVerified fixedThe second listener was found and corrected on the follow-up ticket.
- build-runner-04.example.comStill affectedThe agent checked in. The kernel package is still the vulnerable version, so the finding was never fixed rather than fixed and returned.
A cause is named only when a record names the finding. Here a configuration restore does; if nothing did, this would say the cause is unknown rather than guess from the timing.
OutcomeSimulated
What the fortnight actually produced
- Two findings verified fixed by re-checking the asset, not by anyone reporting them done.
- One regression caught with a named cause, because the platform knew it had verified that fix before.
- One asset still affected, and it was never at any point counted as fixed.
- Nothing was closed on an assertion. The asset that could not be re-checked was reported as unverified until it could be.
What this is showing
The score is a sum, not a verdict
Base severity, exploitation likelihood, exposure, business context, connectivity and evidence strength. You can argue with a number when you can see what built it.
Reachability changes the order, not the list
The same vulnerability on an isolated build runner and on an Internet-facing appliance are not the same problem, and a list sorted by CVSS cannot tell you that. Neither one leaves the list until it is fixed.
Evidence is graded
Detected, high confidence and safely validated are different claims. The console says which one it is holding, on every finding.