Free check

Is anything you ship being exploited?

Drop in an SBOM. We match it against the CISA catalogue of vulnerabilities that are being exploited in the wild, and show you what comes back.

A component on the list is not a reportable event. It is a reason to assess whether your product is affected, and the reporting duty starts only if it is.Art. 14⁠(1)⁠

Drop an SBOM, or choose a file

Format: CycloneDX SPDX
Encoding: JSON · XML tag-value
Size: up to 4 MB

Nothing is storedParsed in memory and discarded. No account, and no record of what you ship — we keep the count of how many components came back, never their names.

I do not have an SBOM

A software bill of materials is the list of every open-source component inside something you ship, with its version, written in a format other tools can read. Syft is a free tool from Anchore that builds one for you by reading a container image, a source directory or a binary. It takes a minute, and you only need it once per release.

# 1. Install it, on macOS
brew install syft

# ...or anywhere else
curl -sSfL https://get.anchore.io/syft | sh -s -- -b /usr/local/bin

# 2. Point it at what you ship
syft acme/agent:latest -o cyclonedx-json > sbom.json

# ...or at a source directory
syft dir:. -o cyclonedx-json > sbom.json

Replace acme/agent:latest with your own image. The redirect writes the bill of materials to sbom.json, and syft keeps its progress on stderr, so the file stays valid JSON. Then drop that file above. The full guide covers formats and running it per release.

What the list is

The Known Exploited Vulnerabilities catalogue is kept by CISA, the United States cybersecurity agency. A vulnerability is added when there is reliable evidence it is being exploited somewhere in the world, which makes it the most widely used public answer to the question the Regulation asks: not “is this severe” but “is this being used”. It is a list of vulnerabilities, not of products, so it has to be matched against what you ship by component and version.

Why a US list matters to an EU duty

Article 14 turns on an actively exploited vulnerability in your product.Art. 14⁠(1)⁠ Exploitation is not regional; a vulnerability exploited against American targets is exploited. What no list can tell you is whether your product is affected: that depends on how the component is used, whether the vulnerable code is reachable, and whether a fix is already in the version you ship. The check names the component; the assessment is yours.

What it reads

CycloneDX 1.4 to 1.7, in JSON or XML, and SPDX 2.2 and 2.3 in JSON. Components are matched by package URL, so a component without one is counted as read but not as identifiable, and the result says how many of each. Files up to four megabytes. If you do not have a file, generating one takes a minute.

What happens to the file

It is parsed in memory, matched, and discarded. What is recorded is a count: how many components were read and how many came back, never which. That is also why there is no shareable link for this check: a permanent page would mean storing a map of your exploitable components, and the check is built on not doing that. The product stores an inventory, under a workspace you control; the security page says exactly how.

A hit is where the clock question starts. What the duty requires, how a report is filed, and whether it applies to you at all.

This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.