Firmware security
Firmware vulnerability scanner for Linux-based images
A firmware vulnerability scanner unpacks a firmware image, identifies the software components inside it and checks them against known vulnerabilities. KROMSE does this today for Linux-based firmware images up to 512 MB and tells you plainly what it could not see.
Free plan, no card required.
Why firmware needs its own scan
Firmware is where source-code scanning stops. A device image contains the vendor's code, but also a Linux kernel, a C library, a busybox, an SSL library and dozens of packages pulled in by a board support package or a build system such as Yocto or Buildroot. Many of them never appear in a repository the product team owns.
The image is also what customers actually run. Scanning it answers the question that matters for the Cyber Resilience Act: which components, in which versions, are in the product that was placed on the market.
How firmware analysis works
A scan has three steps: extract, identify, match. Each one can fail quietly, so a good scanner reports what it could not do as clearly as what it found.
- Extract: unpack the image recursively, through file systems such as SquashFS, JFFS2, CramFS and UBI, and vendor headers.
- Identify: list packages from package databases and identify binaries, for example by version strings.
- Match: check the identified components against vulnerability data such as OSV.dev and NVD-based sources.
- Report: state coverage, including files that could not be unpacked or identified.
What a firmware scan can and cannot tell you
Binary identification is inherently less certain than reading a lockfile. A binary may be patched without its version string changing, or compiled without the feature that makes a vulnerability exploitable. Findings from firmware are therefore a starting point for engineering review, not a verdict.
Some images cannot be analysed at all from the outside: encrypted or signed-opaque images, and bare-metal or RTOS firmware without a file system. A scanner should say so rather than return an empty, reassuring result.
Firmware and the Cyber Resilience Act
The CRA covers hardware products with digital elements and their software, so a connected device's firmware is part of what the manufacturer must secure, document and update. The SBOM requirement in Annex I Part II applies to it, and so does Article 14 reporting when a component in the firmware is actively exploited.
For devices that stay in the field for years, the practical challenge is keeping the inventory of every released image and re-checking it as new vulnerabilities are published.
Preparing images for scanning
A few habits make firmware scans more complete and easier to act on.
- Scan the exact image you ship, not a development build.
- Keep build manifests from Yocto or Buildroot alongside the image; they add package detail.
- Record the image version and the product it belongs to, so findings map to releases.
- Scan again when the vulnerability data changes, not only when the image changes.
Reading the results: coverage and confidence
Two numbers matter as much as the list of findings: how much of the image was unpacked, and how many components could be identified. A result with few findings and low coverage says little; a result with many findings from binary matching needs review before it reaches a customer or an authority.
Record the decision for each finding that matters: affected, not affected and why, or fixed in a named release. Those decisions are what a VEX document communicates, and what an Article 14 report or a customer questionnaire will ask for.
Available in KROMSE today
Firmware scanning in KROMSE today covers Linux-based images.
- Upload a Linux-based firmware image of up to 512 MB; KROMSE unpacks it recursively.
- Packages are listed and checked against OSV.dev, and binaries are matched offline against NVD-based vulnerability data.
- The unpacked root file system is also checked for misconfigurations and embedded secrets, whose values are never stored.
- PX4 .px4 files are unwrapped before unpacking.
- Every scan produces CycloneDX and SPDX SBOMs, and states what could not be unpacked or identified.
- Encrypted images, and bare-metal or RTOS firmware, are reported as not analysable rather than as clean.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q1 2027Bare-metal and RTOS firmware. KROMSE will identify components in firmware without a Linux file system, such as bare-metal and RTOS images built on FreeRTOS or Zephyr.
- Coming · Q1 2027Hardware parts. KROMSE will match the hardware parts in your product against published hardware advisories.
- Coming · Q4 2026 (December)Robotics security. KROMSE will add ROS 2 advisories, component identification inside PX4 and ArduPilot firmware, and robot-specific vulnerability data.
Frequently asked questions
What firmware can KROMSE scan?
Linux-based firmware images up to 512 MB, which KROMSE unpacks through common embedded file systems before identifying components. Encrypted images and bare-metal or RTOS firmware without a file system are not supported yet, and the scan result says so.
How is a firmware scan different from a source-code scan?
A source-code scan reads the dependencies your repository declares. A firmware scan looks at the finished image, including the operating system, libraries and packages added by the build system, which often never appear in your repository. Both are useful; the image is what customers run.
Are firmware findings always accurate?
No scanner can promise that. Identifying binaries by version strings can miss backported patches or report a component that is present but not exploitable. Treat firmware findings as evidence for an engineer to review, and record the decision.
Can KROMSE scan PX4 drone firmware?
Partly. KROMSE unwraps PX4 .px4 files and runs them through the same unpacking and checks as other firmware, but identifying the NuttX-based components inside is not available yet. A Linux-based companion computer image can be scanned in full. Robotics-specific coverage is on the roadmap.
Does the CRA apply to firmware?
Yes, as part of a product with digital elements. A connected device's firmware must meet the essential requirements, be covered by the SBOM and vulnerability handling, and fall under Article 14 reporting if a component in it is actively exploited.