Understanding vulnerability matching

PatchBase doesn't just list advisories — it tells you which advisories actually affect your hosts. Here's how the matching process works and how to interpret the results.

How matching works

When a host sends a snapshot (via agent, SSH pull, or manual upload), the server:

1. Resolves the advisory scope key — determines which advisory database applies to this host based on OS family, name, version, and architecture.
2. Registers scope demand — marks that scope as needed, triggering an advisory database sync if it hasn't been downloaded yet.
3. Runs the matcher — compares every installed package against the advisory database's affected package rules and fixed packages.

The matcher uses two comparison strategies depending on the package family:

• RPM systems — uses RPM epoch-version-release (EVR) comparison rules, matching against affected_package_rules and fixed_packages from the advisory database.
• APT systems — uses Debian version comparison rules to compare installed versions against affected version ranges.

What gets matched

For each advisory, the advisory database contains:

• Affected package rules — conditions that determine if a package version is vulnerable (e.g., "package openssl with version < 3.0.10-1 is affected")
• Fixed packages — the specific package versions that resolve the advisory
• Product streams — the distribution channel (e.g., "Rocky Linux 10.2 BaseOS x86_64") the advisory applies to

The matcher checks each installed package against these rules and records a match if the installed version falls within an affected range.

Interpreting results

On the host detail page, you'll see:

• Vulnerable packages — packages with installed versions that match an advisory's affected rules, along with the advisory ID, severity, and available fix version
• Upgradable packages — packages where a newer version exists in enabled repositories, even if no advisory is attached
• Kernel posture — whether the running kernel is older than the latest installed kernel (meaning a reboot is needed to apply a kernel update)
• Overall action — the recommended next step: none, update_package, or reboot

Severity levels

Advisories are categorized by severity as defined by the upstream distribution:

Severity	Meaning
Critical	Remote code execution or similarly severe vulnerabilities
Important	Significant vulnerability with real exploitation risk
Moderate	Vulnerability that may be exploitable in specific configurations
Low	Minimal practical impact

No-fix advisories

Some advisories have no fixed package available yet. These appear as "no fix" in the host state. PatchBase tracks them so you're aware, but there's nothing to update to until the distribution publishes a fix.

Unknown status

If the matcher can't determine whether a package is affected (for example, the advisory database doesn't have rules for a specific package version), the host's state for that advisory is marked as "unknown." This is worth investigating manually.

Re-matching after advisory sync

When the advisory database for a scope is updated (new advisories published upstream), PatchBase automatically re-matches all hosts in that scope. You don't need to wait for the next host snapshot — the matching runs against existing snapshot data with the fresh advisory records.