Vulnerability enrichment

Summary

Before ONEKEY matches a single CVE against your firmware, it collects vulnerability data from multiple sources, deduplicates and cleans it, adds applicability and threat context, and prepares Automated Impact Assessment rules. The result is stored in ONEKEY's built-in vulnerability database, refreshed several times a day, and reused for every firmware you analyze.

ONEKEY builds its vulnerability intelligence centrally, in a single built-in vulnerability database that's maintained independently of any specific firmware. This page summarizes how that database is built, before anything in it is matched against your firmware.

Collect sources

ONEKEY collects vulnerability data from multiple sources rather than relying on a single database.

Raw vulnerability sources: NIST NVD (National Vulnerability Database), OSV (Open Source Vulnerabilities), and ENISA EUVD (European Union Vulnerability Database). See Databases for how these are matched against your components.

Specialist sources are used to refine and add context to the data later:

• Linux Kernel Tracker and CIP Kernel Security Tracker — track which kernel version or commit fixed a given CVE, including backports to stable/LTS branches.
• Ubuntu CVE Tracker — links to the kernel patches that fixed a given CVE.
• Android Security Bulletins — Google's monthly publications listing which CVE was patched in which Android version and security patch level.
• CISA Known Exploited Vulnerabilities (KEV) — catalog of CVEs with confirmed exploitation in the wild.
• EPSS (Exploit Prediction Scoring System) — statistical likelihood that a vulnerability will be exploited.
• Exploit DB — public exploit availability.

You can also define your own custom CVEs. These are kept in a separate, tenant-scoped database and matched alongside the built-in one, rather than going through the steps below.

At this stage the data is still raw: the same vulnerability may appear multiple times, under different identifiers, with conflicting details across sources. Collecting is all this step does – nothing is merged, refined, or applied to a vulnerability yet.

Normalize and clean

Raw records are turned into canonical, consistent entries:

• Deduplicate vulnerabilities — the same vulnerability reported by multiple databases becomes one entry, with the other identifiers listed as aliases.
• Standardize identifiers — component identifiers are parsed out of each source's own naming scheme. CPE strings from NVD, for example, are split into Vendor, Product, and Version.
• Standardize version ranges — the affected range is rebuilt from whichever notation the source uses. OSV's introduced, fixed, and last-affected events, for example, are assembled into a single VERS spec.
• Validate and fix — malformed records are repaired, known source-specific version quirks patched, conflicting fields resolved (by keeping the more complete or more severe value), and noise or invalid entries discarded.

Without this step, the same issue could be duplicated or carry inconsistent data into later stages.

Enrich

Cleaned records are enriched with context the original vulnerability definition doesn't capture, or doesn't capture accurately. This step uses the specialist sources collected earlier.

Applicability enrichment refines which versions are actually affected:

• Linux Kernel Tracker — replaces NVD's kernel version ranges with its own, rebuilt separately for each maintained stable/LTS branch rather than taken from a single mainline cutoff. NVD may broadly list "Linux 5.15" as affected, while the tracker shows the fix was backported in 5.15.123.
• CIP Kernel Security Tracker — used for kernel CVEs the Linux Kernel Tracker doesn't cover.
• Ubuntu CVE Tracker — adds the commit that fixed the CVE to the vulnerability's References.

Note

This refines the version ranges used for CVE matching itself. It's a different mechanism from the Linux kernel Automated Impact Assessment rules, which look for evidence of the vulnerability directly inside your firmware binaries.

Threat enrichment adds prioritization context:

• CISA KEV — sets Exploit maturity to its highest level and records the Exploited since date.
• Exploit DB — raises Exploit maturity when public exploit code is available.
• EPSS — attaches its probability and percentile scores to the vulnerability.

Both applicability and threat enrichment run before any firmware evidence is considered, using only the vulnerability data collected so far. (1)

1. For more on why matching a vulnerability's published version range isn't enough on its own, see ONEKEY's post on the Linux kernel.

Prepare Automated Impact Assessment rules

A CVE match tells you a component/version could be affected – it can't, by itself, tell you whether the vulnerable code or module actually exists in a specific firmware build. To answer that, ONEKEY prepares Automated Impact Assessment rules:

• Automatically generated rules, parsed from the vulnerability's description and – for Linux kernel CVEs – the upstream fix patch. Android rules also use the vendor, chipset, platform, and package context in the description, plus the patch levels published in Android Security Bulletins.
• Manually created rules, written by ONEKEY security analysts for cases that can't be generated automatically.

These rules are prepared once per vulnerability, then executed independently for every firmware analysis. (1)

1. For a closer look at why a reported patch level alone can't confirm whether a device is affected, see ONEKEY's post on Android version matching.

Store

Cleaned and enriched vulnerability records, together with their prepared Automated Impact Assessment rules, are stored in ONEKEY's vulnerability database. This database:

• Is refreshed several times a day, so monitoring runs and new analyses always use current vulnerability intelligence.
• Contains only public vulnerability data, built the same way for every tenant. It never contains your firmware or analysis info.
• Is preloaded before analysis starts, so CVE matching itself doesn't rely on a live lookup against NVD, OSV, or any other external source while your firmware is being analyzed.

Applying it to your firmware

Everything above happens independently of any specific firmware. When you upload a firmware, ONEKEY runs it through the following analysis steps and matches it against the prepared database:

1. Extraction unpacks the firmware's filesystem, binaries, images, and configuration files.
2. Firmware enumeration analyzes the extracted files and collects binary evidence – strings, symbols, cryptographic material, and more.
3. Component detection identifies components and versions from that evidence and builds the SBOM.
4. CVE matching compares detected components against the vulnerability database.
5. Automated Impact Assessment applies the prepared rules to the binary evidence collected during enumeration, producing a score and justification for each match.

Together, these five steps turn a generic "this version could be affected" CVE match into a firmware-specific vulnerability list backed by evidence.