A safety defect in a component - and it is immediately clear which products are affected. This is part of everyday life for manufacturers in mechanical engineering. The bill of materials makes it possible.
It lists all the individual parts of a product and thus creates full transparency about the composition.
In software development, however, this transparency is often lacking. Manufacturers and operators face similar challenges: Security vulnerabilities regularly occur here too - in frameworks, libraries or third-party components.
The solution? A software bill of materials (SBOM). It transfers the proven principle of the bill of materials to software products and makes it possible to identify safety risks at an early stage and take targeted action.
Why a "Software Bill of Materials"
As the previous example shows, the bill of materials has been an integral part of industries such as mechanical engineering for decades. In the IT industry, however, the provision of a "Software Bill of Materials" (SBOM) is not yet very widespread. However, the IT industry faces the same challenge as the mechanical engineering sector. There are also security flaws in the libraries and frameworks used. These security flaws have been published for years, but operators and manufacturers of IT systems often have no transparency about the libraries and frameworks used. This makes it difficult to take targeted countermeasures against security vulnerabilities.
The "Cyber Resilience Act"1 of the EU has set itself the goal of changing this. The "Federal Office for Information Security" has published the technical guideline "BSI TR-03183-2 Software Bill of Materials (SBOM)".2 provided. This guideline defines the framework conditions for a "Software Bill of Materials".
SBOM standards at a glance: CycloneDX &SPDX
What exactly should the "software bill of materials" for my products look like? This question is not only asked by manufacturers of products with digital content, but of course also by the operators of these products. In the past, operators in particular often had the challenge of checking whether their systems were affected when a security vulnerability occurred. This was often not possible directly, but had to rely on the supplier's security management. This is now changing. With the introduction of the "Software Bill of Materials", both parties have transparency with regard to existing software dependencies.
For this reason, the technical guideline BSI-TR-03183-2 now provides for the two formats CycloneDX3 and Software Package Data Exchange (SPDX)4 before. This clearly defines which formats are used. This has two advantages:
- Product operators can specifically request one of the formats from all suppliers.
- Suppliers can concentrate on one format and adapt their processes accordingly.
Why we at doubleSlash rely on CycloneDX
At doubleSlash, we have decided to use the CycloneDX format. There are three main reasons for this:
Reason 1 - Clearly structured format:
In principle, the "Software Bill of Materials" should be machine-readable. This is possible in any case with the selected format. In addition to being machine-readable, it is also human-readable because it is well structured and easy to understand.
Reason 2 - Expandability
When it comes to expandability, two types of expandability come into play. On the one hand, the CycloneDX format offers the option of defining user-defined properties in some places. This makes it possible to store additional information.
On the other hand, the CycloneDX format can be used to create more than just software bills of materials. It can also be used to create "Cryptography Bill of Materials" (CBOM) for cryptographic assets or "Vulnerability Disclosure Records" (VDR). This facilitates the uniform use of a format for different purposes.
Reason 3 - Wide range of tools
There are a large number of applications and tools that can create and process the CycloneDX format. This makes it a good choice. Developers, manufacturers and operators of products with digital content have the option of processing the "Software Bill of Materials" with their tools.
Conclusion: Transparency creates security for all parties involved
The Software Bill of Materials is a significant step towards more Cybersecurity. It creates a new form of transparency across the entire software lifecycle - for everyone involved: developers, manufacturers of digital products and their operators.
If a security gap occurs, it can be quickly and clearly clarified whether and which software is affected.
Developers can already check during development whether the planned or already published release is vulnerable.
Manufacturers, in turn, have the opportunity to inform their customers specifically and proactively about vulnerabilities in components - including specific security advisories.
Operators also benefit: When a vulnerability becomes known, they can immediately check whether their systems are affected and take appropriate measures - even before a patch is available.SBOM thus enables significantly faster and more targeted action in the event of security-relevant incidents.
In short: it brings more responsibility, more transparency - and above all more Security.
