Ubuntu USNs and OVAL Data Explained: How They Work and How to Use Them

An Ubuntu Security Notice (USN) is Canonical's announcement that fixed packages are available for one or more Ubuntu releases, listing the CVEs addressed and the exact package versions that carry the fix. OVAL is the machine readable form of that data: XML files you evaluate with OpenSCAP to learn which notices or CVEs still apply to a host.

Canonical publishes three OVAL flavours per release (USN, CVE and per package), plus the same tracker data as OSV and OpenVEX JSON, and the Ubuntu Pro client reads the same tracker through pro fix. This guide goes one level deeper than our Ubuntu Pro and ESM history and Ubuntu release lifecycle posts: what is inside a notice, how the per release CVE statuses work, what each feed contains, how to run OVAL with OpenSCAP and parse the results, how ESM fixes appear to machines that are not attached to Pro, how to match an SBOM against Ubuntu's VEX data, and why your scanner and Canonical sometimes disagree. Every field name, status and command below was checked against Canonical's own pages, the data files themselves, or the OpenSCAP and OVAL documentation listed under Sources, on 23 October 2026.

Key takeaways

• A USN is a fix announcement, not a vulnerability record. It exists only once fixed packages are published, and it lists per release binary package versions. Its ID looks like USN-8951-1; the last number counts follow up notices for the same issue (for example USN-8890-2 brought a libsoup fix to one more release).
• The Ubuntu CVE tracker is the vulnerability record. It holds a status for every source package in every release: Needs evaluation, Not affected, Vulnerable, Vulnerable (work in progress), Vulnerable (fix deferred), Fixed, Ignored or Not in release. The git tracker behind it uses short codes such as needed, released, deferred, ignored, not-affected and DNE.
• Canonical's OVAL directory publishes three files per release: usn (one patch class definition per notice), cve (one vulnerability definition per CVE, including unfixed ones) and pkg (one definition per source package with its CVEs attached). Each also has an oci. variant that checks an image manifest file instead of the live dpkg database.
• oscap oval eval --report report.html com.ubuntu.noble.usn.oval.xml is Canonical's documented starting point. In a USN OVAL, a definition that evaluates true means "this patch is missing".
• pro fix CVE-... and pro fix USN-... query the Ubuntu security JSON API, plan the upgrade, and tell you when a fix lives in an Ubuntu Pro pocket. --dry-run shows the plan without installing anything. ubuntu-security-status and pro security-status count where installed packages come from; they do not evaluate CVEs.
• ESM fixes appear in the same notices, marked "Ubuntu Pro" with versions ending in +esmN. An unattached LTS machine past standard support will keep showing those definitions as open, because the fixed version exists but cannot be installed from its sources.
• Canonical's OSV and OpenVEX feeds carry the same tracker statuses as JSON. Canonical recommends one of OVAL, OSV or VEX over scraping the web tracker, and labels its own JSON API "a work in progress" not for production automation.
• Scanner results differ from upstream CVSS because Ubuntu backports fixes without changing the upstream version, assigns its own priority, and marks some CVEs not affected or ignored per release. Matching an SBOM to Ubuntu data needs the full Debian version string and the release codename.

What is a USN, and what fields does it have?

Canonical's notices page puts it plainly: an Ubuntu Security Notice is issued "when a security issue is fixed in an official Ubuntu package". When we checked on 23 October 2026 the index listed 11,485 notices. You can follow them by mailing list (ubuntu-security-announce), Atom or RSS, or by filtering the web index by release.

A single notice page, for example USN-8951-1 for c-ares, published on 21 October 2026, carries these parts:

The same notice is available as JSON by adding .json to the URL. The JSON for USN-8951-1 has these top level keys: id, title, summary, instructions, references, published, description, is_hidden, release_packages, type, cves, cves_ids, releases and related_notices. The useful part for automation is release_packages, keyed by codename. Each entry lists the source package (with is_source: true) and its binaries, each with a version, a pocket and an is_visible flag. For c-ares on focal, the binaries sit in the esm-infra pocket; on noble they sit in security. That pocket field is the cleanest machine signal for "this fix needs Ubuntu Pro".

How does a USN map to CVEs and packages?

The mapping is many to many, and three details trip people up:

1. One notice, several CVEs, uneven reach. USN-8951-1 lists four CVEs, but its own text says CVE-2022-4904 only affected 16.04 LTS. The notice's release list is the union across all its CVEs, not a statement that every CVE hit every release.
2. One CVE, several notices. The JSON cves array shows CVE-2022-4904 in both USN-5907-1 (2 March 2023) and USN-8951-1. The tracker page for CVE-2022-4904 explains why: 18.04, 20.04 and 22.04 were fixed in 2023, and 16.04 LTS got its fix (1.10.0-3ubuntu0.2+esm4, Ubuntu Pro) in the October 2026 notice.
3. Some notices have no CVE at all. USN-8947-1 (21 October 2026) is an "NSS update" that refreshed CA certificates, with no CVE ID. USN-6663-3 in the noble OVAL file is an OpenSSL hardening update whose severity field reads None. A pipeline that drops notices without CVEs drops real updates.

Notices are also keyed to source packages while fixes install as binary packages. c-ares builds libcares2 on 24.04 and libc-ares2 on older releases; a single PHP source builds dozens of binaries. The update table always names binaries, so match on those when you compare against dpkg output.

The revision suffix matters too. USN-6663-3's description says USN-6663-1 "provided a security update for OpenSSL" and that this update "provides the corresponding update for Ubuntu 24.04 LTS". A -2 or -3 usually means the same fix arriving for another release, a regression fix, or a related package. The pro fix documentation shows the client treating these as related notices: fixing USN-5079-2 also checks USN-5079-1.

How does the Ubuntu CVE tracker show status per release?

The CVE tracker at ubuntu.com/security/cves holds one record per CVE. Each record has an Ubuntu priority, an optional CVSS score, a description, notes, and a status table: one row per source package per release. Canonical's About CVEs page defines the statuses, and its OSV documentation maps them to the shorter codes used in the git version of the tracker.

Two of these deserve care. Ignored is still vulnerable; it means Canonical has decided not to ship a fix for that release. On the CVE-2022-4904 page, 14.04 LTS (trusty) shows "Ignored, end of standard support". Deferred is also still vulnerable; Canonical's VEX mapping turns it into under_investigation, not not_affected.

The status table for CVE-2022-4904 is a good illustration of how one CVE looks across a decade of releases:

The newer releases are "Not affected" because they ship c-ares 1.18.1-2 or later, which already contains the upstream fix. The JSON form of the record (https://ubuntu.com/security/cves/CVE-2022-4904.json) has a packages array, and each package has a statuses list with release_codename, status (the git code, such as released or not-affected), description (the version or reason) and pocket (for example esm-infra-legacy for the xenial fix).

Ubuntu priority is not CVSS

Each record also carries an Ubuntu priority: Critical, High, Medium, Low or Negligible. Canonical says the priority weighs "severity, importance, risk, estimated number of affected users, software configuration, active exploitation" and Ubuntu's own hardening features, and states that these levels "are distinct from other published severity levels such as CVSS base scores". CVE-2022-4904 shows the gap: Ubuntu priority Medium, CVSS 3 base score 8.6 High. The About CVEs page also notes that Low priority issues "tend to be included in security updates only when higher priority issues require an update", and Negligible ones "typically will not receive security updates" unless the fix is easy.

What OVAL feeds does Canonical publish?

OVAL (Open Vulnerability and Assessment Language) is an XML language for describing machine state as definitions, criteria and tests. The OVAL schema defines five definition classes: compliance, inventory, miscellaneous, patch and vulnerability. A patch definition "will evaluate to true when the specified patch is missing from the system"; a vulnerability definition "will evaluate to true when the system is found to be vulnerable". Canonical's files declare OVAL schema version 5.11.1 and use the Linux dpkginfo_test, the Unix uname_test and the independent textfilecontent54_test and variable_test.

Canonical's OVAL page describes two products and the data directory at security-metadata.canonical.com/oval publishes three per release, each in a host and an oci. flavour:

The directory also carries files for Pro and special channels: fips, fips-updates, fips-preview, realtime and bluefield variants for the releases that have them (for example com.ubuntu.fips-updates_noble.usn.oval.xml.bz2). The general release files already include ESM content: the noble CVE OVAL contains criteria for esm-apps/noble alongside plain noble. Everything was regenerated at 06:06 UTC on 23 October 2026 when we looked, and the noble files carried a generator timestamp from the evening before.

How big are they, and what is inside?

For 24.04 LTS (noble) on 23 October 2026:

A USN definition is short. Here is the structure of the one for USN-6663-3, trimmed:

<definition id="oval:com.ubuntu.noble:def:666330000000" class="patch" version="1">
  <metadata>
    <title>USN-6663-3 -- OpenSSL update</title>
    <reference source="USN" ref_id="USN-6663-3"
               ref_url="https://ubuntu.com/security/notices/USN-6663-3" />
    <description>... Run `sudo pro fix USN-6663-3` ... libssl3t64 - 3.0.13-0ubuntu3.1
      openssl - 3.0.13-0ubuntu3.1 No subscription required</description>
    <advisory from="security@ubuntu.com">
      <severity>None</severity>
      <issued date="2024-05-23T09:27:17Z" />
    </advisory>
  </metadata>
  <criteria>
    <extend_definition applicability_check="true"
        definition_ref="oval:com.ubuntu.noble:def:100"
        comment="Ubuntu 24.04 LTS (noble) is installed" />
    <criterion test_ref="oval:com.ubuntu.noble:tst:666330000000"
        comment="openssl source package in noble, is affected and has been fixed
                 (note: '3.0.13-0ubuntu3.1')." />
  </criteria>
</definition>

The test it points to is a dpkginfo_test whose object lists the binary package names built from openssl and whose state is a Debian version comparison:

<linux-def:dpkginfo_state id="oval:com.ubuntu.noble:ste:666330000000" version="1"
    comment="The binary package version is less than '3.0.13-0ubuntu3.1'">
  <linux-def:evr datatype="debian_evr_string" operation="less than">3.0.13-0ubuntu3.1</linux-def:evr>
</linux-def:dpkginfo_state>

So the definition is true when the host runs noble and any listed binary is installed at a version lower than the fixed one. Definition 100 is the inventory check: it reads DISTRIB_CODENAME from /etc/lsb-release to confirm the release.

Kernel notices work differently. The noble USN file has 48 uname_test entries, which check the running kernel, combined with variable_test version comparisons. A host that installed a fixed kernel package but has not rebooted still evaluates as missing the patch, which is correct: the vulnerable kernel is the one in memory.

The CVE OVAL holds two kinds of criteria. Fixed entries carry the same "less than" version test. Unfixed entries ("might be affected and may need fixing") point at a dpkginfo_test with no state, which means "the package exists". In the noble CVE file we counted 15,170 such unfixed criteria for noble and 3,178 for esm-apps/noble, against 3,769 and 762 fixed ones. If a host has any of those packages installed, the CVE definition evaluates true whether or not a fix will ever ship. That is by design, but it means the CVE OVAL produces far longer reports than the USN OVAL.

The PKG OVAL groups CVEs by source package. Each definition carries an advisory block with one cve element per CVE, including attributes for priority, public date, cvss_score, cvss_vector, cvss_severity and the usns that fixed it. For c-ares on noble the definition lists CVE-2026-69184 (priority medium, CVSS 7.5 high) and CVE-2026-69186 (priority medium, CVSS 5.3 medium), both fixed by USN-8951-1 at 1.27.0-1.0ubuntu1.1. It is the most compact way to feed a dashboard that wants "package, fixed version, CVEs, priority" rows.

How do you run Ubuntu OVAL with OpenSCAP, step by step?

This walkthrough evaluates a live 24.04 LTS host, then an image manifest, then turns the results into rows you can feed to a report. Nothing here changes installed packages.

Step 1: install the scanner

sudo apt update
apt-cache search openscap
sudo apt install openscap-scanner
oscap --version

The oscap binary comes from the OpenSCAP project. Package names have changed between Ubuntu releases (on 26.04 LTS the binary package is openscap-scanner in universe), so use the search line to confirm the name on yours.

Step 2: fetch the USN OVAL for this release

These commands are Canonical's documented ones:

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2

lsb_release -cs prints the codename (noble, jammy, resolute). If you run a FIPS or real time kernel channel, fetch the matching variant instead, for example com.ubuntu.fips-updates_noble.usn.oval.xml.bz2.

Step 3: evaluate and keep both outputs

Canonical's page shows the HTML report. Add --results so you also keep the machine readable OVAL results file:

oscap oval eval \
  --results usn-results.xml \
  --report usn-report.html \
  com.ubuntu.$(lsb_release -cs).usn.oval.xml

The OpenSCAP manual describes oscap oval eval --results RESULTS_FILE OVAL_FILE as the basic form; it prints each definition's result to standard output while it runs. To check one notice only, pass its definition ID:

oscap oval eval --id oval:com.ubuntu.noble:def:666330000000 \
  --results one.xml com.ubuntu.noble.usn.oval.xml

Result values come from the OVAL results schema: true, false, unknown, error, not evaluated and not applicable. For a patch class definition, true means the patch is missing. A true result on the inventory definition 100 just confirms the release.

Step 4: make the results smaller if you store them

Full results include every collected system characteristic. The OpenSCAP manual documents an OVAL directives file that switches to "thin" results, and --without-syschar to omit system characteristics:

oscap oval eval --directives directives.xml --without-syschar \
  --results usn-results.xml com.ubuntu.noble.usn.oval.xml

Copy the directives template from the OpenSCAP manual and set its schema_version to match your input file (Canonical's files declare 5.11.1).

Step 5: turn results into report rows

The results file references definitions by ID. This short script joins results to titles and prints the missing notices as tab separated rows. It only reads the two XML files.

#!/usr/bin/env python3
# usage: python3 -I missing_usns.py com.ubuntu.noble.usn.oval.xml usn-results.xml
import sys
import xml.etree.ElementTree as ET

DEF = "{http://oval.mitre.org/XMLSchema/oval-definitions-5}"
RES = "{http://oval.mitre.org/XMLSchema/oval-results-5}"

defs_file, results_file = sys.argv[1], sys.argv[2]

titles = {}
for d in ET.parse(defs_file).getroot().iter(DEF + "definition"):
    if d.get("class") != "patch":
        continue
    titles[d.get("id")] = d.findtext(DEF + "metadata/" + DEF + "title")

for r in ET.parse(results_file).getroot().iter(RES + "definition"):
    def_id = r.get("definition_id")
    if r.get("result") == "true" and def_id in titles:
        print(f"{def_id}\t{titles[def_id]}")

Each output line looks like oval:com.ubuntu.noble:def:... followed by a title such as USN-6663-3 -- OpenSSL update. Pipe it into whatever feeds your patch dashboard, keyed by host name and scan date.

Step 6: scan an image or rootfs without logging into it

The oci. files check a manifest instead of the dpkg database. In the noble file every one of its 2,154 tests is a textfilecontent54_test reading a file named manifest in the current directory. Canonical documents this flow for its official cloud images:

wget https://security-metadata.canonical.com/oval/oci.com.ubuntu.noble.usn.oval.xml.bz2
bunzip2 oci.com.ubuntu.noble.usn.oval.xml.bz2
wget -O manifest https://cloud-images.ubuntu.com/releases/noble/release/ubuntu-24.04-server-cloudimg-amd64-root.manifest
oscap oval eval --report report.html oci.com.ubuntu.noble.usn.oval.xml

Canonical's own example uses focal; the noble manifest path above follows the same pattern, so confirm the URL resolves before you script it. For your own images, you can produce a manifest in the same "package, tab, version" layout from inside the image with dpkg-query -W -f='${Package}\t${Version}\n' > manifest, then run the evaluation in that directory.

Step 7: schedule it

Canonical regenerates the files continuously, so a nightly fetch is reasonable. Compare the oval:timestamp in the file's generator block between runs; if it has not moved, there is nothing new to evaluate.

How do ubuntu-security-status and pro fix use this data?

They solve different problems and read different sources.

pro fix: per CVE or per notice, with a plan

The Ubuntu Pro client's pro fix takes a CVE or USN ID, works out which installed packages are affected, and upgrades them. The client's source code points its security_url at https://ubuntu.com/security and requests cves/{cve}.json and notices/{notice}.json: the same JSON records described above. The documented output always follows the same shape: it describes the issue, lists affected installed packages, says where each fix lives ("A fix is available in Ubuntu standard updates" or "A fix is available in Ubuntu Pro: ESM Infra"), prints the exact apt command, and ends with a verdict.

sudo apt update && sudo apt install ubuntu-pro-client
pro fix --dry-run CVE-2022-4904
sudo pro fix CVE-2022-4904

The Pro client documentation shows four kinds of outcome:

--dry-run prints the same plan with "No packages will be installed", including the pro attach and pro enable esm-infra steps it would prompt for. When you fix a USN, the client also looks for related notices (USN-5079-2 pulls in USN-5079-1) and prints a summary; the documentation has a separate guide for skipping related notices. Behind the CLI there are API endpoints, such as u.pro.security.fix.cve.plan.v1, for tools that want the plan as JSON.

Note that pro fix is reactive: it answers "am I affected by this one ID?", not "what am I missing?". For the second question you need OVAL, OSV or VEX.

pro security-status and ubuntu-security-status: coverage, not CVEs

pro security-status summarises where installed packages come from and what security coverage applies. Its documented output counts packages from Main/Restricted, Universe/Multiverse, third parties and "no longer available for download", says whether the machine still receives standard LTS patches, and whether esm-infra and esm-apps are enabled. On an unattached 16.04 example, the documentation shows "There are 170 pending security updates" for esm-infra. Flags such as --esm-infra, --esm-apps, --thirdparty and --unavailable list the packages in each set. For automation, the documented API endpoints include u.pro.packages.summary.v1 and u.pro.packages.updates.v1.

ubuntu-security-status is the older tool from the update-manager package. Reading its source shows how it works: it walks the apt cache, classifies each package by origin, and downloads the Packages index of the ESM security pockets from esm.ubuntu.com to count how many installed packages have an ESM update. It supports --thirdparty and --unavailable. It never reads OVAL, the CVE tracker or notices, so it cannot tell you which CVEs are open. Use it, or pro security-status, to find packages with no security coverage at all (third party, PPAs, leftovers from older releases), which is exactly the blind spot of every Ubuntu feed.

How do ESM packages appear in notices, and what does that mean for unattached machines?

Ubuntu Pro's Expanded Security Maintenance (ESM) delivers fixes through separate archive pockets. Canonical's ESM documentation says the Infra pockets cover Main and the Apps pockets cover Universe, both served from esm.ubuntu.com. For noble the client writes DEB822 sources with suites noble-infra-security noble-infra-updates and noble-apps-security noble-apps-updates, signed by keyrings under /usr/share/keyrings/. The client pins ESM packages at priority 510, slightly above the default 500, so that a standard pocket update with a higher version number cannot roll back an ESM fix.

According to the same page, ESM updates are announced "via standard Ubuntu Security Notices", and notices and CVE data "clearly mark updates available only through Ubuntu Pro". In practice you can spot an ESM fix four ways:

What this means for an unattached machine depends on where it is in its lifecycle. Canonical's About CVEs page says the first five years of an LTS bring standard security updates for Main, with Universe covered on a best effort basis by the community and Debian; ESM extends coverage to ten years for Main and Universe, and the Legacy add on adds five more. So:

• A 24.04 LTS machine inside standard support still gets Main fixes from the security pocket. Universe packages may have fixes only in esm-apps. The noble CVE OVAL already carries 762 fixed and 3,178 unfixed esm-apps/noble criteria.
• A 20.04 LTS or older machine past standard support gets new Main fixes only from esm-infra. USN-8951-1 is a clean example: the focal, bionic and xenial fixes exist only as +esm versions.

In both cases the fixed version is real and published, so the OVAL "less than" test is true, pro fix reports a fix "in Ubuntu Pro", and a VEX or OSV match shows the package version as affected. Nothing is wrong with the data. The machine simply cannot install the fix from its configured sources. Report these separately ("fix exists, needs Pro") from "no fix exists", because the remedies are different: attach and enable the service, upgrade the release, or accept and record the risk. Canonical says Ubuntu Pro is free for personal use on up to five machines; check current terms before planning around it for a fleet.

How do Ubuntu's OSV and VEX publications compare with OVAL?

Canonical publishes the same tracker data in two JSON formats, documented on its security documentation site, and its public ubuntu-security-notices repository holds osv, vex, usn and lsn directories under a CC BY-SA 4.0 licence. The repository README warns that the raw USN/LSN JSON "can be changed at any time" and is not advised for consumption.

OSV

The OSV documentation lists three record types, each identified by its id prefix: UBUNTU-CVE-... for CVE records (the CVE- prefix is reserved for data synced from the CVE Program), USN-... for notices, and LSN-... for Livepatch notices. Key fields:

• upstream: the CVE ID for a CVE record; the list of UBUNTU-CVE records fixed for a USN or LSN.
• severity: an Ubuntu entry with a lowercase priority (critical to negligible) and CVSS entries. Severity is only on CVE records, so Canonical recommends evaluating notices "in conjunction with the corresponding Ubuntu CVE records".
• affected[].package: an ecosystem such as Ubuntu:24.04:LTS, Ubuntu:25.04 or Ubuntu:Pro:16.04:LTS, the source package name, and a purl like pkg:deb/ubuntu/php8.3@8.3.6-0ubuntu0.24.04.5?arch=source&distro=noble.
• ranges with introduced and fixed events, an explicit versions list, and ecosystem_specific holding the binaries and an availability string ("No subscription required", "Available with Ubuntu Pro", or "Livepatch subscription required").

Status mapping: Not in release and Not affected are left out of affected entirely; Fixed is listed with fixed set; everything else (needs triage, needed, ignored, pending, deferred, in progress) is listed without fixed. OSV data comes as a tarball (osv-all.tar.xz) on the security metadata site, as individual files in the repository, and through the central OSV database API.

OpenVEX

Canonical's VEX feed follows the OpenVEX specification (context https://openvex.dev/ns/v0.2.0) and is published as vex-all.tar.xz and as one JSON file per CVE under vex/cve/<year>/. Each statement names a vulnerability, a list of product purls (for example pkg:deb/ubuntu/unbound@1.19.2-1ubuntu3.5?arch=amd64) and a status. Canonical's mapping:

USN VEX documents only contain fixed statements. OpenVEX has no severity field, so Canonical encodes the Ubuntu priority in status_notes in a parsable way.

Choosing between them

Canonical's OSV page closes with a recommendation worth following: use OSV, OVAL or VEX "instead of trying to consume the information directly from the Web tracker or git tracker, as those tend to change and can even be replaced over time". Its About CVEs page says the same about the JSON API, which "is still a work in progress and subject to change", and asks that it not be used "in production environments or automations". (pro fix uses it because Canonical maintains both ends.)

How do you wire USN data into patch reporting and SBOM based matching?

There are two common pipelines. Use the first for hosts you can log into and the second for images and artifacts you build.

Pipeline A: fleet patch reporting from OVAL

1. Know each host's release and channel. Record lsb_release -cs, whether it is attached to Pro (pro api u.pro.status.is_attached.v1), and which services are enabled (pro api u.pro.status.enabled_services.v1).
2. Fetch once, distribute locally. Download the USN OVAL for each release you run to an internal mirror nightly, so hosts do not each pull 1 to 2 MB from Canonical.
3. Evaluate on each host with oscap oval eval --results, as in the walkthrough.
4. Parse results to rows of host, release, USN ID, title, scan time.
5. Enrich from the notice JSON. For each open USN, the release_packages entry for that codename tells you the fixed binary versions and whether their pocket is security or esm-*.
6. Report three buckets: missing standard fixes (patch now), missing Pro only fixes (attach or upgrade), and kernel fixes installed but not yet running (schedule the reboot).
7. Track time to patch from the notice published timestamp to the first scan where the definition turns false.

For CVE level reporting (auditors often ask per CVE), evaluate the CVE OVAL or PKG OVAL instead, but filter on priority. The noble CVE OVAL will flag many Low and Negligible issues with no fix planned.

Pipeline B: SBOM matching for images and builds

Canonical's guide "Using an SBOM with Ubuntu VEX data" lays out the method, and its reasoning is worth quoting in substance: generic databases report at the upstream component level, while Ubuntu backports fixes with +ubuntuX.Y version suffixes that generic databases may not recognise, and marks some upstream vulnerabilities not affected for the Ubuntu build.

1. Generate an SBOM that keeps Debian identity. You need purls of the form pkg:deb/ubuntu/<name>@<version>?arch=<arch>&distro=<codename> with the full version string, revision included.

2. Extract Ubuntu purls. For CycloneDX JSON, Canonical's example is:

   jq -r '.. | objects | .purl? | select(. and startswith("pkg:deb/ubuntu/"))' sbom.cdx.json
   

   For SPDX JSON, read externalRefs where referenceType is purl. If the SBOM lacks purls, rebuild them from name, version, the dpkg:architecture property and the operating system component that carries the codename.

3. Get the VEX data.

   wget https://security-metadata.canonical.com/vex/vex-all.tar.xz
   mkdir -p ubuntu-vex && tar -xf vex-all.tar.xz -C ubuntu-vex
   

4. Match. For each purl, find VEX statements whose product @id matches, comparing with qualifiers stripped unless you filter by architecture, and an exact version. Keep affected and under_investigation. Canonical's guide recommends the packageurl-python library for spec compliant parsing rather than string splitting.

5. Replay history when auditing an old SBOM. Check out the ubuntu-security-notices repository at the commit current when the SBOM was made (git log --oneline --before="2024-11-01T00:00:00Z" -1), then match against vex/cve/. Matching an old SBOM against today's data can both add and remove findings.

6. Attach the result to the artifact. Store the matched list, the VEX data timestamp, and the SBOM digest together, so a later reviewer can see what was known when you shipped.

Remember the scope Canonical states: this covers .deb packages from the Ubuntu archive (apt installs, Ubuntu based containers, snaps that bundle archive debs, software built from Ubuntu sources). Third party repositories and anything compiled from source "will not have matching entries".

A worked example: one CVE across three releases

Take the c-ares CVEs from USN-8951-1 and three hypothetical, unattached hosts. The fixed versions come from the notice and the CVE-2022-4904 tracker page; the installed versions are illustrative.

The noble line is true for USN-8951-1 because of the two 2026 CVEs, not because of CVE-2022-4904. The focal line shows a notice open for newer CVEs while the old one is closed. The xenial line is the classic unattached case. A CVE only report and a USN only report would each tell a partial story; joining them on the notice's cves_ids gives the full picture.

Why do scanner results on Ubuntu differ from upstream CVE severity?

Teams usually notice this when a container scan flags a "High" CVE that Canonical rates Medium, or flags a CVE that pro fix says does not affect the host. The reasons are well documented by Canonical, and most are not bugs.

1. Backported fixes keep the upstream version. Ubuntu patches 1.27.0 rather than moving to a newer upstream release, then marks it 1.27.0-1.0ubuntu1.1. A matcher that compares only the upstream part against an upstream "fixed in" range will keep reporting it as vulnerable.
2. Different severity scales. Ubuntu priority considers default configuration, exposure, exploitation and Ubuntu's hardening. CVE-2022-4904 is Medium in Ubuntu and 8.6 High in CVSS 3. Neither is wrong; they answer different questions, and Canonical notes that "CVSS is not a measure of risk".
3. Not affected per release. Newer releases often ship an upstream version that already includes the fix, so they are Not affected while older ones are Fixed. A tool that ignores the release codename cannot tell these apart.
4. Ignored and deferred. Some CVEs will never get a fix in a given release. A scanner that shows them as "fix available upstream" invites a patch that does not exist for your release.
5. Pro only fixes. A fixed version that only exists in an ESM pocket counts as "fixed" in the data but is not installable on an unattached machine.
6. Source versus binary names. Notices and tracker rows use source names (c-ares), while hosts install binaries (libcares2). A matcher that mixes them misses or double counts.
7. Running versus installed kernel. OVAL checks the running kernel. A package based scanner sees the installed one.
8. Data timing. Canonical's VEX guide notes that an Ubuntu fix may not yet have propagated to third party databases, which can produce false positives, and the reverse can happen when a new CVE reaches a generic database before Canonical triages it (it then shows as Needs evaluation).
9. Packages outside the archive. PPAs, vendor repositories, language packages installed with pip or npm, and binaries copied into images are invisible to every Ubuntu feed. Those need their own ecosystem data.

When two tools disagree, check the Ubuntu CVE page for the exact release and package first; it usually explains the gap in its status or notes.

Common mistakes

• Treating a USN as a vulnerability feed. Notices only exist for fixes. Open CVEs with no fix appear in the CVE tracker and CVE OVAL, never in a USN.
• Reading "true" as "safe". In a patch or vulnerability OVAL definition, true means the problem is present.
• Evaluating the wrong release file. A jammy OVAL evaluated on a noble host fails its inventory check and reports nothing useful. Use lsb_release -cs or the channel specific variant.
• Ignoring kernel reboots. A kernel USN stays true until the fixed kernel is running.
• Dropping notices with no CVE. CA certificate refreshes and hardening updates are still updates you want.
• Shortening version strings. 1.15.0 is not 1.15.0-1ubuntu0.5+esm1. VEX matching needs the exact Debian version.
• Treating ignored or deferred as not affected. Canonical maps them to affected and under_investigation.
• Building automation on the web tracker or the JSON API. Canonical says both may change; use OVAL, OSV or VEX.
• Cherry picking single packages to "fix" a CVE. Canonical recommends against it; a full apt upgrade or pro fix keeps dependent binaries in step.
• Assuming one feed covers the whole image. Debian packages are one layer. Application dependencies need their own scan.

FAQ

What does USN stand for in Ubuntu?

Ubuntu Security Notice. It is Canonical's announcement that fixed packages for a security issue are available, with the affected releases, the CVEs addressed and the fixed package versions.

What is the difference between a USN and a CVE?

A CVE identifies a vulnerability across all software. A USN announces Ubuntu packages that fix one or more CVEs, or sometimes a security relevant update without a CVE. One CVE can appear in several USNs (for different releases or dates), and one USN can cover several CVEs.

Where do I download Ubuntu OVAL files?

From security-metadata.canonical.com/oval. Files are named com.ubuntu.<codename>.<usn|cve|pkg>.oval.xml.bz2, with oci. variants for image manifests and channel variants such as fips-updates_noble.

Should I use the USN OVAL or the CVE OVAL?

Use the USN OVAL to find missing patches, because every true result has a fix you can install. Use the CVE OVAL (or PKG OVAL) when you need per CVE evidence, including CVEs with no fix yet, and filter by Ubuntu priority.

How do I check if my Ubuntu system is affected by a specific CVE?

Run pro fix --dry-run CVE-YYYY-NNNNN. It reports whether any installed package is affected, where the fix lives, and what it would install, without changing the system. The CVE page on ubuntu.com shows the per release status.

Does pro fix need an Ubuntu Pro subscription?

No. It works on any supported Ubuntu machine and installs fixes from the standard pockets. When a fix exists only in an ESM pocket, it tells you and prompts you to attach a Pro token or cancel.

What is the difference between ubuntu-security-status and pro security-status?

Both summarise where installed packages come from and their security coverage. ubuntu-security-status is the older update-manager script; pro security-status is part of the Pro client and has API endpoints for machine readable output. Neither evaluates CVEs.

Why does my scanner say a package is vulnerable when Ubuntu says it is fixed?

Usually because Ubuntu backported the fix without changing the upstream version, and the scanner compared upstream versions. Check the full Debian version against the fixed version on the Ubuntu CVE page.

Can I use Ubuntu OVAL to scan a Docker image?

Yes, with the oci. variants. They read a file named manifest listing packages and versions. Generate one from the image with dpkg-query -W -f='${Package}\t${Version}\n', or use the published manifest for official cloud images, then run oscap oval eval in that directory.

Is the Ubuntu security JSON API safe to automate against?

Canonical says it is "still a work in progress and subject to change" and asks that it not be used in production automation. Prefer the OVAL, OSV or VEX feeds, which Canonical documents as stable formats.

Where Safeguard fits, honestly

Canonical's feeds are the authority on Ubuntu packages, and nothing here replaces them: Safeguard does not evaluate OVAL, manage Pro subscriptions or patch hosts. The overlap is in the layers around the OS. An Ubuntu based container image carries Debian packages and, on top of them, the application dependencies and language runtimes your team adds, which no Ubuntu feed covers. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output), matches components against vulnerability databases, and shows which of your projects contain a given component and version. When an OS package finding and Canonical's data disagree, treat Canonical's per release status as the deciding source for that package.

Patch reporting on Ubuntu only covers the packages Canonical ships, yet every image built on Ubuntu also pulls application dependencies again on each rebuild. Keeping those dependencies on fixed versions is the other half of the same report, and it is where the following applies.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show Safeguard working on the code and images you build. They do not run OpenSCAP or pro fix; for Ubuntu packages, those stay the right tools.

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same ask before every command flow fits the repository that builds your Ubuntu based service image, where the application dependencies live.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine: you approve it with its device code, then scan from the terminal. That suits a build host where you already assemble Ubuntu images and generate SBOMs, so the scan runs next to the files instead of shipping them elsewhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If you already ask Claude to explain a USN or a CVE page, this is how to let it also ask Safeguard which of your projects carry a given component version, using only the tools you approve.

Click through it at your own pace, or open it full screen.

You can download Safeguard or read the CLI documentation to try it on your own build. For the Debian side of the same workflow, see how to check a CVE in the Debian security tracker.

Quick check

Sources

• Canonical: Ubuntu Security Notices index
• Canonical: USN-8951-1, c-ares vulnerabilities (page and JSON)
• Canonical: CVE-2022-4904 tracker page and JSON record
• Canonical: About CVEs (statuses, priorities, repositories, data export)
• Canonical: Ubuntu OVAL data
• Canonical security metadata: OVAL file directory
• Ubuntu security documentation: Ubuntu OVAL data
• Ubuntu security documentation: Ubuntu OSV data
• Ubuntu security documentation: Ubuntu VEX data
• Ubuntu security documentation: Using an SBOM with Ubuntu VEX data
• Ubuntu security documentation: Expanded Security Maintenance
• Canonical: ubuntu-security-notices repository (OSV, VEX, USN, LSN data)
• Ubuntu Pro Client docs: How to resolve a specific CVE or USN
• Ubuntu Pro Client docs: Common scenarios when using pro fix
• Ubuntu Pro Client docs: How to preview the result of pro fix
• Ubuntu Pro Client docs: How to check if a system is affected by a CVE/USN
• Ubuntu Pro Client docs: What does security-status do?
• Ubuntu Pro Client source: defaults (security URL)
• Ubuntu Pro Client source: fix API common module (CVE and notice endpoints)
• update-manager source: ubuntu-security-status
• OpenSCAP User Manual: evaluating standalone OVAL definitions
• OVAL Community: OVAL language documentation and releases
• OVAL 5.11.2 common schema: definition classes
• OVAL 5.11.2 results schema: result values and directives
• OpenVEX specification
• OSV schema
• Canonical: Ubuntu release cycle

Last reviewed: 24 October 2026. Canonical regenerates these feeds continuously and its client and data formats evolve; check the linked documentation for your release before automating against it.