What this tool does
- SBOM scanner: builds the component list from lock files (npm, yarn, pnpm, pip, Poetry, Cargo, Go, Maven, Composer) and from Yocto or Buildroot manifests.
- SBOM reader: opens your existing CycloneDX or SPDX JSON file (such as
bom.json,*.cdx.json,manifest.spdx.jsonor*.spdx.json) and shows its components and known vulnerabilities in a readable table. - SBOM checker: checks every component by name and version against the OSV.dev vulnerability database and sorts the results by severity.
- Export: download the result as CycloneDX 1.7, SPDX 2.3 or CSV.
Your files never leave your computer. Files are read in your browser. With the vulnerability check on, only the package name, version and ecosystem are queried on OSV.dev; turn the check off for a fully offline scan.
What is an SBOM?
An SBOM (software bill of materials) is a machine-readable list of the components inside software or firmware. It brings the open-source libraries, operating system packages, third-party components and their versions in a product together in one file.
A typical SBOM entry holds:
- Component name and version
- Supplier or author
- Unique identifiers: PURL and CPE
- File hashes and licence information
- Dependency relationships between components
When a new vulnerability (CVE) is published, a team with a current SBOM can see within minutes which products and firmware versions are affected. Without one, the same question turns into days of investigation.
For a longer explanation with a firmware example and the CRA details, read What is an SBOM?
SBOM under EU regulation: what the CRA requires
The EU regulation that makes an SBOM a legal requirement is the Cyber Resilience Act, Regulation (EU) 2024/2847. It applies to products with digital elements placed on the EU market from 11 December 2027; for an overview, see the Cyber Resilience Act summary.
CRA Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components in their products, including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies.
- The SBOM is part of the technical documentation (Annex VII). It does not have to be published.
- It is provided to a market surveillance authority on a reasoned request.
- No specific format is mandated; CycloneDX and SPDX are the two commonly used ones.
- It should be kept current for every firmware version, and components are monitored for new vulnerabilities throughout the support period.
Article 13 lets the Commission specify the format and elements of the SBOM by implementing act; check EUR-Lex for whether one has been adopted. If the manufacturer chooses to make the SBOM available to users, the user information (Annex II) states where it can be accessed.
An SBOM alone is not CRA compliance. Fixing vulnerabilities, secure updates, Article 14 reporting and the technical documentation are required too. For an overview, see the CRA guide.
CycloneDX or SPDX?
| Aspect | CycloneDX | SPDX |
|---|---|---|
| Developed by | OWASP | Linux Foundation |
| Standard | Ecma International ECMA-424 | ISO/IEC 5962 |
| Focus | Security: vulnerabilities, VEX and services | Licence compliance and file-level detail |
| Output of this scanner | CycloneDX 1.7 JSON | SPDX 2.3 JSON |
Both are commonly used formats that serve the CRA requirement. Choose based on what your customers and toolchain expect; this scanner produces both.
SBOMs for embedded systems: Yocto, Buildroot and binaries
- Yocto: the image manifest written at the end of the build (
<image>.manifest) andlicense.manifestlist the packages and versions in the image. Thecreate-spdxclass also produces SPDX output. - Buildroot:
make legal-infowriteslegal-info/manifest.csvwith the packages and versions. - C/C++ projects without a package manager, and prebuilt binaries: with no source manifest, components have to be identified from the firmware image itself. If some cannot be identified, the SBOM should be marked incomplete.
The scanner above reads Yocto manifests, Buildroot manifest.csv, lock files and existing CycloneDX or SPDX files. Analysing the firmware image itself is what our platform does.
After the SBOM: vulnerability matching and VEX
Matching each SBOM component against databases such as OSV and NVD produces a raw vulnerability list. It is often long; exploitation signals such as CISA KEV and EPSS help set the order.
A vulnerability present in a component may still not be exploitable in the product: the affected code may not be compiled in or used. The standard way to communicate that decision to customers and authorities is a VEX document; CSAF and OpenVEX are the two most common formats.
SBOM questions
Can I open and check an SBOM file I already have?
Yes. Drop your CycloneDX or SPDX JSON file; the tool lists its components and checks each one against known vulnerabilities on OSV.dev. It reads CycloneDX and SPDX 2.x JSON files whatever they are called; CycloneDX XML (bom.xml) and SPDX tag-value files are not supported yet.
How do I view a CycloneDX JSON file?
Drop the file (for example bom.json or sbom.cdx.json) onto the area at the top of this page. The viewer lists every component, including nested ones, with its version, ecosystem and the file it came from; you can search the list and show only vulnerable components. CycloneDX 1.x JSON is supported; CycloneDX XML is not yet.
What does the viewer show, and can I download the result?
For each component: its name, version, ecosystem and source file, and, with the vulnerability check on, the known vulnerabilities on OSV.dev with their severity and the version that fixes them. You can download the result as CycloneDX 1.7 JSON (including the vulnerabilities found), SPDX 2.3 JSON or CSV.
How do I open a manifest.spdx.json file?
Drop it onto the area at the top of this page, or pick it with "choose from your computer". The tool lists the packages in the SPDX 2.x JSON file and, if the vulnerability check is on, checks them on OSV.dev. The file is read in your browser and never leaves your computer.
Do I need to sign up or pay?
No. The SBOM scanner is free and needs no sign-up.
Do I have to publish my SBOM to customers?
No. Under the CRA the SBOM is part of the technical documentation and is provided to a market surveillance authority on request. Sharing it with customers is your choice.
Is an SBOM required by EU regulation?
Yes, for products with digital elements under the Cyber Resilience Act (Regulation (EU) 2024/2847). Annex I Part II(1) requires a machine-readable SBOM covering at least the top-level dependencies, kept in the technical documentation. It applies from 11 December 2027.
Which SBOM format does the CRA require?
It does not mandate one; it must be commonly used and machine-readable. CycloneDX and SPDX both qualify.
How often should the SBOM be updated?
For every firmware or software release. Components should be monitored for new vulnerabilities throughout the support period.
Can this scanner read a firmware image?
No. The web scanner reads lock files, Yocto and Buildroot manifests and existing SBOM files. Firmware image analysis is done in our platform, as part of the enterprise pilot.
Do I upload my files to your server to get an SBOM?
No. Files are read in your browser. With the vulnerability check on, only the package name, version and ecosystem are queried on OSV.dev.