Snyk for IoT does not exist. Here is what is actually in the gap.
People search for it. Snyk does not have it. Phosphorus is priced wrong for the buyer. NetRise and Finite State sell to PSIRTs. The 10-to-500-device industrial operator running their own firmware is unserved, and the shape of the right tool is obvious once you draw the map.
Type "Snyk for IoT" into Google and you get marketing pages from companies that do not actually scan firmware. OEM-grade binary analysis platforms that quote you in the low six figures. Network-monitoring vendors who watch packets on the wire and have nothing to say about the bytes inside the device. Snyk itself, whose product genuinely stops at the dependency manifest.
Nobody sells what the search query is asking for. The 10-to-500-device industrial operator running their own firmware on ESP32s or Linux gateways, who wants a CVE list per OTA build and a way to gate rollouts when something looks wrong, has nobody to call. Not because the problem is unimportant. Because every existing tool was shaped around a different buyer.
Here is the map.
Snyk stops at the dependency manifest
Snyk Open Source is excellent at one thing: read your package.json, your go.mod, your requirements.txt, walk the dependency graph, cross-reference the Snyk Vulnerability Database, report. That works because the input is structured, the ecosystem is curated, and the build is reproducible from the manifest alone. Snyk Container extends the same pattern to container images, assuming a Linux distro with a package manager and a relatively standard runtime.
There is no Snyk product that ingests an ESP-IDF firmware binary, a Yocto-built rootfs, or a Buildroot image and tells you what CVEs apply to the C dependencies pinned in the build. There is no Snyk story for cross-compiled Rust firmware running on a custom Linux gateway. The closest you get is running Snyk CLI against the source repo at build time, which catches your application dependencies and silently misses the entire embedded toolchain. Fine for a Node.js service. Useless for a deployed device.
The gap is structural, not a roadmap omission. Snyk's customer is a SaaS engineering team. The buyer who needs IoT firmware coverage has a different deployment lifecycle and a different risk surface, and Snyk has correctly chosen not to chase them.
Phosphorus has the right price and the wrong buyer
In November 2025, Phosphorus did something the rest of the IoT-security category refused to do: they published transparent per-device pricing, starting at $5 per device per year. This is the right unit. Per-device pricing is how an industrial operator actually thinks about a fleet. N devices, N times the unit, model it before the sales call.
The problem is who Phosphorus built the product for. Their marketing is explicit: enterprise xIoT, which in their definition spans IP cameras, VoIP phones, printers, building-automation controllers, medical devices, and the rest of the corporate-IT-adjacent device sprawl. Reference deployments are hospitals, large enterprises, and government agencies running tens of thousands of heterogeneous third-party devices where the security team's job is credential rotation, patching against known CVEs in vendor firmware, and configuration hardening.
That is a real problem and Phosphorus solves it well. It is not the problem of the operator running their own firmware on 50 ESP32s in a water treatment plant. The Phosphorus value proposition assumes the firmware is a vendor blob you cannot change. If you wrote the firmware, the questions you want answered (which CVE entered the build at commit X, which OTA channels got it, can I block the rollout) do not map onto what Phosphorus does.
Right unit, wrong buyer.
NetRise and Finite State sell to PSIRTs
NetRise and Finite State are the two best-known players in firmware binary composition analysis. The technical work is genuinely impressive. NetRise unpacks a firmware binary, reconstructs an extended SBOM (XBOM), and surfaces CVEs against the components it identifies, even when no source manifest exists. Finite State sells the same shape of capability plus a workflow layer around PSIRT triage and supplier risk.
Their buyer is the OEM Product Security Incident Response Team. The pricing reflects it. Public reporting and vendor RFP discussion put deal sizes in the range of $100,000 to $500,000+ per year, with custom enterprise pricing above that. No self-serve tier. No per-device line item. You are buying a platform license sized to your security team's seat count and your supplier portfolio.
This makes complete sense for a medical-device OEM with a regulatory obligation to respond to disclosed vulnerabilities across a product line shipped to thousands of hospitals. It makes no sense for an industrial operator with 80 gateways in 12 substations and a roadmap line item that says "implement vulnerability management before the next SOC 2 review." The floor price for a NetRise or Finite State deal exceeds the entire annual security budget of the company that needs the capability.
Right capability, wrong commercial shape.
ICS network monitors are watching a different layer
Claroty, Dragos, and Nozomi Networks are the canonical names in industrial-control-system monitoring. They are excellent at what they do: passive packet inspection on OT networks, parsing Modbus, DNP3, IEC 61850, PROFINET, S7, and the long tail of industrial protocols off a SPAN port; building an asset inventory from observed traffic; alerting on anomalous behavior or known attack signatures.
That is not vulnerability management on the firmware. That is detection and response at the network layer. If a CVE in the OpenSSL build linked into your gateway is exploitable over the network and an attacker exploits it, a Dragos sensor might catch the traffic. It will not tell you the CVE is in your build before the attacker gets there.
The two categories are complementary, not substitutes. An operator who buys Claroty still has an open question about which CVEs are sitting in the firmware they shipped last month. The network monitor watches the wire. Nobody on that side of the market is touching the binary on the device.
Build-time SBOM beats unpack-time SBOM
A recurring claim in the binary-composition-analysis category is that unpack accuracy is meaningfully better than competitors. NetRise's marketing has claimed their unpack identifies 4 to 25 percent more components than peer tools. Take it at face value. It is still worse than the build that produced the binary.
If you control the source, you do not need to reverse-engineer your own output. You can emit a CycloneDX or SPDX SBOM directly from the toolchain (cargo-cyclonedx, esp-idf SBOM tooling, syft against a Yocto manifest) and pin every dependency by exact version and source. The accuracy is whatever your build system's accuracy is, which is 100 percent for declared dependencies and as good as your toolchain for the transitive ones.
Unpack-time analysis is for the case where you do not own the source: vendor-supplied blobs, acquired product lines, third-party modules in your bill of materials. For your own firmware, binary decomposition is solving a problem you should not have. The right shape is to generate the SBOM at build time, attach it to the OTA artifact as metadata, and run the CVE check against that SBOM before the rollout fans out.
The actual gap
Draw the map and the gap is obvious. There is a buyer who:
- Operates somewhere between 10 and 500 devices, mostly ESP32-class microcontrollers or small Linux gateways
- Wrote the firmware themselves, or paid an integrator who wrote it for them and handed over the source
- Already runs an OTA pipeline (whether home-grown, AWS IoT Jobs, Mender, or something stitched together)
- Has SOC 2, IEC 62443, or a customer security questionnaire showing up on the roadmap
- Wants to know which CVEs are in each build before it ships, and wants to gate rollouts when a critical one shows up
- Has a budget in the tens of thousands per year for security tooling, not the hundreds of thousands NetRise quotes
This buyer is not Phosphorus's buyer (wrong device class). Not NetRise's buyer (one to two orders of magnitude too small for the deal). Not Claroty's buyer (different layer). Not Snyk's buyer (no embedded story). They search "Snyk for IoT," find nothing that fits, and either roll their own with grype plus a homemade SBOM pipeline plus a spreadsheet, or punt on the problem until an auditor surfaces it.
What the right shape looks like
Once the buyer is clear, the product shape is forced.
Pricing is per-gateway, not per-PSIRT-seat. The math has to work for an operator with 80 devices and a five-figure security budget. Phosphorus had the right instinct here.
SBOM extraction happens at build time, inside the customer's existing CI, against the source they already own. No binary unpack stage, no reverse-engineering, no marketing claim about being 4-to-25-percent better at unpacking because the answer is just "what your toolchain emitted." Closer to how Snyk Open Source works than to how NetRise works.
CVE matching runs against the NVD, OSV, and GitHub Advisory Database feeds. The differentiation is not the database. It is the integration into the OTA pipeline, where a critical CVE on a build can block the rollout, gate it to a canary subset of the fleet, or require explicit acknowledgement before fanning out.
Per-tenant policy, because the operator's customers each have different risk tolerance. A fleet shipped to a hospital wants stricter gating than the same firmware deployed to a research lab. The policy lives next to the OTA channel, not in a separate platform.
Audit-log evidence comes for free, because the gating decisions, the SBOMs, and the CVE results are written to the same immutable log the operator already needs for SOC 2.
Not a feature list. What the constraints of the actual buyer push the product toward.
I am building this. SCADABLE is the name. The bet is that the gap is real, the buyer is identifiable, and the right product fits in the OTA pipeline that operator already runs. If that is your fleet, the next section is for you.
Talk to a founder
If you're an industrial operator running custom firmware on a fleet of any size and the CVE-management problem is on your roadmap, get on the calendar. I'm the person building this and I'd rather hear about your fleet than write more blog posts.