Sorting by severity ranks your backlog for somebody else. CVSS is scored once, by someone who has never seen your deployment. Sort a backlog by it and a malicious package with a KEV listing lands underneath a wall of vendor sevens that nobody has ever attacked. A strategy replaces that with an ordered list of rules, stored against your organisation and applied to every finding as it lands: 15 signals to choose from, 23 rules in the shipped default, and the first matching rule decides the tier.
The signals you can rank
A rule is only worth dragging if the data behind it exists for every finding, every day. These are the signals available to a strategy today, with examples of the feeds that supply them.
Known malware
OpenSSF Malicious Packages (OSV MAL), OpenSourceMalware, Vulnetix Malscan, VDB malware advisories
The dependency itself is hostile rather than merely vulnerable. The system default ranks this above everything else, and most organisations leave it there.
KEV catalogues
CISA KEV, ENISA EU KEV, Vulnetix KEV, VulnCheck KEV
Four catalogues, four separate rules, so you decide whether an ENISA EU listing carries the weight of a CISA one. The shipped default reads them in that order, and Vulnetix KEV is our own evidence-driven catalogue for exploitation the authority lists have not reached yet.
Weaponized exploit
Metasploit modules, Nuclei templates, Snort rules, Nmap NSE scripts
Someone has packaged the vulnerability into a tool that runs. No research phase required, just a target list.
Active exploitation
CrowdSec honeypots, Shadowserver Foundation, CIRCL and MISP sightings
Attack traffic observed against real sensors, with a first-seen date kept on the signal. This is the rule that separates "could be attacked" from "is being attacked".
PoC exploit
Exploit-DB, VulnCheck XDB, GitHub PoCs, 0day.today, HackerOne and Bugcrowd disclosures, Project Zero 0day in the wild
Public proof the vulnerability is reachable in practice. Weaker than a packaged module, far stronger than a CVSS vector on its own.
Reachability
Vulnetix CLI tree-sitter reachability, semantic grep, symbol fallback
Whether the vulnerable routine is actually called from your code, not merely present in your lockfile. The CLI assesses a CVE against your call graph and records what it found. "Assessed unreachable" is a separate rule from "reachable", on purpose, because a finding nobody has looked at is not the same as one you have ruled out.
Traceability
SARIF locations from the Vulnetix CLI SAST and secret scanners, repo insights call graph
A code finding that resolves to a real file and line range is one an engineer can act on this afternoon. A stronger rule adds the call graph: the file the finding sits in is reached from something that runs. Two rules rather than one, so a graph-confirmed path can outrank a merely located one.
EPSS and Coalition ESS
EPSS (FIRST), Coalition ESS
Two models answering two different questions, which is why they get separate rules. EPSS asks whether an exploit for this CVE will surface publicly in the next 30 days. Coalition ESS asks whether attackers are using it now. A CVE can score low on one and high on the other, and the rule you put first decides which of those worries you more.
CVSS, CWSS and your own scores
NVD and CNA CVSS, CWSS, Custom CVSS, Custom CWSS
CVSS rates the vulnerability and arrives the same for everyone. CWSS rates the underlying weakness and is built to be tailored to your environment. Custom CVSS and Custom CWSS are the same scales after your analysts re-score them, which is how a critical that is not reachable in your deployment comes down and a medium in a payment path goes up.
Attack path
CVSS v2, v3 and v4 vectors, MITRE ATT&CK techniques and tactics, reachability and exploitation evidence
One CVSS metric rarely changes a priority. Chain AV:N, PR:N and UI:N and you have described an attack somebody can mount today, unattended, from anywhere. Add an ATT&CK technique or reachability as a third link and the rule fires only on the findings that carry the whole path.
All remaining
Ordered oldest first
Everything the rules above did not match. Exactly one of these, always pinned at the bottom, so nothing quietly falls out of the queue.
Those feeds are samples, not the list
Naming a handful of sources per rule keeps the explanation readable. The real inputs run much wider. The Vulnetix VDB is the largest global collection of vulnerability and patch data: 150+ upstream authorities aggregated, normalised and cross-referenced. Vulnerabilities from CVE, GHSA, OSV, PYSEC, RUSTSEC, GCVE, national CERTs and vendor PSIRTs. Exploits graded by maturity from a public PoC to a packaged module to a live honeypot sighting. Patch reality in each vendor dialect, from Microsoft Patch Tuesday to Red Hat RHSA to Canonical USN, with CSAF and VEX wherever upstream publishes it. Malicious package advisories and live indicators across ten ecosystems. End-of-life cycles for runtimes, frameworks, distributions and base images.
How a strategy works
Clone the read-only system default, drag the rules into your order, and save. Priority is the row position, and 0 is highest. Evidence signals such as malware, KEV and weaponized exploits match on presence; score signals take a comparison or a range, so "CWSS between 4 and 7" is a single row. One rule stays pinned at the bottom, All remaining, which sweeps up whatever the rules above did not catch, oldest first. Activate the strategy and the ranking applies wherever the queue appears: the What to fix first view, the dashboard priority widget, and the findings API.