Finite State is a commercial product security platform for connected devices. It builds a component inventory from the firmware and binaries a product actually ships, not from the dependency manifests a build declares.
That distinction is why it sits in the SCA category but does not behave like one. Most dependency scanners cannot open a firmware image at all.
Matt Wyckhouse founded the company in 2017 and still runs it. It raised a $30M Series B led by Energize Ventures in August 2021, with Schneider Electric Ventures and Merlin Ventures joining.
It became widely known in 2019 for a Huawei supply chain assessment that analyzed more than 1.5 million files across roughly 10,000 firmware images spanning 558 products.
In June 2024 Finite State acquired MergeBase , a source-code SCA vendor. That folded conventional manifest-based scanning into a platform previously built around binary analysis.
I evaluated Finite State against vendor documentation, its public GitHub repositories, and independent press coverage of its funding and acquisition history. This review did not include a firmware-corpus test of the platform itself.
What is Finite State?
Finite State is a product security platform that decomposes shipped software artifacts into an evidence-backed component inventory. Firmware images, compiled binaries, container layers, and source repositories all feed the same platform.
They do not take the same path through it. Binaries and firmware go through decomposition; source repositories run the manifest-based dependency scanning that arrived with MergeBase.
From that inventory it produces SBOMs in CycloneDX and SPDX, VEX documents recording exploitability decisions, and control-mapped evidence packages for regulatory audits.
The vendor now markets the product as an “AI-native Product Security OS” spanning four named pieces: the Finite State Platform, Assurance Studio, AgentOS, and Finite State Copilot.
Underneath the branding, the durable capability is binary decomposition. Finite State identifies components from compiled bytes, which is how it surfaces build-time inclusions and firmware-only code that never appears in a lockfile.
Its buyer is a product security team at a device manufacturer, not an application security team at a software company. The published customer logo wall leans automotive, industrial, energy, and medical.
| Capability | What it covers |
|---|---|
| Firmware and binary decomposition | Unpacks firmware images and executables to identify components without needing source access or a build manifest. |
| Artifact-derived SBOM | Each component entry is tied to evidence observed in the artifact, then reconciled against source and supplier-provided SBOMs. |
| Reachability prioritization | Filters findings by whether the vulnerable code is actually present and executable in the shipped binary. |
| Compliance evidence | Maps components, decisions, and verification results into audit packages aimed at EU CRA, FDA 524B, and IEC 62443. |
What are Finite State’s key features?
Binary and firmware analysis
The platform unpacks a firmware image, walks its filesystems, and identifies the libraries and executables inside. This is the capability manifest-only SCA tools do not have.
Finite State reports support for 50+ binary instruction set architectures — a vendor figure. The table below lists what the documentation actually names.
| Input layer | Named coverage |
|---|---|
| Instruction sets | ARM, AARCH64, MIPS, PowerPC, RISC-V, x86, x64 (vendor reports 50+ in total) |
| Binary and firmware formats | ELF, DOS executables, object code, Intel HEX, S-Record, plus vendor formats from Adobe, Cisco, DJI, and Ambarella |
| Archives and packages | Gzip, bzip2, LZMA, 7-Zip, RAR, ZIP, APK, Debian packages, MSI |
| Filesystems | FAT, NTFS, BTRFS, VHD, VMDK, raw disk images, Android sparse images |
Source-code SCA
The MergeBase acquisition in June 2024 added manifest-based dependency scanning. That matters because most device teams have both a repository and a shipped binary, and the two rarely agree.
Finite State reconciles the two views into one component list, which is the part a spreadsheet workflow is hardest to keep consistent on.
Listed language coverage on the source side runs Java, Go, Python, JavaScript and Node, PHP, .NET, Ruby, and C/C++. That is the ecosystem set a device team’s tooling repositories usually sit in.
The platform also imports findings from third-party scanners, which the documentation currently puts at 161 supported tools. That matters if you are consolidating rather than replacing an existing toolchain.
Reachability and triage
Finite State applies reachability analysis to decide whether a flagged component is genuinely exposed in the shipped artifact.
The vendor reports 10.9 million findings analyzed for reachability since 2024, of which 4.4 million were removed as unreachable, or 40.5% of the total. Treat that as vendor telemetry, not an independent benchmark.
The vendor’s headline noise-reduction claim is a marketing best case. The 40.5% aggregate is the more useful figure, because it spans everything analyzed rather than a favorable slice.
Supplier SBOM reconciliation
Device manufacturers receive SBOMs from suppliers and struggle to verify them consistently by hand. Finite State ingests those files, normalizes naming and versions, then compares the claims against what it observes in the firmware.
That reconciliation is a genuinely hard problem, and it is one of the clearer reasons a device manufacturer would pick this over a general-purpose scanner.
CI/CD and API surface
Finite State publishes GitHub Actions for setup, scan, artifact upload, report generation, quality gates, PR comments, and SBOM download.
The setup action installs fs-cli, the single-binary CLI that the current documentation treats as the primary developer surface. A Python SDK
wrapping the GraphQL API is also published.
There are public Jenkins plugin and Azure DevOps task repositories too, and the Jenkins plugin is listed in the official Jenkins plugin index.
Listed workflow integrations include GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket, Azure Repos, Jira, and Slack.
How does Finite State support EU CRA, FDA, and IEC 62443 compliance?
The regulatory calendar is the reason this product category exists right now. A handful of dated obligations drive most connected-device buying conversations.
The EU Cyber Resilience Act entered into force in December 2024. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the bulk of obligations from 11 December 2027.
FDA section 524B of the Federal Food, Drug, and Cosmetic Act has applied to cyber device submissions since 29 March 2023, and requires an SBOM as part of the submission.
IEC 62443 governs industrial automation and control systems, and NIST SSDF plus Executive Order 14028 cover US federal software supply.
| Regime | Key date | What it demands | Finite State’s artifact |
|---|---|---|---|
| EU Cyber Resilience Act | In force Dec 2024; exploited-vulnerability reporting from 11 Sep 2026, bulk from 11 Dec 2027 | Product-level SBOM, vulnerability handling, post-market monitoring | Artifact-derived SBOM plus VEX decisions and an audit export |
| FDA 524B | Applies to cyber device submissions since 29 Mar 2023 | SBOM as part of the premarket submission | SBOM generated from the shipped image, not the build manifest |
| IEC 62443 | Sector standard, no single deadline | Component inventory and verification evidence for industrial control systems | Control-to-verification mapping in the audit package |
| NIST SSDF / EO 14028 | US federal software supply | Attested secure-development practice and component transparency | Same SBOM plus attestation export |
Finite State’s answer to all four is the same shape: generate the SBOM from the shipped artifact, attach VEX decisions, map controls to verification results, and export an audit package.
The honest framing is that this produces the artifacts an assessor asks for. It does not produce compliance. That still depends on your processes, your documentation, and your post-market monitoring discipline.
If you are working through the CRA specifically, my EU Cyber Resilience Act tooling guide covers what the regulation actually asks for before you shortlist any vendor.
Finite State vs Black Duck
Black Duck is the closest large-vendor comparison, because it is one of the few established SCA platforms with real binary analysis rather than manifest parsing alone.
Black Duck’s strength is breadth and institutional depth. Black Duck markets its open-source component and license knowledge base as one of the largest available.
Its license-compliance workflows are built for legal review, M&A due diligence, and audit-grade attribution reports.
Finite State’s strength is narrower and deeper. It is built around firmware unpacking across embedded architectures and RTOS environments, supplier SBOM reconciliation, and regulatory evidence packages aimed specifically at device manufacturers.
The practical difference shows up in what each treats as the primary artifact. Black Duck assumes a software organization with repositories and builds.
Finite State assumes a hardware organization shipping firmware images it may not have fully built itself.
Pick Black Duck if license compliance, attribution reporting, and a large open-source knowledge base drive your requirements.
Pick Finite State if your risk lives in compiled firmware and your deadline is a CRA or FDA submission.
Finite State vs Snyk
Snyk is the default developer-first SCA platform. Both now scan source dependencies, since MergeBase brought conventional source SCA to Finite State in 2024.
The overlap stops there. Their primary buyers and primary artifacts pull the two products in different directions.
Snyk optimizes for developer feedback loops. IDE plugins, pull-request checks, automated fix PRs, and a proprietary vulnerability database give engineers a fast path from finding to merged patch.
Finite State optimizes for proof. Its output is a component inventory tied to observed evidence in a shipped artifact, plus the VEX and audit documentation a regulator or an enterprise customer will ask for.
Where Snyk sees a package-lock.json, Finite State sees a signed firmware blob with a squashfs root filesystem and a vendor-modified BusyBox.
Snyk cannot open that. Finite State cannot give a Node developer an inline fix suggestion the way Snyk does.
Many device manufacturers end up running both: Snyk in the application repositories, Finite State on the release artifact.
Pick Snyk if your codebase is application software and developer remediation speed is the goal. Pick Finite State if you ship physical products and need to prove what is inside them.
How much does Finite State cost?
Finite State does not publish prices. Its pricing page carries an FAQ about how quotes are structured, covering volume and multi-project discounts, EMEA invoicing, proof-of-concept availability, and data residency. No numbers attached.
There is no free tier and no self-serve signup. Every route into the product goes through a demo request or a sales conversation.
| Commercial question | What the vendor documents |
|---|---|
| List price | Not published — quote only |
| Free tier | None |
| Self-serve trial | None; a vendor-scoped proof of concept may be available through sales |
| Quote structure | Volume and multi-project discounts referenced in the pricing FAQ |
| Data residency | Addressed in the pricing FAQ; confirm the specifics during procurement |
| Invoicing | EMEA invoicing supported |
| Inspectable before contact | Python SDK, GitHub Actions, Jenkins plugin, Azure DevOps tasks — all public |
That is normal for this segment, where deals are scoped per product line, per release cadence, and often per managed-service engagement. It also means you cannot evaluate the platform without engaging the vendor.
What you can inspect first is the public tooling. The Python SDK , the GitHub Actions, the Jenkins plugin, and the Azure DevOps tasks are all open on GitHub.
Reading those tells you how the integration would work before anyone quotes you.
Finite State also sells managed services alongside the platform, including CRA advisory work. Bundling those changes the shape of a quote considerably, so ask for them to be priced separately.
How do you get started with Finite State?
There is no self-serve path, so the sequence starts with sales and moves to integration.
- Request a demo and scope a proof of concept. Bring one real firmware image and one repository. The value of the platform is entirely in whether it unpacks your artifact cleanly, and that is not knowable from a slide deck.
- Wire up CI. Add the setup and scan actions from
FiniteStateInc/finite-state-actions, storing the API token as a secret and the domain and project ID as repository variables. - Add a quality gate. The
quality-gateaction fails a build when findings cross configured thresholds. Start it in warn mode so you learn your baseline before blocking releases. - Automate SBOM export. The
download-sbomaction pulls the SBOM for a project version, which is what you attach to a customer request or a regulatory submission.
For scripted workflows, install the SDK with pip3 install finite-state-sdk and drive the GraphQL API directly.
When should you use Finite State?
Finite State makes sense when the thing you ship is a device and the thing you have to prove is what is inside it.
That covers automotive suppliers facing UNECE and supplier audits, medical device makers preparing FDA submissions, industrial and energy vendors under IEC 62443, and any manufacturer selling into the EU after the CRA deadlines.
It also fits teams inheriting firmware from contract manufacturers or acquired product lines. When nobody in the building has the source, binary analysis is the only way to build an inventory.
It is a poor fit for pure software teams. If you ship a SaaS product or a mobile app, a manifest-based scanner gives you most of the value for far less complexity.
It is also a poor fit if you want a free or trial-first evaluation. Nothing runs without a sales conversation first, which rules it out for small teams and side projects.
If you are earlier in the process and still working out what an SBOM has to contain, start with my guide on what an SBOM is .
What are Finite State’s strengths and limitations?
Where Finite State is strong
Binary decomposition is the real moat. Unpacking firmware across dozens of architectures, filesystems, and RTOS environments is difficult engineering, and very few SCA vendors attempt it.
Supplier SBOM reconciliation solves a live problem. Manufacturers are drowning in supplier-provided SBOMs they cannot verify. Comparing those claims against observed firmware content is directly useful.
Regulatory framing is specific, not generic. The evidence packages target named regimes with named deadlines, which matters when the buyer’s actual deliverable is an audit submission.
Integration surface is inspectable. Public GitHub Actions, a Jenkins plugin, Azure DevOps tasks, and a Python SDK let you understand the workflow before you buy.
Where Finite State falls short
No free tier, no self-serve trial, no published pricing. Evaluation runs through a vendor-scoped proof of concept arranged by sales, which is a real barrier for teams that want to compare tools quickly.
Vendor metrics dominate the public evidence. The reachability and noise-reduction figures are all self-reported telemetry. No independent benchmark of its unpacking accuracy or false-positive rate was identified during this review.
Heavy platform for a narrow buyer. The 2026 “AI-native Product Security OS” repositioning stacks threat modeling, agent workflows, and a copilot on the analysis engine. If you only want firmware SBOMs, that is a lot of surface area.
Weak fit for developer remediation. It does not compete with Snyk or Endor Labs on inline fix suggestions, IDE feedback, or automated upgrade pull requests.
Public open-source footprint is small. Its GitHub repositories are integration glue rather than a community project, so there is no large user base producing independent write-ups.
What are the alternatives to Finite State?
The alternatives split into two groups, and which group you look at depends on whether firmware is actually in scope.
If you need binary and firmware analysis, the direct competitors are specialist device-security vendors: ONEKEY and NetRise both build product security platforms around firmware decomposition and SBOM generation, and Black Duck offers binary analysis inside a broader SCA suite.
One caveat on that shortlist: Accenture announced in June 2026 that it is acquiring NetRise outright , alongside runZero and a majority stake in Dragos.
The deal was expected to close in late 2026, so ask NetRise about roadmap and contract continuity before you shortlist it.
If you actually just need SBOMs and dependency scanning for software, the field is wider and cheaper. Syft generates CycloneDX and SPDX SBOMs from containers and filesystems for free, and pairs with Grype for vulnerability matching.
Anchore builds a commercial platform on that same open-source core, with FedRAMP-oriented reporting. Dependency-Track is a free OWASP project for continuous SBOM monitoring once you have the files.
For conventional developer-facing SCA, Snyk leads on remediation workflow, Endor Labs on function-level reachability, and JFrog Xray if your artifacts already live in Artifactory.
For a wider comparison of SBOM generation specifically, see my SBOM tools comparison . The full category roster is on the SCA tools page.