The CRA Checklist: A Supply Chain Perspective

I wrote this blog post while working at a small scale cybersecurity company, as an attempt to communicate several important points about CRA compliance in regards to the supply-chain aspect of software development. During my time at the company I took an interest in software supply chain security, since it often was a lesser focus in secure development. It was also very important to us during high-assurance software development. I am by no means an expert in the area, but found that there exists a lot of open-source tools to cover major aspects of securing the software supply chain, a few of which are jotted down in this article. Personally I believe that very few companies realize what is expected in terms of product delivery when the CRA enters into effect. This article should highlight some of the main necessities. For those of you who are familiar with the CRA, it is important to know that not all actors will be affected by it, the exact specifications can be found in the CRA itself. This is not legal advice.

The CRA Checklist: Mastering Security Compliance for your Software Supply Chain

In the evolving landscape of digital technology, the Cyber Resilience Act (CRA) marks a significant stride in fortifying software supply chain security (SSCS). The EU will require due diligence from organizations producing software (where applicable) to properly adopt and align with the CRA's mandates. The act is still subject to formal approval by the European Parliament, but once enacted, distributors and actors will have an initial grace period of 36 months to adapt to the new regulations. In this article, we'll explore some practical ways to adjust your organization's processes to align with some of the new requirements from a supply-chain perspective.

The SBOM

The adoption and implementation of the Software Bill of Materials (SBOM) in regular software-development is a key component of CRA alignment. An SBOM is essentially a structured inventory that lists all components of software, including open-source libraries and dependencies, in a machine- readable format. SBOM adoption has gained a lot of traction recently, which stems from the need for greater visibility into software components, aiding in identifying vulnerabilities and managing security risks more effectively across the supply chain.

CRA specifies the SBOM as a direct requirement for vendors placing software products on the market:

Manufacturers of the products with digital elements shall: (1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.

Gaining an understanding of your software's composition is crucial. However, it's also important to recognize a suitable scope when applying these measures. Your SBOM should ideally cover components throughout the entire Software Development Life Cycle (SDLC), covering stages like implementation, testing, and software build, not only the final production software. CRA implicitly requires conducting detailed vulnerability analysis, keeping track of vulnerabilities, and rapidly disclosing them. To get the most value from these processes, it's beneficial to perform continuous, automated vulnerability analysis of your SBOM. This regular analysis helps in identifying any new risk. Using potentially vulnerable components in your software is a common threat vector since the components typically run with equal privileges as the application itself. Using vulnerable or malicious components is considered one of the most common security risks, and often ranks high in OWASPs TOP Ten Application Security Risks.

Furthermore, in line with the CRA's guidelines, it's essential for your organization to develop and implement a policy for vulnerability disclosure. This policy should outline how vulnerabilities are reported, managed, and communicated both internally and externally.

Both the SBOM and complete information and specifications of the vulnerability handling process are to be included as technical documentation when you place a product with digital elements on the market, as stipulated in the proposal:

"...When placing a product with digital elements on the market, the manufacturer shall include a cybersecurity risk assessment in the technical documentation as set out in Article 23 and Annex V"

" ... complete information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy..."

Key open-source technologies

Incorporating SBOM management and analysis within your SDLC can be achieved cost-effectively, by leveraging the power of open-source projects. Organizations like OWASP, which pioneered the CycloneDX SBOM format, are at the forefront of this initiative. They drive the creation of more secure software by supporting significant open-source projects that enhance cyber security across the SDLC. CycloneDX is one of several SBOM formats actively used, and you can choose which format suits your organization best. In this article, we’ll focus on tools using the CycloneDX SBOM format.

As for generating SBOMS when developing containerized applications, Anchore's Syft can be employed to create SBOMs through package discovery in container images. Syft is a command-line interface (CLI) tool, that supports all primary ecosystems and integrates seamlessly into automation tools, pipelines, and workflows. Syft parses the entire dependency tree of a project, meaning you not only generate an SBOM with top-level dependencies, but all transitive dependencies as well. By Having indexed all the components of your application you can now leverage this inventory against other automated tools, for continuous, automated vulnerability analysis.

Syft CLI showcase

OWASP's Dependency Track can be used for continuous monitoring and management of these SBOMs. Dependency Track offers the convenience of on-prem deployment, allowing for in-house management and analysis of your SBOMs. The platform routinely updates its vulnerability data from key advisory sources such as the National Vulnerability Database (NVD) and GitHub Advisory Database, letting you know of any newly discovered vulnerabilities. You can easily set up automated workflows for consuming generated SBOMs by utilizing the built-in REST API or otherwise manually import them via the GUI. Since Dependency Track keeps track of previous SBOMs you’ve analyzed, it enables you to get a broad insight into existing vulnerabilities across your range of released software. Dependency track also allows you to define certain policies for your component inventory, where you can specify and measure compliance with your policies regarding security, operations, and licenses. It should be noted that Dependency Track currently only supports the CycloneDX format when consuming SBOMs.

Dependency track palttform overview

These tools are by no means the only way to continuously monitor your software for potential vulnerabilities, but since the CRA stipulates that you should handle vulnerabilities for released software for a duration of the expected product lifetime or a period of five years (whichever is shorter). You must make sure that the processes you implement are sustainable and stable.

As the enforcement of CRA approaches, it's important for affected organizations to begin preparing. We've outlined the main talking points of this article and generated a simple checklist of things to enforce in your organization:

Act sooner rather than later.

□ Implement and Regularly Update Your Software Bill of Materials (SBOM)

Ensure you have a comprehensive SBOM that lists all components of your software, including libraries and dependencies, in a machine-readable format. This SBOM should cover components throughout the entire Software Development Life Cycle (SDLC).

□ Create an automated, sustainable vulnerability analysis process for your component inventory

Conduct continuous, automated vulnerability analysis of your applications and act upon the discoveries made. Make sure that the you have a well- defined process for handling vulnerabilities.

□ Develop a Vulnerability Disclosure Policy

Create and implement a policy outlining how vulnerabilities are reported, managed, and communicated both internally and externally.

□ Include Required Documentation When Placing a Product on the Market

Ensure the technical documentation for your product includes complete information on the vulnerability handling processes you've established. This must also include the SBOM and the coordinated vulnerability disclosure policy, as required by the CRA. This is by no means a summation of the contents of the CRA, but rather some key points to keep in mind when working towards CRA-compliance.

The act is a great addition to the strengthening of European cyber resilience, and it outlines many areas where software manufacturers will need to invest to ensure their products meet the new regulatory standards. The journey towards CRA compliance is an opportunity for organizations to review and strengthen their cybersecurity practices, ultimately benefiting their customers, stakeholders, and the broader digital community.