SBOM checker for the CRA

Drop a CycloneDX or SPDX JSON file and see, field by field, what is missing for the CRA minimum and for BSI TR-03183-2.

The Cyber Resilience Act asks for a software bill of materials but does not list its fields. Germany's Federal Office for Information Security (BSI) does, in Technical Guideline TR-03183-2. This checker reads your SBOM in the browser and shows which checks pass, how many components have each field, and what to add.

Drop an SBOM here, or choose a file CycloneDX JSON (bom.json, *.cdx.json) · SPDX 2.x JSON · SPDX 3 JSON-LD

Download the example (CycloneDX 1.6)

Or paste the JSON

SBOM contents

Your file is read in your browser and is never uploaded or stored.

What the checker looks at

Level	Checks
CRA minimum Annex I, Part II, point 1	The SBOM is in a commonly used, machine-readable format, lists the components, and identifies at least the app's top-level dependencies.
BSI TR-03183-2, the SBOM itself Sections 4 and 5.2.1	CycloneDX 1.6 or later, or SPDX 3.0.1 or later, in JSON or XML. The creator of the SBOM (an email address, or a URL if there is none) and a timestamp. Completeness of the dependency list is stated.
BSI TR-03183-2, each component Section 5.2.2	Creator, name, version, filename, dependencies, distribution licence, SHA-512 hash of the deployable file, and whether it is executable, an archive and structured.
Additional fields Sections 5.2.3 and 5.2.4	Required when they exist: the SBOM URI, other identifiers such as a package URL (purl) or CPE, the original licence, the source code URI and the URI of the deployable form.

For CycloneDX the checker uses the field mapping in section 8.2 of TR-03183-2: for example the SBOM creator in metadata.manufacturer, the hash in an external reference of type distribution, and the filename and the three properties as bsi:component:filename, bsi:component:executable, bsi:component:archive and bsi:component:structured. Components marked "scope": "excluded" (not shipped, such as development tools) are not counted. SPDX 2 has no mapping in the guideline, so it is checked at the CRA level and against the closest SPDX 2 fields; SPDX 3 support is basic for now.

CRA and TR-03183-2: how they relate

The CRA text sets the minimum: Annex I, Part II, point 1 asks manufacturers to identify and document the components of the product, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. The Regulation lets the Commission specify the format and elements of the SBOM later through implementing acts (Article 13(24)).

TR-03183-2 is a technical guideline from the BSI. According to the BSI, it is meant to give manufacturers an early view of the kind of requirements the CRA will bring. It is not part of the Regulation, and it goes further than the CRA text: it asks for every component, not just the top level, and for fields such as a SHA-512 hash and licences. Our reading: meeting the CRA minimum is the obligation; the TR-03183-2 fields are a good target while the Commission has not specified the elements, and the more complete the SBOM, the more useful it is when a vulnerability is disclosed.

For a mobile app, most gaps are in the TR-03183-2 rows. SBOMs generated from lockfiles usually have names, versions, package URLs and the dependency graph, but no hashes of the shipped files, no licences and no component creators. Our free scanner and the Shipmark GitHub Action produce CycloneDX 1.6 with names, versions, package URLs and the app's direct dependencies; they do not add licences or hashes yet, so expect those rows to show gaps. The guides for Flutter and React Native explain how to produce a fuller SBOM for each platform.

About the example SBOM

The example is a fictional app, "Example Shop" 4.2.0, with three fictional components. Every name, address, URL and hash in it is a placeholder. It shows one way to fill every field the checker looks at in CycloneDX 1.6, and you can use it as a template.

Maintaining apps for clients? Shipmark keeps an SBOM per release, daily vulnerability checks and the support period for every client app in one place. Founding agencies use it free until 1 April 2027.

Join the free beta

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), consolidated text, EUR-Lex: Annex I, Part II, point 1 and Article 13(24).
BSI Technical Guideline TR-03183, Part 2: Software Bill of Materials (SBOM): version 2.1.0 of 20 August 2025, sections 4, 5.2, 6.1 and 8.2. The guideline says the most recent version must be used; check the BSI site for a newer one.

The checker runs in your browser and stores nothing. It checks whether fields are present and well formed; it is not a full schema validation, a conformity assessment or legal advice. Related: SBOM and vulnerability scanner · Flutter SBOM guide · React Native SBOM guide · Support period calculator.