The European Parliament approved the EU's Cyber Resilience Act (CRA) on March 12th.

‍

CRA uses the Software Bill of Materials (SBOM) to describe, record, and monitor product security. Therefore, a formal document outlining CRA compliance requirements and specifically describing all SBOM-specific requirements is expected soon.

‍

However, in anticipation of the adoption of the CRA, Germany's Federal Office of Information Security (BSI) has been working to clarify SBOM requirements. The Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products (Part 2: Software Bill of Materials (SBOM)) has been published since November 28th.

‍

TR-03183: SBOM Requirements for CRA

The 17-page requirements document is published here.

Its key requirements can be summed up as follows:

1. The compilation of SBOM is mandatory to meet CRA.
2. An SBOM MUST contain certain minimum information but MAY be expanded and detailed as desired.
3. A new, separate SBOM MUST be generated for each software version.
4. A new version of the SBOM for a given software version MUST be generated if and only if more information on the included software components is provided or errors in the SBOM data are corrected.
5. It is NOT required to include vulnerability information in the SBOM.
6. SBOM must be in one of the two specifications: CycloneDX version 1.4 or higher OR SPDX version 2.3 or higher.
7. The SBOM MUST be created as part of the build process or its equivalent where the build process does not exist.
8. The creator of the SBOM MUST be identified by email or fallback to a URL
9. The date and time of the SBOM data collection MUST be included.
10. For each component included in the SBOM —
11. The component name, version (preferred SemVer or Calendar), and list of components on which this component depends MUST be included.
12. The component license MUST be included for each license and must be identified with their SPDX identifier.
13. If the license is not found in SPDX, ScanCode LicenseDB AboutCode must be used. These must be identified with LicenseRef-scancode- .
14. If neither fails to find the license, then LicenRef-<unique-inventorying-entity> it must be used to meet SPDX license expression criteria.
15. The component MUST include a hash value as SHA-256.
16. The SBOM MAY include an SBOM-URI.
17. Each SBOM component MAY include the source Code URI, the URI of the component's executable form, the source code's hash value as SHA-256 (exact method left undetermined), and other unique identifiers of the component, such as CPE or PURL.
18. The guidance also recommends CSAF (with a VEX profile) as the format for distributing vulnerabilities separately from the SBOM.

‍

Technical Guideline TR-03183 is an important step forward toward clarifying the exact steps software builders need to take to meet CRA compliance. However, it still needs to be answered.

‍

Without CPE or PURL as an identification requirement, creating vulnerability reports from the SBOM is prone to errors.

‍

The guideline uses ‘scope of delivery’ to define the depth at which the transitive component must be enumerated. However, it does not include any guidance on the acceptable ‘scope of delivery.’

‍

The guidelines explicitly acknowledge that the method for computing SHA-256 of source code still needs to be completed.

‍

The guidelines call out including all transitive components recursively but do not explicitly require specifying relationships among those components. In our experience, missing/skipping relationships is a common problem with SBOM generators and adversely affects using SBOM for vulnerability management.

‍