For teams that ship firmware

Most advisories don't touch your firmware. We find the ones that do.

Upload an SBOM for something you ship. We take the SDK apart, check every library in it against NVD and against what your chip vendors publish themselves, and show you which advisories reach your build. Each one links to the vendor's own document.

Try it free Talk to us

Free for one product. No card and no password: we email you a sign-in code.

One build, five advisories Example
Buffer overflow in Mbed TLS Affected your build ships 3.6.2 · fixed in 3.6.3
Espressif security advisory, no CVE Affected published by Espressif only · NVD has no record of it
Bluetooth flaw in NimBLE Not affected the fix is already in your SDK's copy of NimBLE
Zephyr network stack bug Needs a look Nordic's fork may have backported the fix · here's what to check
DHCP parsing bug in lwIP Not affected your lwIP 2.2.1 is past the fix

Two to fix, one to look at, and two you can close with a VEX statement.

Why

Your scanner checks NVD. Your vendors publish somewhere else.

Most scanners look each package up in NVD by name and version. Plenty of what affects firmware never shows up that way, even when it has a CVE.

No CVE at all

Espressif, Silicon Labs and Nordic publish advisories of their own that never get a CVE. A CVE-keyed scanner has nothing to match.

Not in NVD yet

A CVE can exist for weeks before NVD has a record of it, or links it to any product. Until then a lookup comes back empty.

Filed under another name

NVD lists the bug against the SDK while your SBOM names the library, or against upstream while you ship a vendor's fork. The names don't match, so nothing is reported.

How it works

From an SBOM to a short list you can act on.

AFFECTED NEEDS A LOOK NOT AFFECTED

Upload what you have

A CycloneDX or SPDX file, the output of west spdx or esp-idf-sbom, a platformio.ini, or the address of a public GitHub repository.

We take the SDK apart

An SBOM usually names the SDK and stops there. We read that exact release of ESP-IDF, Zephyr, nRF Connect and others to see which libraries it bundles, at which versions.

Every finding shows its source

Each one says why it applies: your version against the vendor's affected range, or the actual code in a vendor's fork. The vendor's own document is one click away.

You decide what it means

Mark findings not affected, with a reason. Export them as CSV or a VEX file, or print a report for a customer or an auditor.

The CRA

The Cyber Resilience Act applies to anything you sell into the EU.

Wherever it's made. Fines go up to €15M or 2.5% of worldwide turnover. Most of the work is knowing what's in each product, dealing with what turns up, and being able to show what you decided and when.

The law took effect

Manufacturers' obligations became law and the phase-in started.

Reporting started

Once you know an exploited vulnerability is in your product, you have 24 hours to send an early warning, 72 for a notification, then a final report. Your users have to be told too.

Everything else, and CE marking

An SBOM per product, a disclosure policy and contact, security updates for at least five years, published fixes, and documentation kept for ten.

What you get

What's in the product today.

Findings with evidence

Affected, not affected, or needs a look, each with one sentence of why and the vendor's document behind it.

Advisories with no CVE

Vendor advisories read straight from the vendor, so the ones a CVE scanner can't see are in the list too.

VEX and CSV exports

Your own decisions as a CycloneDX VEX file, every finding as CSV, and a report that prints cleanly.

CycloneDX VEX · CSV · PDF

Alerts (Pro)

Your current releases are checked again every day, and you get an email when a new advisory reaches one.

Exploited-in-the-wild flags

Findings on CISA's known-exploited list are marked, because those are the ones the 24-hour clock is about.

Your data, your call

Invite colleagues to your account. Delete a release, a product or the whole account yourself, whenever you want.

On the way: help with the CRA's 24-hour reports, drafted customer notices, and a step for your CI so every build gets checked without an upload.

Works with

Bring the SBOM you already have.

If your toolchain writes an SBOM, upload that. If all you know is the SDK and its version, an SBOM that names just that is enough to start. We work out what the release bundles.

You don't need to replace a scanner, change your build, or send us firmware images. We only see component names and versions.

SDKs we take apart

ESP-IDFArduino-ESP32ZephyrnRF Connect SDKSilicon Labs SDKsSTM32CubePlatformIO

Files we read

CycloneDXSPDX JSONSPDX tag-valueplatformio.iniGitHub URL

Where advisories come from

Vendor PSIRTsNVDOSVGitHub advisoriesCISA KEV

Where we're at

We're early, and want to build the rest with a few teams.

Finding what reaches your build works today. The reporting side we'd rather design with people who do this job, so if you get in touch, expect questions from us too.

  • Send us one product and we'll go through what the last month of advisories means for it.
  • You keep everything that comes out of it, whether or not you become a customer.
  • In return we'd like your honest reaction, and a reference if we've earned one.
Ask us about it

Pricing

Start with one product. Pay when you want it watched.

A product is one thing you ship. Uploading its next release replaces the last, so keeping it up to date never costs more.

Free

€0

1 product

  • Every advisory that reaches it, including vendor ones with no CVE
  • The vendor's document behind each finding
  • Re-check whenever you like
Try it free

Pro

€200/month

up to 5 products · or €2,000 a year · excl. VAT

  • Everything in Free, for five products
  • Checked every day, with an email when something new reaches a build
  • VEX, CSV and printable reports
Get early access

Pro is open to early customers. Tell us what you ship on.

Larger teams

Let's talk

more than 5 products

  • Everything in Pro, for all your products
  • Help getting SBOMs out of your builds
  • Invoices, and a contract your procurement team will recognise
Talk to us

Questions

Things people ask us.

We don't have an SBOM. Our firmware is a vendor SDK and some code we copied in years ago.
Your toolchain can probably write one already: ESP-IDF, Zephyr and nRF Connect each have a one-line command for it, and a PlatformIO project's platformio.ini works as it is. If all you know is the SDK and its version, an SBOM that names just that is enough to start. We take the release apart into what it bundles.
What do you see of our product?
The SBOM you upload: component names and versions. No source code and no firmware images. To look your components up we send their names and versions to OSV, NVD and GitHub, never who you are. You can delete any of it yourself, at any time.
Is an AI deciding whether we're affected?
No. Whether an advisory reaches your build is worked out from versions, the vendor's stated ranges and, for vendor forks, the code itself. Every verdict links to the vendor's document. A model helps us read advisories, and nothing it reads is used until it's been found in the source. What you decide about a finding is recorded with your name, and that's what your VEX says.
We sell in the US, not Europe.
The CRA covers anything placed on the EU market, so check whether a distributor puts you there. Either way, the same things (an SBOM, "not affected" statements, a disclosure policy, update commitments) are what US medical device rules, the UK's regime and your bigger customers' security questionnaires already ask for.

Get in touch

Tell us what you ship on.

Send a note and one of us will reply, usually within a couple of working days. If it doesn't sound like a fit, we'll say so.

Prefer email? Write to [email protected]. We only use your address to reply.