What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Current platform module list and whether source-based analysis is offered alongside binary analysis: confirm with vendor
- Supported firmware formats and architectures: verify against vendor documentation
- Integration list: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Finite State works on artifacts rather than repositories. Its analysis pipeline takes a firmware image or a compiled binary, unpacks the filesystem and nested archives, identifies the operating system, bootloader, kernel, libraries and applications inside, and fingerprints each component and version from binary characteristics rather than from any manifest. That produces an SBOM for something you may not have built and may have no source for, which is the central problem in device security: most of what ships in a connected product came from a supplier's supplier.
From that inventory it matches known vulnerabilities and adds checks specific to embedded targets: hardcoded credentials and keys, exposed private certificates, weak or absent binary hardening such as missing stack protection, insecure configuration in packaged services, and components well past end of life. Around the analysis sits a product-oriented workflow: product versions tracked over time, supplier SBOM ingestion and normalization, VEX generation, and reporting shaped for regimes requiring software transparency in medical, industrial and consumer devices.
Where it fits
This is a product security tool, not an application security one, and it runs at the artifact stage: release candidate firmware, a supplier delivery, or a device you are assessing before procurement. It can be wired into a build pipeline for firmware you produce, but much of its value is in analyzing artifacts that never touched your build system. The prerequisite is organizational: someone must own the answer when the analysis says a supplier shipped an unpatchable component.
Strengths
- Binary and firmware unpacking sees components source-based scanning structurally cannot, the only viable approach for supplier-delivered code.
- Hardening and credential checks address embedded failure modes that generic composition tools do not look for.
- Tracking a product across versions and suppliers fits how device companies organize, rather than forcing a repository-shaped model.
Limitations
- Binary fingerprinting is approximate. Stripped binaries, statically linked code, custom builds and backported patches all produce version identifications needing human confirmation, and backport false positives are persistent in this category.
- Coverage of exotic architectures, proprietary packing and encrypted firmware images is never complete, and a failed unpack is a silent gap.
- It is narrowly aimed at embedded and device software, so it is the wrong shape entirely for a web application estate.
Who it suits
Well matched to manufacturers of connected products, medical device companies and industrial vendors accounting for software they did not write and cannot rebuild, especially where regulators or customers demand an SBOM for a shipped device. Of little use to a team whose software is source-available and deployed to their own cloud, where a conventional composition tool covers the same ground with better precision.
Used Finite State? Recommend it under your own name and title.
Recommend this tool