Please don’t make your CRA due diligence a DoS attack!

The EU Cyber Resilience Act (CRA) and other regulations stress the importance of understanding your software supply chain. The CRA makes manufacturers responsible not only for their own code and hardware, but for all the components they integrate to their products. This often includes a large amount of open source software.

When carrying out the required due diligence for all components in a product, there’s a real risk of unintentionally contributing to a denial-of-service attack on the open source maintainers. Let’s work together to make sure it doesn’t happen. The Open Regulatory Compliance working group is starting to work on a best current practice, and we’d like to tell you more about this important project.

Remember the Log4shell vulnerability?

Log4shell was a serious vulnerability in the Apache Log4j open source project. It generated a lot of work within IT organisations, both for customers and manufacturers. The main question was “Are we affected?” Trying to find out which products and systems included this critical piece of software became the priority.

This led to a large amount of queries to upstream vendors and open source projects, often requesting a response to be provided in a specific format and within a strict time frame. In many cases, open source maintainers had no business relationship with the companies and no associated revenue stream to pay for this work. Unsuprisingly this led to a lot of frustration. Let’s not repeat that experience.

Let’s try to come up with a standardised way forward

If you look at the problem more broadly, open source projects can have a large number of downstream manufacturers and users. Each of those, in turn, has a long list of open source libraries, tools, and platforms. This can lead to a massive communication breakdown at scale.

Open source maintainers are under no obligation to spend their valuable - quite often unpaid - time responding to ad hoc requests in various formats. Receiving a large volume of requests from different, and possibly unknown, sources will cause confusion and unnecessary workload. We want maintainers to focus on their code, the project and in many cases, securing their code and development processes.

Join the work to create a best current practice

In ORC, we are looking into this problem. We have started working on a document that will describe the best current practice for due diligence according to the Cyber Resilience Act.

This community-driven project is led by Timo Perälä from Nokia, and contributions are welcome from manufacturers, open source maintainers, tooling vendors, and policy experts.

You can get involved by:

• Participating in discussions via the ORC WG Vulnerability Handling Task Force, which meets every other Thursday at 15:00 CET (see our community calendar)
• Joining asynchronous discussions in the vulnerability handling Slack channel
• Contributing ideas, use cases, or text to the Due Diligence white paper
• Helping define practical, automatable checks that work for both manufacturers and open source projects

In addition, the ORC community is working on Voluntary Security Attestations, which offer open source projects another way to communicate security posture and support manufacturers with their due diligence process.

If interest and activity grow, the working group may spin up dedicated meetings or channels focused solely on due diligence.

If you care about sustainable open source consumption under the CRA, this work needs your input.