What the Cyber Resilience Act Requires of an SBOM
The Cyber Resilience Act is Regulation (EU) 2024/2847 and has been in force since 10 December 2024 (EUR-Lex, Regulation (EU) 2024/2847). Its core obligations - secure development, conformity assessment, CE marking - apply only from 11 December 2027 (European Commission). The SBOM is part of these secure-development requirements: manufacturers must identify and document the components contained in a product with digital elements, among other things by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies of the product (Regulation (EU) 2024/2847, Annex I, Part II). Deeply nested sub-dependencies are not legally mandatory, though capturing them remains a sensible next step.
The distinction of what the SBOM is not matters: the CRA does not require the bill to be published. It is part of the technical documentation and is provided to market surveillance authorities on request (European Commission). At the same time it is not a one-off document but must be kept up to date for as long as a product is supported. Germany's Federal Office for Information Security notes that the CRA obligations apply to all products with digital elements on the EU market - including legacy products already placed on the market (BSI). For website and web-app operators this means it is not only about new developments but about the entire supported installed base.
Unlike a public feature list, the software bill of materials goes into the technical documentation and is shown only on request from authorities. Its value lies in traceability: as soon as an embedded library appears in a catalogue of actively exploited vulnerabilities, a current SBOM shows in minutes whether and where your own product is affected - instead of searching whole codebases by hand.
What an SBOM Contains: Component, Version, purl, Hash and Licence
An SBOM is more than a list of package names. The US agency NTIA has defined the minimum elements of a software bill of materials, which serve as an international reference: for each component the supplier, the component name, the version, unique identifiers such as Package URL (purl), CPE or SWID, the dependency relationship, as well as details of the SBOM author and a timestamp of creation (NTIA, Minimum Elements for a Software Bill of Materials). The common formats additionally capture cryptographic hashes such as SHA-256 for integrity checks and the licence per component - details that matter for security and legal reviews alike.
The unique, machine-readable name of the building block - such as the npm package name or the PHP library. It anchors every line of the bill.
The exact version. Without it there is no way to decide whether a reported flaw affects the version in use (NTIA).
The universal identifier that tools understand across ecosystems - for example pkg:npm/jquery@3.6.0. purl is the preferred identifier for matching against vulnerability catalogues (OWASP CycloneDX).
The cryptographic fingerprint of the component. It proves that the file in use matches the documented one and was not swapped unnoticed.
The licence per component - for legal review and for the question under which terms a building block may be reused.
Which component embeds which other. The CRA requires at least the top level; the relationships make impact traceable later (Regulation (EU) 2024/2847).
The Package URL - purl for short - is the link between the bill and the security world. A purl like pkg:npm/react-dom@18.3.1 names ecosystem, package and version in a single, standardised string. This very identifier allows an SBOM to be matched automatically against public vulnerability catalogues: if a purl appears in such a catalogue, the affected component is immediately found in your own bill. purl is regarded as the more precise identifier for software packages in both common formats (OWASP CycloneDX).
CycloneDX or SPDX: the Two Common SBOM Formats
The CRA does not prescribe a single format but requires a commonly used, machine-readable one (Regulation (EU) 2024/2847). In practice two open standards dominate: CycloneDX, developed by the OWASP community with a strong focus on security use cases, and SPDX, internationally standardised as ISO/IEC 5962:2021 and historically stronger on licence compliance. Both are machine-readable, both support purl - the choice mainly depends on your own toolchain.
| Attribute | CycloneDX | SPDX |
|---|---|---|
| Origin | OWASP community | Linux Foundation (SPDX project) |
| Standardisation | Ecma International, ECMA-424 | ISO/IEC 5962:2021 |
| Current version | 1.7 (October 2025) | 3.0 (April 2024) |
| Data formats | JSON, XML, Protocol Buffers | Tag-Value, JSON, RDF, YAML |
| Traditional strength | Security, VEX, supply chain | Licence compliance, provenance |
| Identifiers | purl, CPE | purl, CPE |
SPDX was published in September 2021 as ISO/IEC 5962:2021, becoming the internationally recognised standard for software bills of materials, licence compliance and other supply-chain artifacts (Linux Foundation). The current release SPDX 3.0 appeared in April 2024 and expands the use cases considerably (Linux Foundation). CycloneDX is an Ecma International standard as ECMA-424; version 1.7 was published in October 2025 and added, among other things, enhanced transparency for cryptographic building blocks (OWASP CycloneDX). For CRA conformity the key point is: both satisfy the format requirement of Annex I - so you do not have to choose between standard and compliance, only the format that fits your tools.
An SBOM is at its core a list of ingredients for software: it states what a product is made of - and is therefore the basis for making risks visible across the entire supply chain at all.
— Paraphrased from NTIA, Minimum Elements for a Software Bill of Materials
Why Websites and Web Apps Need an SBOM
The idea that a website consists mainly of your own code is outdated. 97 percent of all codebases examined contain open source, and over 70 percent of a typical application is made up of open-source building blocks - on average 981 open-source components per application (Black Duck OSSRA 2025). The same holds for websites: WordPress plugins, npm packages in the build, PHP libraries via Composer, embedded JavaScript libraries. Each of these is a component that belongs in the bill - and each can bring a vulnerability.
86 percent of commercial codebases contain at least one vulnerable open-source component (Black Duck OSSRA 2025). At the same time the number of open-source files in an average application has tripled - from over 5,300 in 2020 to over 16,000 in 2024 (Black Duck OSSRA 2025). Without a systematic inventory this amount of third-party code is hard to oversee, and that is exactly where the practical value of an SBOM lies.
The supply chain is also an active attack vector. In the ENISA Threat Landscape 2025, classic software supply-chain attacks are among the ten most important threat categories and made up roughly 10.6 percent of the incidents analysed (ENISA). ENISA's 2021 analysis already showed that attackers focused on suppliers' code in about 66 percent of the supply-chain incidents examined (ENISA). For websites the concrete pattern is a secretly altered third-party script - the classic Magecart scenario. Anyone who knows their embedded scripts and monitors their fingerprint detects such manipulation earlier; how this succeeds continuously is described in the article on monitoring Subresource Integrity. The SBOM provides the inventory that is checked against.
Capturing the Software Inventory Systematically
A reliable SBOM is not built from memory but from the sources that already describe the software inventory. For websites and web apps these are above all the manifest files of the ecosystems in use and the embedded third-party resources. The following flow leads from the first capture to a machine-readable bill that meets the CRA format requirement.
- Determine the sources -
package.jsonand lockfile for npm,composer.jsonfor PHP, the CMS plugin and theme list, and all third-party resources embedded via a CDN or script tag - Record name and version per building block - the exact version is crucial to judge exposure to reported flaws later (NTIA)
- Add the Package URL (purl) and hash - the purl as identifier for automated matching, the SHA-256 hash as an integrity proof
- Capture the licence per component - for legal review and reusability
- Set the dependency depth - at least the top-level dependencies, as the CRA requires (Regulation (EU) 2024/2847)
- Store in CycloneDX or SPDX and add to the technical documentation - so the bill is machine-readable and can be provided on request
The CRA initially requires only the top-level dependencies - the building blocks you embed directly, not every deeply nested sub-dependency. That lowers the entry hurdle considerably: start with the top level, keep it cleanly up to date and extend the depth later. A maintained top-level SBOM is, in practice, superior to an incomplete, outdated full inventory.
Keeping an SBOM Current - the Real Effort
The hard part is not creating the SBOM but keeping it current. An SBOM ages with every deploy, every npm update, every plugin change and every swapped library. The CRA explicitly does not require a snapshot but a continuously maintained bill across the product's supported lifecycle (European Commission). Particularly tricky are components that have reached the end of their support (end-of-life): they no longer receive security updates but keep appearing in the product - becoming a preferred attack surface. An SBOM that tracks the version state makes such outdated building blocks visible in the first place.
Keeping it current links the SBOM directly to the reporting obligations. If a component listed in the bill is actively exploited, the tight CRA reporting deadlines from September 2026 kick in - the 24-hour early warning, the 72-hour full notification and the final report, as explained in detail in the article on the CRA vulnerability reporting obligation from September 2026. For many operators this overlaps with the NIS2 Directive, which has a very similar 24-hour early warning; the practical consequences are summarised in the article on NIS2 incident reporting for website operators. In both cases the current SBOM is the basis for judging exposure quickly.
A maintained bill also pays off during technical migrations. Anyone who inventories the cryptographic building blocks of their systems can steer the transition to quantum-safe methods deliberately - a topic taken up in the article on monitoring post-quantum TLS with ML-KEM in the browser. And for email delivery the article on MTA-STS and TLS-RPT for encrypted mail shows how to secure transport-encrypted channels - such configurations, too, are part of the picture of a maintained, traceable technology inventory.
The XICTRAQ CRA Component Cockpit
This is exactly where the CRA component cockpit comes in. It inventories the components used on a website along with their version state, heuristically detects outdated stacks and flags approaching CRA deadlines in good time. The abstract duty to evidence a software inventory becomes a concrete, repeatable workflow - from the first inventory to ongoing maintenance.
The building blocks in use are captured and tracked with their version state - the data basis from which a bill in a common format is produced.
A tech-stack heuristic marks building blocks that are nearing or have passed their support end - exactly the candidates that need an update.
Approaching CRA dates are recalled in stages so that preparation does not start just before full application on 11 December 2027 (European Commission).
Security-relevant deviations run into the same notification workflow as the rest of the monitoring - via email, Slack, Discord or Telegram, with escalation.
The cockpit does not stand alone but complements the rest of the attack-surface monitoring. Together with the security scan for headers and TLS, the script-integrity check and certificate observation, a picture emerges of what is actually delivered - not just of the intent. Anyone who wants to know which building blocks their digital product contains today and where the next deadline waits will find the right tier in the pricing overview. A software bill of materials is, in the end, not a paper document but a living inventory - and a tool that maintains that inventory takes much of the weight off CRA preparation.
Getting Started with the Bill of Materials Now
The CRA's SBOM obligation is not a distant edge topic but a plannable task with clear value beyond mere compliance. Full application on 11 December 2027 is fixed (European Commission), and the path there runs through three sober steps: capture the software inventory from the existing sources, bring it into a machine-readable format such as CycloneDX or SPDX, and then - the real effort - keep it permanently current. Each of these steps incidentally improves your own security posture, because it reveals what a product is really made of.
The common denominator is oversight. A current component inventory shortens the time in which the question "Are we affected?" is answered for a newly reported flaw - from days of manual work to minutes of matching. Anyone who starts inventorying their stock today will have a maintained bill and an established process by 2027 instead of a last-minute scramble. A live demo shows what the component inventory looks like in everyday use; and getting started with systematic inventory monitoring works via free registration.
This article draws on data and documents from: Regulation (EU) 2024/2847 (Cyber Resilience Act, EUR-Lex - entry into force 10 Dec 2024, SBOM requirement Annex I Part II, commonly used machine-readable format, top-level dependencies), European Commission (digital-strategy.ec.europa.eu - full application 11 Dec 2027, SBOM as part of the technical documentation, keeping it up to date, sanctions framework), Germany's Federal Office for Information Security (BSI, Cyber Resilience Act - applicability to all products with digital elements including legacy products), NTIA (The Minimum Elements For a Software Bill of Materials - supplier, name, version, unique identifiers CPE/SWID/purl, dependency relationship, author and timestamp), OWASP CycloneDX (specification, purl as preferred identifier, Ecma standard ECMA-424, version 1.7 October 2025), Linux Foundation SPDX (ISO/IEC 5962:2021 since September 2021, SPDX 3.0 April 2024), Black Duck Open Source Security and Risk Analysis Report 2025 (open-source share in codebases, vulnerable components, file growth), ENISA Threat Landscape 2025 and Threat Landscape for Supply Chain Attacks 2021 (share and characteristics of supply-chain attacks). The legal remarks are not legal advice.