CRA and SBOMs: Shaping a Practical and Unified Framework
Executive Summary
- The Mandate: The EU Cyber Resilience Act (CRA) mandates SBOMs for digital products by December 2027. But it deliberately avoids picking a format, leaving engineering teams in limbo.
- The Bridge: While we wait for harmonized EU standards, Germany’s BSI TR-03183–2 guideline is the most actionable technical blueprint available today. Use it.
- The Reality Check: The format debate is a distraction. The real nightmare is building the pipeline capability to maintain SBOMs as living documents and forcing your third-party vendors to actually comply.
If you ask five DevSecOps engineers how their teams are preparing for the EU Cyber Resilience Act’s (CRA) SBOM mandate, you’ll get five different answers — and a lot of heavy sighing.
The regulation, which entered into force in December 2024, mandates that by December 2027, manufacturers of products with digital elements must produce a Software Bill of Materials (SBOM). The intent is great: force transparency into the software supply chain. But the implementation path the EU has laid out is a mess.
The CRA requires an SBOM in a “commonly used and machine-readable format.” That deliberate ambiguity might look good in a legislative chamber, but it creates a massive headache for the engineering teams who have to start building their CI/CD compliance pipelines today.
What the CRA Actually Requires (Hint: It’s Not a PDF)
The SBOM obligation sits within the vulnerability handling requirements of the CRA (Annex I, Part II). You have to “identify and document vulnerabilities and components,” and keep that documentation at the disposal of market surveillance authorities.
But here is the critical part that many companies are missing: The CRA doesn’t want a snapshot. If your current process is running a scanner right before a major release, generating a static file, and throwing it into a shared drive to check a compliance box, you will fail the CRA requirements. The regulation treats the SBOM as a living document that feeds into an active, continuous vulnerability handling process for the entire support period of the product.
The Format Fight: CycloneDX vs. SPDX
Because the EU didn’t pick a format, we are stuck in a holding pattern waiting for harmonised European standards (expected eventually from CEN/CENELEC). Right now, the industry is split between two heavyweights:
- CycloneDX (ECMA-424 v1.7): Maintained by OWASP, this is built from the ground up for security. It natively integrates with vulnerability management workflows (VEX, VDR).
- SPDX (ISO/IEC 5962 v3.0): Maintained by the Linux Foundation. It has expanded into security, but its DNA is in licensing and provenance tracking. It is incredibly comprehensive, which also means it can be a beast to implement if you only care about security.
My take? Neither is legally “wrong” under the CRA. But from a pure DevSecOps and vulnerability tracking perspective, CycloneDX is usually the path of least resistance for engineering teams to bolt onto existing scanners. SPDX is often the choice for massive enterprises where legal teams need deep, complex licensing trees alongside the security data.
Get Souvick’s stories in your inbox
Join Medium for free to get updates from this writer.
Until the EU officially designates one (or both) as carrying a “presumption of conformity,” manufacturers have to place a bet.
The BSI TR-03183–2 Lifeline
So, what do you actually tell your developers to build today? You look to Germany.
The German Federal Office for Information Security (BSI) didn’t wait for the EU. Their Technical Guideline TR-03183–2 is currently the most detailed, actionable CRA implementation guide on the planet.
It defines the exact formal and technical requirements for SBOM generation, including mandatory data fields. Crucially, it provides a direct mapping for both CycloneDX and SPDX formats, and they even published a CycloneDX taxonomy on GitHub to get you started.
It is technically non-binding at the EU level. But if you want a defensible, practical specification to start writing tickets against right now, the BSI guideline is your best friend.
The Ugly Reality of Supply Chain Compliance
If you are a Product Owner or Security Lead, December 2027 looks like it’s a long way off. It isn’t. The engineering lift required here is brutal, specifically when it comes to the supply chain.
Article 13 requires you to exercise due diligence on third-party components. Let me translate that: if your product embeds a commercial SDK or a proprietary library from a vendor, you need their SBOM to complete your SBOM.
If you have ever tried to force a legacy vendor to hand over a machine-readable SBOM, you know exactly how painful this is. Vendors will fight you. They will claim their code is a “black box” for IP reasons. They will try to email you a locked PDF summary and call it compliance.
You need to start having these fights with your procurement teams and vendors today. Writing the CRA compliance language into vendor contracts takes months, and waiting for them to actually generate the JSON files will take even longer.
Stop Waiting, Start Building
The format debate is ultimately a distraction. Tools like Syft, Trivy, and the CycloneDX CLI are largely format-agnostic at the pipeline level. They can spit out whatever JSON schema you eventually need.
The real challenge isn’t whether you output CycloneDX or SPDX. The challenge is organizational. Can your team generate, maintain, and act on an SBOM continuously, across every product layer, with every single release, while dragging your third-party vendors along for the ride?
That is a massive engineering and cultural shift. The EU might be dragging its feet on the final format standards, but if you wait for them to finish before you start building your pipelines, you are going to miss the 2027 deadline.
