Showing what to fix first, without a black-box risk score
Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.
Intro
“Risk-based” has become a marketing word that usually means a vendor multiplies some numbers together and hands you a score you can’t question. I went the other way with RiskRancher. Prioritization here is a handful of honest counts: how many open findings you have, broken down by severity and by source, combined with the SLA deadlines from the last post. No black box. This post is about why transparent beats clever for deciding what to fix first.
I. “Open” is the number that matters
The dashboard’s foundation is a single idea: only count work that’s actually still work. A finding that’s Patched is done. A finding that’s Risk Accepted was a deliberate decision. Neither should inflate your “how much is left” number. So every analytics query starts by excluding those two:
SELECT COUNT(*) FROM tickets
WHERE status != 'Patched' AND status != 'Risk Accepted'
That’s your real open count. It doesn’t drift up because old fixed findings linger, and it doesn’t nag you about things you’ve consciously chosen to accept. The headline number means exactly what it says: open work remaining.
II. Where the risk concentrates
From there, the summary groups the open findings two ways. By severity, so you can see how many Criticals and Highs are actually outstanding:
SELECT severity, COUNT(*) FROM tickets
WHERE status != 'Patched' AND status != 'Risk Accepted'
GROUP BY severity
And by source, so you can see which scanner is generating your open load. Those two breakdowns answer the two questions you actually have in front of a backlog: how bad is what’s left, and where is it coming from. A pile of open Criticals says “triage now.” A huge open count from one noisy scanner says “maybe tune that scanner, or build a better adapter for it.”
III. Severity plus SLA is the priority
Put the pieces together and prioritization isn’t a score, it’s a conversation between three plain facts: the severity of a finding, whether it’s still open, and how close it is to its SLA deadline. A Critical that’s open and past its 14-day SLA is the top of your list. A Low that’s open with weeks of SLA left can wait. You don’t need a proprietary algorithm to see that, you need the severity, the status, and the clock, all of which are visible and checkable.
IV. Why transparent wins here
A black-box risk score has a real problem in security work: when someone asks “why is this ranked above that?”, the honest answer is often “the vendor’s formula said so.” That doesn’t hold up in a remediation meeting, and it doesn’t build trust. Counts you can reproduce with a SQL query do. Anyone can look at RiskRancher’s prioritization and see precisely why the list is ordered the way it is, because it’s just open findings, by severity, against their deadlines. For a tool security people rely on, being auditable is worth more than being clever.
Conclusion
Deciding what to fix first doesn’t require a mysterious score. It requires knowing what’s genuinely open, how severe it is, where it came from, and when it’s due. RiskRancher computes those with queries you could write yourself, and that transparency is the feature: a priority order you can defend. If you’re building prioritization into anything, consider showing your work instead of hiding it behind a number. Thanks for reading, and may your Criticals be few and your SLAs generous.