Methodology

Identifiers & merging

The CVE ID is the primary key. GitHub (GHSA), ENISA (EUVD) and other databases often describe the same issue under their own ID; when a record lists a CVE alias it is merged into that CVE, and its identifier is shown as an alias. Records without a CVE — common for open-source packages — keep their own ID (for example GHSA-xxxx-xxxx-xxxx).

Advisories (BSI bulletins, Red Hat RHSA, Debian DSA, Ubuntu USN …) are kept as separate documents and linked to every CVE they cover, so one advisory can fix many vulnerabilities and one vulnerability can appear in many advisories.

Severity

Each vulnerability gets one headline CVSS base score, picked in this order:

1. the score from the CNA (the organisation that assigned the CVE) — CVSS 3.1, then 3.0, then 4.0;
2. otherwise a score added by an ADP such as CISA Vulnrichment;
3. otherwise the score from ENISA EUVD or the package advisory database (GitHub, OSV), or that database's own rating.

All other scores remain visible on the vulnerability page. The score maps to the standard CVSS ratings:

Advisories carry the rating of their publisher (for example BSI's kritisch / hoch / mittel / niedrig, or Red Hat's impact). Where an advisory has no rating of its own, it shows the highest score among its CVEs ("max").

Exploitation & EPSS

A vulnerability is marked exploited when it is in CISA's Known Exploited Vulnerabilities catalogue or flagged as exploited by ENISA. Both are confirmed observations, not predictions. KEV entries also show known ransomware use and CISA's remediation deadline.

EPSS (Exploit Prediction Scoring System, by FIRST) is a daily probability that a CVE will be exploited in the next 30 days. It is a useful second signal for prioritising: a medium-severity bug with a high EPSS often deserves attention before a critical one nobody targets.

Vendors, products & tags

Vendor and product tags come from the affected-products section of each CVE record and from the product tree of CSAF advisories. Names are normalised (case, punctuation, legal suffixes such as "Inc."), so "Microsoft Corporation" and "microsoft" end up on the same vendor page. Platform and category tags (Linux, Windows, macOS, web/CMS, network devices …) are assigned by rules that match the vendor, product and description, and from advisory metadata such as BSI's affected operating systems; package and ecosystem tags come from OSV records.

Version matching

The version check and lockfile scan evaluate the affected ranges published in OSV records, following the OSV specification: a version is affected when it falls between an introduced and the next fixed (or last_affected) event, or is listed explicitly. Versions are compared with the rules of each ecosystem:

• npm, Go, crates.io, NuGet, Packagist … — Semantic Versioning, including pre-releases;
• PyPI — PEP 440 (epochs, rc, .post, .dev); package names are normalised;
• Maven and RubyGems — their own ordering of qualifiers;
• Debian / Ubuntu — dpkg (epoch:upstream-revision, ~ sorts first);
• Red Hat, SUSE, Rocky, AlmaLinux — rpmvercmp;
• Alpine — apk version rules (-r revisions, _rc, _p).

The suggested upgrade is the smallest fixed version that resolves every matching vulnerability that has a fix.

Linux distributions

Distributions fix vulnerabilities by backporting patches into their own package builds, so an upstream version number says little: OpenSSL 3.0.7 on RHEL 9 can be fully patched. That is why distribution checks need the release and the exact package version as reported by dpkg -l or rpm -q, and are matched only against that distribution's own fixed versions.

Releases are grouped the way you think of them: "RHEL 9" covers BaseOS, AppStream, CodeReady Builder and the other RHEL 9 repositories; "SLES 15 SP6" covers the server and its modules. Extended-support streams (EUS, AUS, E4S, ELS, LTSS-only products) and specialised products (SAP, HPC, Micro) are listed separately because they receive different fixes.

Limitations

• Upstream data is used as published. Wrong ranges, missing scores or late updates at the source appear here as well.
• "No known vulnerabilities" is not a guarantee. It means no matching record exists in the sources above.
• Product names are matched heuristically. Unusual vendor naming may split a product across tags or merge two similar ones.
• Lockfile scans see only exact versions. Ranges in manifests (^1.2, >=2) are skipped; use the lockfile.
• Delays. Sources are polled hourly or daily; see current status.

Found something wrong? Report it — corrections are welcome.