Firmware SBOM and CVE checks without source code: the approaches

How do the four approaches differ?

What does source code analysis give you?

What it reads

The project folder, the bundled libraries and, where they exist, package managers and build scripts.

Strong for

Your own development with full access. Dependencies are visible before a build exists, and a vulnerability can be fixed at the source.

Where it ends

The project folder also holds code the linker never puts into the image. CISA names exactly this as the limit of this SBOM type. In a public Keil project vTaskEndScheduler is in tasks.c and missing from the AXF. C projects without a package manager also lack the file a tool would otherwise read the list from.

What you need

The source code, your suppliers' included.

Build-time variant

The SBOM comes from the build itself. According to CISA this increases confidence that it describes the built artifact correctly. It may mean changing the build process.

What does analysing the shipped binary give you?

What it reads

The image as you ship it. For embedded Linux the file system with its package data and programs, for microcontrollers the ELF or AXF from Keil, IAR or GCC, the BIN if nothing else exists.

Strong for

Bought-in firmware, old releases and anything without a development environment. CISA names legacy firmware artifacts as an example. No access to the build is needed, and the result can verify SBOMs from other sources. It counts what is in the device.

Where it ends

If the analysis does not recognise a component, it is missing from the list; CISA names omissions as a limit of this type. A version is not always in the binary. In the Keil and the GCC example the FreeRTOS version sat only in the debug information and the BIN did not carry it. The Ambiq HAL in the Keil example and TouchGFX in the GCC example came as prebuilt archives: function names in the binary, no version. An honest result leaves that version blank. Encrypted images cannot be read without the key; the manufacturer can have the unencrypted build output checked.

What you need

The file. The more debug information it carries, the more versions are evidenced: the ELF or AXF gives more than the BIN.

What is a supplier SBOM worth?

What it reads

A CycloneDX or SPDX file your supplier ships with a module, stack or operating system. Germany's BSI guideline TR-03183-2 names both formats.

Strong for

Parts you never see as source. The supplier knows the product best, and the file drops straight into your own bill of materials.

Where it ends

The SBOM is the supplier's statement about one release. Whether it matches the firmware you ship shows only when it is compared with the binary. Missing versions or identifiers make a component hard to connect to vulnerability data.

What you need

The supplier's file, matching the version you build in.

When is a review by hand worth it?

What it reads

Map file, linker output, release notes, licence files, purchasing BOMs.

Strong for

Single questions where a person has to know the context, such as whether a function is reachable on this device at all.

Where it ends

The effort comes back with every firmware release.

What you need

Time and someone who knows the build.

Which approach fits which situation?

The approaches do not exclude each other. One SBOM may combine data from several of them.

How does an SBOM become a CVE check?

Known vulnerabilities attach to a component and a version. The check is only as good as those two values, whichever approach produced them. Without a version nobody can say whether a vulnerability applies; the field stays blank and is marked as an open question.

One database no longer covers this. Since 15 April 2026 the NVD adds severity and affected products first for selected CVEs, such as those in CISA's KEV catalog. Backlogged CVEs published before 1 March 2026 are set to “Not Scheduled”. Vendor advisories and the records of the CVE numbering authorities close part of that gap.

What does the EU Cyber Resilience Act require?

Annex I Part II point 1 requires manufacturers to identify and document the components of their product, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. The CRA does not prescribe which approach gets you there. The obligation applies from 11 December 2027 (Art. 71(2)).

Where does LegacyMind fit?

LegacyMind works with the second and the third approach: it reads the shipped image, Linux and microcontroller alike (ELF, AXF and OUT from Keil, IAR or GCC, plus BIN and HEX), and supplier SBOMs in CycloneDX or SPDX. A version the binary does not evidence stays blank. After the scan, LegacyMind keeps matching newly published CVEs to the same firmware.