Software Bill of Materials (SBOM): The Foundation of CRA Compliance

Contemporary software applications usually do not require code to be completely developed in-house. Applications, connectivity devices, industrial software, and embedded systems commonly employ open source packages, third-party libraries, and elements of operating systems and other commercial products. The networked nature of this software supply chain exposes companies to vulnerabilities they must address.

The EU’s Cyber Resilience Act (CRA) increases the burden on manufacturers when it comes to recognizing vulnerabilities and ensuring cybersecurity of the product through its entire lifecycle. According to the CRA, manufacturers will be required to describe the software components and their dependencies, including through machine-readable SBOM for at least the top-level dependencies.

If the manufacturer itself is not have coding practices, then still the weakness in the code provided by the third party will affect the entire product. It will not be easy for the security team to determine the affected products and the rate at which the issue needs to be sorted out.

This is why the CRA makes the connection between cybersecurity risk management and product lifecycles. The manufacturers have to perform risk assessment, vulnerability management, and technical documentation.

This is where an SBOM becomes useful. It provides a structured inventory of the software components that make up a product.

An SBOM is a machine-readable record of the software components, libraries, packages, versions, and dependencies used within a software product.

A practical SBOM can help security and engineering teams answer questions such as:

For CRA compliance, the SBOM also supports the technical documentation and vulnerability-handling processes required by the regulation.

The two commonly used SBOM formats include SPDX and CycloneDX.

The appropriate format depends on the product architecture, development environment, tooling, and compliance requirements.

Open source software is capable of bringing more speed into the development process; but, every dependency represents one more thing that must be kept an eye on. Vulnerabilities occur in old software, old packages become harder to manage, and transitive dependencies bring components that were not chosen by the developers.

Therefore, third-party library management is not only about listing packages. It requires tracking of the versions, monitoring of vulnerabilities, licenses if required, and usage within the final build.

In case of manufacturers working under the CRA, due diligence regarding third-party components becomes a part of cybersecurity responsibilities.

SBOMs are typically created in the software development/build environment. An analysis of source code, repositories, package manifests, dependencies, container images, binaries, and build outputs may show the existence of software components.

Typically, the process involves the following steps:

The result should correspond to the actual software version being delivered.

A Software Bill of Materials must be considered a living security document. The reason is that the software itself is constantly evolving because of updates and upgrades to dependencies, features, and the operating system.

The automation of SBOMs in CI/CD pipelines allows organizations to create an updated inventory in each release. These SBOMs in version control will help manage vulnerabilities and incidents for the entire life cycle of the product.

This is especially important because CRA vulnerability-handling obligations continue after a product reaches the market.

The SBOM process can be integrated directly into the CI/CD pipeline so that software composition is checked as part of the development and release process. Code enters the build environment, where direct and indirect dependencies can be identified through dependency scanning. The SBOM is then generated and validated against the build output before vulnerability scanning and risk assessment take place.

After the release is authorised, the SBOM related to it can be stored along with the version number. The monitoring process will allow detection of any changes in dependencies and discovered vulnerabilities continuously during the life cycle of the product. This technique will provide the SBOM for the released software version.

Embedded devices pose extra difficulties. An embedded device might include firmware, bootloader code, operating system software components, middleware, driver software, libraries from third parties, and software that is device-specific.

Thus, an effective SBOM for an embedded product needs to include software that is deployed on the actual device and their versions. This will give the engineering team a way to identify vulnerable components.

In case of connected industrial and IoT devices, this can assist in planning maintenance and updates.

When it comes to the embedded product, the SBOM should reflect the software components which are really used on each of these levels. These software components may include application software, middleware, RTOS/operating system software components, device drivers, bootloader, firmware libraries, and all other necessary dependencies.

Hardware itself is not a software component but is the target environment where software will be installed. By linking an SBOM with a particular product/hardware version, engineers can know what software components were used for a certain configuration of the device.

This structure is particularly useful for industrial and IoT products where a vulnerability in an operating system component, driver, middleware package, or firmware dependency may affect the security of the complete device.

Consider an industrial controller containing several open-source libraries. A critical vulnerability is later discovered in one library.

Without the SBOM, the manufacturer needs to manually check the source repository and the multiple versions of the product. With an up-to-date SBOM, the security team will be able to identify the component, understand the versions of the products that use the component, calculate the exposure and plan their remediation efforts accordingly.

SBOM thus bridges the gap between software development, vulnerability management, and compliance requirements.

Ascenten enables organizations to implement and manage the process of SBOM from component identification and dependency mapping to SBOM creation, verification, and updates throughout the software product lifecycle.

In the case of CRA compliance preparation, implementing SBOM procedures will ensure visibility of the software supply chain and allow easier vulnerability management.