The Cyber Resilience Act (CRA) and the Management of Open Source

Open source is everywhere: Hardly any product today can do without digital components, from electric toothbrushes and baby monitors to smartwatches. Less obvious to many users is the security risk that such products pose for the end users.

The new European Cyber Resilience Act (CRA) aims to ensure that consumers receive secure products. The regulation was announced in the EU Cybersecurity Strategy 2020 and complements other legislation in this area, in particular the NIS2 framework (second EU directive on network and information security). The CRA agreement was formally adopted by the European Parliament in March 2024.

The CRA covers a wide range of requirements for “products with digital elements”. These are all the software and hardware products as well as “remote” data processing solutions without which an intended function of the respective product with digital elements could not be performed. The requirements include, among other things:

• Cybersecurity is considered in the planning, design, development, production, delivery and maintenance phases.
• All cyber security risks are documented.
• Manufacturers must actively report exploited vulnerabilities and incidents.
• After the sale of a product, manufacturers must ensure that any vulnerabilities are effectively eliminated during the expected lifetime of the product or for a period of five years.
• Clear and understandable instructions for the use of products with digital elements.

With the Cyber Resilience Act (CRA), the European Union has created regulation for the topics of cyber security, ICT risks and digital operational resilience. The central requirement is:

All components of the software must be continuously checked for security vulnerabilities!

Providers of commercial products must fulfill the obligations of the regulation. Open source developers have been excluded from the scope of the regulation. The above obligations only have to be fulfilled if open source is used commercially as part of a “product with digital elements”

Example

A company called “Amusing Micro Devices Ltd.” installs chips as components of its product. The company must be able to rely on these being designed securely and requires security updates from the supplier “Bizarre Broadband Ltd.” for a certain period of time to ensure security along the supply chain. According to the CRA, Bizarre Broadband Ltd. must prove that it has complied with EU-harmonized cyber security standards during development and production. This is documented via a so-called software bill of materials (SBOM). The supplier must also document any vulnerabilities of which it has become aware. Before placing the chip on the market, the supplier must carry out a conformity assessment procedure, only then may the CE marking be affixed. Amusing Micro Devices Ltd. must also do all this for its part of the supply chain. Both companies must also provide updates and fulfill reporting and information obligations after the chip and product have been placed on the market; Amusing Micro devices Ltd. must ensure that this is also guaranteed for all suppliers with suitable contracts.

The SBOM: software bill of materials

The commercial components of an SBOM are usually easy to determine: Using the list of suppliers, the commercial components are quickly found. This is more difficult with the open source components: “Free and open source software is software whose source code is openly shared and whose license provides all the rights necessary to make it freely accessible, usable, modifiable and redistributable.”(Point No. 18., Position of the European Parliament of March 12, 2024)

With open source in particular, however, there is a significant risk of security vulnerabilities, especially in projects that do not have an active community or are only maintained by individual maintainers.

The German federal office for information security (BSI) has already drawn up a technical guideline with the minimum specifications for an SBOM.

Today, there is a large number of commercial and free tools for creating SBOMs. Some promise to create an SBOM in just a few minutes – however, then usually only the main components and dependencies in a repository are read out. The problem here is that this SBOM is usually neither complete nor correct. In our experience, there is no tool that can automatically perform all the activities required to create a correct, detailed and reliable SBOM for any software project. This requires an “open source auditor” who validates, researches and, if necessary, supplements the indications found in tools. Open source components are often hidden within a larger component, or developers have only copied individual fragments from another open source project. This can be indicated by copyright notices, e-mail addresses or URLs in the code. Some markings in open source projects are also just obviously wrong, especially in Maven or Github.

Creating an SBOM is not easy. The following graphic shows a comparison between the number of open source components known by the development team (gray) and the number of components that were actually found after an extensive scan (red):

Due to the increasing use of AI in software development, a further rapid increase in the number of open source fragments used is predicted.

Once a complete SBOM has been created, it can easily be automatically checked for new known security vulnerabilities. However, changes to the software components require an updated SBOM from time to time.

The software supply chain

A complete SBOM covers all components along the entire software supply chain. Not only the self-compiled software must be checked, but also all elements delivered by suppliers and components from their suppliers. As software is usually delivered in compiled form and cannot be viewed, subcontractors and suppliers are also obliged to provide a meaningful SBOM. This must therefore be demanded by companies.

Conclusion

A meaningful and robust software bill of materials is an elementary building block for complying with the Cyber Resilience Act (CRA). With it, all components of the software can be continuously checked for security gaps! Bitsea is happy to support you in the development of the same, as well as all other activities for the management of open source.