Synced 17 Jun 2026 22:27 UTC Account
← Home

Methodology

How every score is calculated · last updated June 2026

Every version score rates one specific version of a product — never its maintainers or vendor. A low score means that version has known unpatched vulnerabilities; the current release almost always scores far higher.

The product-level score — the single number shown next to a product name in lists — rates that product's latest supported release. Where no supported release is published (some appliances and vendor products have no lifecycle data), it instead reflects all tracked versions of that product and is labelled "all versions", so an aggregate is never mistaken for a single release.

IsItPatched answers one question — is your software version safe? — by combining four authoritative, free data sources into a single plain-English verdict.

Data sources

  • NVD (NIST National Vulnerability Database) — CVEs, CVSS severity, and affected-version ranges.
  • CISA KEV — the Known Exploited Vulnerabilities catalog (what's being exploited in the wild right now).
  • EPSS (FIRST.org) — the probability a vulnerability will be exploited.
  • endoflife.date — product support lifecycles and latest released versions.
  • Ubuntu Security Notices (USN) — Canonical's per-release security advisories and the CVEs they fix, used for Ubuntu releases.

The health score (0–100)

Every version starts at 100 and loses points for the known vulnerabilities affecting it:

  • −15 per open Critical CVE (max −45)
  • −8 per open High CVE (max −32)
  • −3 per open Medium CVE (max −18)
  • −15 if any open High/Critical has an EPSS exploitation probability over 50%

Two hard caps override the maths:

  • If a vulnerability is actively exploited (in CISA KEV), the score is capped at 20 — it can never read "healthy."
  • If the version is end-of-life, the score is capped at 40 — no patches are coming.

Higher = safer. Bands: 90–100 Healthy · 70–89 Good · 50–69 Attention · 20–49 High risk · 0–19 Critical.

Multi-dimensional risk model

A single 0–100 score is great for a quick "is this safe?" lookup, but it blends signals that buyers want to see separately. So for an SBOM scan and your monitored stack we also break risk into named dimensions, each scored on its own. The blended score stays the headline; the breakdown is the stack-level view. We only show what an artefact can honestly tell us — where the data isn't there, the dimension reads "not assessed" rather than a guess.

  • Vulnerability — share of assessed components/products with at least one known open CVE. On the SBOM scan this is matched against OSV, and each component's CVE IDs are checked against the CISA KEV catalogue so actively-exploited components are flagged and floated to the top; for tracked products it reflects the same CVE data behind the health score (severity × active exploitation × EPSS). Verdict colour: green at 0%, amber when present, red when anything is actively exploited or a large share is affected.
  • Version — share of components/products pinned below an available fixed release. For an SBOM this is derived from OSV's "fixed-in" data; for tracked products it's the recorded version vs the minimum safe version. We don't have a package registry's "latest stable" for every ecosystem, so this measures "you could upgrade out of a known issue", not raw release age — stated plainly rather than overclaimed.
  • End-of-life — components/products on a release line past end-of-support, where no security fix is coming. Real for tracked products (we hold lifecycle data from endoflife.date and vendor notices); not assessed per component on a raw SBOM scan, because arbitrary packages carry no lifecycle data — it's shown as "—" there rather than faked.
  • Licence — share of components whose licence is restrictive/reciprocal (copyleft: GPL, AGPL, LGPL, SSPL, MPL…) or undeclared/unrecognised. Read straight from the SBOM's own metadata (CycloneDX licenses / SPDX licenseConcluded); strong copyleft (AGPL/SSPL) is flagged red. This is the dimension legal & procurement care about. We never guess a licence — anything we can't positively identify is counted as "unknown", not assumed permissive. The permissive / copyleft / strong-copyleft mapping lives in a published config (data/licence-risk.json), so the families are tunable without code changes.
  • Unmatched — share of components we could not map to a known package source (no usable package URL). This is the honest-coverage signal: it's always shown, never hidden, so you know exactly what was and wasn't checked — the opposite of a false "all clear".

Each dimension is a simple share of the relevant denominator (shown on the figure, e.g. "12 of 80 analysed"), rounded to a whole percent, with a green/amber/red verdict colour. The same breakdown is rendered in the dashboard and carried into every compliance evidence pack.

Patch-queue priority (Act / Attend / Track)

The health score rates technical risk. But which fix is most urgent for you also depends on where the software runs and how much it matters — a critical CVE on an internet-facing, business-critical system is not the same as the same CVE on an isolated lab box. So the My Stack patch queue ranks each item with a transparent, SSVC-inspired priority that combines our technical signals with two pieces of context you set per product. Nothing is hidden — every point is shown on the row.

Priority starts at 0 and adds:

  • Actively exploited (CISA KEV): +50 (+5 per extra exploited CVE, capped +20)
  • else an open Critical CVE: +25 · else an open High CVE: +12
  • End-of-life (no fixes coming): +15
  • Exposure you set — Internet-facing +25 · Internal network +8 · Isolated / air-gapped +0
  • Importance you set — Business-critical +20 · Standard +6 · Low +0

The total maps to a decision: Act now (≥70) · Attend (35–69) · Track (<35). Exposure and importance default to Internal / Standard until you set them, and are stored only in your browser (synced to your account if you sign in) — never used to rank anything but your own queue. This mirrors the logic of CISA's SSVC (Stakeholder-Specific Vulnerability Categorization) decision model; it's a prioritisation aid, not a substitute for your own risk assessment.

"Latest safe version" & "fixed in"

We take the latest supported release from endoflife.date, and read the first patched version from NVD's version-range data (the version a CVE was fixed in).

Operating-system releases (e.g. Ubuntu)

OS distributions don't fit the version-range model app frameworks use — Canonical backports security fixes into supported Ubuntu releases and tracks them through Ubuntu Security Notices (USN), not NVD version ranges. So a release page such as Ubuntu 24.04 does not claim a per-version "patched" score. Instead it shows the release's support status (still receiving updates, or end-of-life), its most recent security notices, and the CVEs they fix. The honest answer for an OS is that security depends on the updates you have actually applied — keep the system current (apt update && apt upgrade), not on the release number alone.

Update cadence

Data refreshes daily, and the actively-exploited feed more often. Every page shows when it was last checked.

Limitations (please read)

  • We surface known issues. Absence of a listing is not a guarantee of safety.
  • NVD can lag in enriching brand-new CVEs, and some lack precise version data — so counts may be conservative.
  • Build-numbered products (Microsoft, VMware, F5, some Cisco) are assessed at product level on recent activity, pending exact-build data — we never show them a false "healthy."
  • This is informational, not a substitute for your vendor's advisories. See our disclaimer.