Most of a camera or router image comes from the chip vendor's SDK, open-source projects and contractors. When a buyer asks for an SBOM or a flaw makes the news, you need to know what is in each release and at which version. FDIE reads it from the firmware itself, not from a manifest that may be out of date.
The challenge
Chip vendors ship board support packages full of open source, often at old versions and with local patches. Few of them come with a list of what is inside.
A manifest lists what you meant to include. Prebuilt libraries, vendor binaries and copied code reach the image without ever appearing in it.
Operators, tenders and enterprise buyers ask for an SBOM with each release, and for a quick answer when a vulnerability lands. A spreadsheet kept by hand does not keep up.
How FDIE helps
FDIE unpacks Linux file systems such as SquashFS and UBIFS, vendor wrappers such as uImage and TRX, and bare-metal images for ESP32 and Cortex-M with its own readers. Components are identified in the files that ship, so the SBOM describes the image, not the intention.
Every component comes with its licence and is matched to NVD and OSV, ranked with CISA KEV and EPSS. Function use shows whether your programs call the vulnerable code, so a match is a lead to judge, not only a version string.
Connect GitHub, GitLab, Bitbucket or Azure DevOps and the dependencies from your manifests and lockfiles join the firmware's components in the same product. Exact upgrades can open as pull requests on a new branch, never merged for you.
Export the SBOM in CycloneDX 1.6 or SPDX 2.3. When a vulnerability does not affect your product, your team records a VEX statement with its reason and exports it, so the next questionnaire is answered from records, not from memory.
How it works
Upload the firmware image, import it from a GitHub or GitLab release, or let CI send each build. Connect the source if you have it.
FDIE unpacks the image, reads its programs and libraries and identifies each component with its version and licence.
Check the vulnerability matches, record VEX for the ones that do not apply and see what the analysis could not read.
Export the SBOM and VEX for a buyer, a tender or a lab, and keep them with the release they describe.
Rules by market
Buyers and tenders in every market ask for an SBOM. ER-01 testing in India reviews the bill of materials, and for products sold in the EU, the EU CRA asks manufacturers to document their components. Section 889 evidence shows components from covered vendors for your counsel.
Needed for new BIS registrations since 9 April 2025
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Component evidence for federal buyers, not a legal verdict
Voluntary consumer IoT baseline, September 2022
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
Per release, product or repository, in CycloneDX 1.6 or SPDX 2.3.
Your team's reasons a vulnerability does not apply, in CycloneDX, OpenVEX or CSAF 2.0.
The same content as a signed PDF, for people who read rather than parse.
The licence of every component, exported in CSV or JSON for your legal review.
Exact dependency upgrades on a new branch, one per package, never merged for you.
What the analysis could not read, with the reason, so an empty result is never mistaken for a clean one.
No. A firmware image on its own gives you its components and their vulnerabilities. Source code adds the dependencies from your manifests and lockfiles.
A build SBOM lists what your manifests declare. FDIE reads the image that ships, so prebuilt vendor libraries and copied code show up too. Connecting your repository adds the declared dependencies beside them.
It is listed as a coverage gap with the reason, never counted as a pass.
Your team records a VEX statement with its reason and exports it as CycloneDX, OpenVEX or CSAF 2.0.
No. Components come from FDIE's own readers and rules. Full results without AI: every finding comes from FDIE's own rules and engines. Bring your own AI key (BYOK) and your AI makes them sharper. AI explains and proposes; your team decides.
A 45-minute call with our team. Bring one firmware image.