How does ShipReadyMetrics prioritize vulnerability risk?

This explains a method, not a guarantee

Audience: a prospective buyer, a current user, or an engineer who wants to see exactly how findings get ordered before trusting the order. This is the one page in this cluster that is intentionally about this product rather than vendor-neutral practice — every other page in this cluster stays neutral. It is not legal advice, does not determine that any legal or framework obligation applies to YOU, and does not prove that any specific system has no unaddressed risk.

The point of this page is falsifiability: every claim below names the actual signal, the actual source, and what that signal does not tell you, so the method can be checked rather than taken on faith. Last verified 10 September 2026.

Nothing on this page is a promise about a future capability. It describes what the shipped method does today, and it says plainly where that method stops.

Inputs — what the ranking actually uses

The table below lists each input to the ranking and the vendor-neutral explainer on this site that describes it without any product framing. Read the explainer to understand the underlying concept; read this section to understand how this product specifically uses it. Last verified 10 September 2026. Not legal advice.

How the inputs combine — the actual tie-break order

The open-findings queue is not one blended score; it is a deterministic tie-break, evaluated in this order: (1) whether the finding is actively exploited per CISA KEV, descending; (2) how many days it is past its own remediation deadline, descending; (3) severity rank, most severe first; (4) the finding's highest published EPSS score, descending; (5) oldest first-seen date, then a stable identifier, as the final tiebreak. Each finding also shows the specific reasons behind its position — the fact and the source — rather than an opaque number. Last verified 10 September 2026. Not legal advice.

Exploitation outranks severity by design: a moderate-severity finding under confirmed active exploitation is treated as a worse problem than a high-severity finding nobody is known to be exploiting. An overdue deadline the organization itself set outranks a fresh severity label for the same reason — it is a stronger, more comparable claim on attention than a scanner's assigned severity, and every incident review tends to agree with that ordering after the fact.

• A finding with no readable first-seen date is shown as undatable, not silently treated as fresh or excluded — an unmeasured finding is not the same as a zero.
• A finding with no CVE identifier gets no EPSS or KEV line at all, rather than a hedged or assumed one.
• The queue is reproducible: given the same finding data and the same date, the order does not vary.
• Ties that survive every stated tiebreak fall back to a stable identifier, so the order is always fully determined rather than arbitrary at the margin.

What this method does not claim

The list below states the boundaries of the method as plainly as the method itself. None of these are footnotes; each one changes how a result here should be read. Last verified 10 September 2026. Not legal advice.

• It does not patch anything. Ranking a finding does not fix it; a named human still applies, verifies, and closes every remediation.
• It does not determine legal applicability. Flagging a finding, or noting that KEV or a framework control might touch it, is not a determination that any statute, directive, or certified control binds YOU.
• It does not prove the absence of risk. A clean queue reflects only what was ingested from connected sources and successfully matched to a CVE; it is not a claim that no other risk exists.
• EPSS is a probability, not a verdict. A high EPSS score means the model estimates a higher likelihood of exploitation across similar vulnerabilities in a population — it is not a statement that YOUR specific instance will be exploited.
• KEV absence is not safety. The KEV catalog is a lagging indicator: a vulnerability under active exploitation right now may not be listed yet. A finding not flagged as KEV-exploited has not been cleared; it has simply not (yet) been confirmed.
• Blast radius is scoped to npm lockfiles that were actually fetched. Yarn, pnpm, NuGet, PyPI, and npm repositories without a readable lockfile are reported from what the manifest declares, not from a resolved transitive tree — a package pulled in only transitively through one of those paths may not appear.
• It does not know reachability. The method ranks by exploitation evidence and probability, not by whether the vulnerable code path is actually called in YOUR deployment.

How to check this yourself

This page is written so the method can be checked, not just trusted. The table below points at the specific fact to look for on a given finding, and what it would mean if that fact were missing or wrong. Last verified 10 September 2026. Not legal advice.

What to do now

The list below is how to use this method responsibly, not a claim that using it discharges any legal or framework obligation. Last verified 10 September 2026. Not legal advice.

• Treat the queue order as a strong default, not a final answer — a person with deployment knowledge is allowed to override it, and the override should be recorded.
• Check the inputs table above against what your organization has actually connected before assuming a low finding count reflects a genuinely low-risk estate.
• Read each finding's stated reasons, not just its position, before deciding whether to act.
• For a package-level exposure question, check whether the answer came from a resolved npm lockfile or a declared manifest before treating a 'not found' result as reassurance.
• Pair this product's ranking with your own asset-exposure knowledge; the method has no visibility into whether a given code path is actually reachable in YOUR deployment.
• Do not cite this product's ranking as a legal determination that any framework, directive, or statute has been satisfied.
• Connect the sources relevant to your estate before drawing conclusions from an empty or short queue; an unconnected source contributes nothing to the ranking.

Where this shows up in ShipReady Metrics

If you already have a session: signed-in app → Security → Findings is the continuous operating layer this page describes — the queue is recomputed as findings are ingested, enriched, and updated, not generated once and frozen. It is not a complete enterprise-wide asset inventory, it does not apply patches to YOUR estate, and it does not file with CISA, ENISA, or any market-surveillance authority.

This page describes the method the shipped product actually runs, not a roadmap or an aspiration. Any capability not described above is not part of this method. This page does not document a public demo URL.

Primary sources (last verified 10 September 2026)

Every third-party signal claim on this page is taken from one of these; the method description itself is drawn from the shipped product, not from marketing material.

FIRST's Exploit Prediction Scoring System (EPSS) publishes a daily exploitation-probability score for CVEs — a model output, not a verdict. The CISA Known Exploited Vulnerabilities (KEV) catalog lists CVEs with reliable evidence of active exploitation — a lagging indicator, not a complete list of what is currently exploited. FIRST's Common Vulnerability Scoring System (CVSS) rates a vulnerability's intrinsic severity, not its likelihood of exploitation. MITRE's CVE program assigns the identifiers this method uses to correlate findings across sources. These are not a complete world list. Not legal advice.

The CVE-vs-CWE-vs-CVSS, what-is-KEV, how-to-prioritize-vulnerabilities, exploitability-vs-severity, what-is-an-SBOM, and how-to-detect-vulnerable-open-source-packages guides on this site are the neutral explainers this page's inputs map to. The vulnerability-management glossary entry on this site is the education page under glossary. This page describes the vulnerability-management ranking specifically; it does not describe how any other part of the product scores unrelated categories such as code quality or delivery metrics.

Frequently asked questions