AI-assisted SBOM and vulnerability triage for device firmware

To build an SBOM without source code, unpack the image with an extraction tool and run an SBOM generator over the extracted file systems. Open tools cover both steps, and the result should be written in CycloneDX or SPDX so other tools can read it.

Unpacking. A firmware image is a stack of containers: a vendor header, a compressed kernel, one or more file systems, sometimes encrypted blobs. unblob, maintained by ONEKEY on GitHub, parses "78+ archive, compression, and file-system formats", including SquashFS, JFFS2 and UBI/UBIFS, extracts them recursively, and carves out chunks it cannot identify. Binwalk-style tools do similar work. Encrypted or signed-and-compressed images may need the vendor's key or a device dump first.

Cataloguing. Syft, maintained by Anchore on GitHub, generates SBOMs from file systems and archives, supports package ecosystems such as Alpine (apk), Debian (dpkg) and RPM, and writes CycloneDX, SPDX and its own Syft JSON. On an embedded Linux root file system it finds what the package database records. It sees less in statically linked binaries, vendor SDK blobs and RTOS images, which carry no package metadata; those need binary identification or the build system's own manifest. When you control the build, generating the SBOM inside Yocto or Buildroot is more complete: see SBOMs from embedded Linux build systems.

Sources: CycloneDX specification overview, SPDX specifications page.

Before matching, open the SBOM and look at it: missing versions, generic names and duplicate entries all become false positives or missed CVEs later. The free SBOM viewer opens a CycloneDX or SPDX JSON file in your browser and lists every component with its version. For the wider method, including what to do when no tool identifies a component, read the firmware SBOM guide.

CVE matching produces false positives on firmware because it compares names and version strings, and firmware breaks both. A component can be named differently in the SBOM and in the vulnerability database, carry a fix that its version string does not show, or have the vulnerable feature compiled out.

Naming. NVD records which products a CVE affects with CPE names, and the CPE vendor and product often differ from the package name in the image. An OpenWrt package called dropbear is filed in NVD under the vendor dropbear_ssh_project; a shared library package such as libmbedtls12 belongs to Arm's mbed_tls. A matcher that guesses the vendor from the package name either misses those CVEs or hits an unrelated product. Package URLs (purl) identify packages more precisely, but most NVD applicability data is still expressed as CPE; see purl for SBOMs.

Backported fixes. Red Hat describes backporting as "taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version of the package we distribute." The version string stays old, so a scanner keeps reporting the CVE. Debian's security FAQ answers this exact complaint: "Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release." Vendor SDKs can do the same, and their changelogs are not always public.

Configuration and reachability. Many embedded packages are built with features switched off. A CVE in a BusyBox applet that is not compiled into the binary, or in a TLS cipher suite the build excludes, matches by version but cannot be exploited.

Every row ends with a fact an engineer can check. That fact is also what a VEX justification needs later.

Put CVEs in the CISA Known Exploited Vulnerabilities catalog first, then order the rest by the FIRST EPSS score, and use CVSS to break ties on impact. KEV records exploitation that has happened; EPSS estimates how likely it is to happen soon.

The KEV catalog data on GitHub listed 1,779 CVEs in catalog version 2026.11.10, released 10 November 2026, and 361 of those entries carry the value "Known" for use in ransomware campaigns. EPSS, published by FIRST, is a model that "estimates the probability that a published CVE will be exploited in the wild in the next 30 days" and publishes a score every day for every CVE. The EPSS data page shows that model version 5 has been published since 15 June 2026, so record the model version with each score you keep.

The two signals do not compete. FIRST's guidance on using EPSS puts it directly: "CISA KEV and EPSS answer different questions." A low EPSS score on a KEV entry does not lower its priority. The same guidance says that a vulnerability that is "not present, not reachable" or of low consequence is less urgent "regardless of the EPSS score itself", which is why false-positive removal comes before ranking.

Thresholds, worked examples and the CVSS side are covered in KEV and EPSS vulnerability prioritisation.

VEX is a machine-readable statement, made by the supplier, that says whether a product is affected by a vulnerability and why. The OASIS CSAF 2.0 standard defines a VEX profile whose "main purpose" is "to state that and why a certain product is, or is not, affected by a vulnerability."

A "not affected" status needs one of five justification labels. CSAF 2.0 defines them as follows:

These map closely onto the false-positive table above: a wrong CPE usually ends as component_not_present, a feature compiled out as vulnerable_code_not_present, and a backported fix as status "fixed" for that firmware version rather than "not affected". CycloneDX supports VEX as well, inside the SBOM or as a separate document. For format choice, product trees and publishing, see CSAF VEX for device makers and CycloneDX VEX.

AI helps where the work is reading and writing: explaining findings, grouping them, and drafting text from evidence. It must not decide whether a product is affected, change a score, or state anything that no record supports.

A firmware scan can return hundreds of matches across dozens of components. A language model is good at turning that list into something a product owner can read: one paragraph per component, the CVEs grouped under it, each sentence pointing at the record it came from. It can also draft a VEX justification once an engineer has found the evidence, for example "the CONFIG option that builds this driver is disabled in the shipped kernel configuration", and suggest which of the five CSAF labels fits.

The limits follow from who carries the liability. A VEX "not affected" statement is the manufacturer's claim about its own product, and under the CRA the manufacturer answers for shipping known exploitable vulnerabilities. A model that has not read the build configuration cannot know whether code is compiled in, and a fluent sentence without a source is the most dangerous output in a security report.

A practical test for any AI-assisted tool: delete the citation behind one sentence of its report and see whether the report still passes. If it does, the tool lets unsourced claims through.

SoftWSP automates unpacking, the SBOM, matching and scoring, and uses AI only to write the cited report; the triage decisions stay with your engineers. The device firmware security service runs these steps:

• SBOM: the firmware is unpacked with unblob and catalogued with Syft, and the output is normalised into a CycloneDX 1.6 SBOM. A mapping table corrects embedded package names whose NVD vendor differs, such as dropbear and dnsmasq.
• Matching: components are matched against NVD by CPE, and the observed version is checked against each CVE's affected range. The results are checked against the CISA KEV catalog, FIRST EPSS scores and CISA's CSAF advisories for industrial control systems.
• Scoring: a fixed ruleset ranks every component: any KEV entry first, then EPSS, then CVSS, with a small, bounded adjustment for network exposure. The model has no say in the order.
• Report: AI drafts one section per component, highest risk first. Every claim sentence must cite a matched record; a draft with an uncited sentence is rejected rather than saved. An engineer reviews the report before you receive it.

What it leaves to you, by design: SoftWSP does not detect backported fixes, does not decide that a CVE does not affect your product, and writes no VEX statements. Those calls need your build configuration and your vendor's patch history.

One pass per release candidate, with the evidence kept next to the SBOM. A workable routine:

1. Generate the SBOM from the release image, not from an earlier build, and store it with the image hash. Compare it with the previous release: see firmware SBOM diff between releases.
2. Review components without a version or identifier before matching.
3. Match against current CVE, KEV and EPSS data, and record the date and EPSS model version used.
4. Work through false positives with the cause table above, and keep the evidence for each closed item.
5. Fix or mitigate KEV entries before release; schedule the rest by EPSS and impact.
6. Write VEX statements for every "not affected" and "fixed" decision, approved by a named engineer.
7. Repeat the matching after release, because KEV and EPSS change daily while the SBOM stays the same.