If you are an open source software maintainer, or a developer utilizing open source software at work, you may have heard mention of the Cyber Resilience Act in the last couple of years. It goes into effect in 2027 and will require changes to your security posture around consumption of open source, so what exactly is it and what do you need to do?
The Cyber Resilience Act, or CRA, is a legal framework that will apply to software or hardware products within the European Union, mandating that the makers of these products think about cybersecurity and cyber resilience through every step of that product’s life.
From a practical perspective, this means things like separating feature updates from security updates, defaulting to automatic updates for security patches, performing regularly-scheduled security assessments, and implementing standardized vulnerability disclosure and incident reporting practices.
The CRA came about as a result of a series of increasingly destructive security incidents affecting large numbers of users. We are an increasingly connected society, with a rapidly growing number of products and services we rely on daily being a part of the “Internet of Things.” This increases our attack surface as a society, risking not just individual harm but broad economic harm.
Instead of placing the responsibility on users (who may not be particularly tech savvy) to decrease their individual attack surface by manually enabling automatic updates or requiring that they be knowledgeable enough to purchase less vulnerable products, the CRA aims to shift the responsibility for security squarely to the manufacturers.
The EU Cyber Resilience Act provisions will begin to apply in stages. Most organizations placing products on the EU market will need to comply by 2027, giving companies some time to prepare. However, given the complexity of aligning your software supply chain and security practices with the CRA’s requirements, it’s important to start evaluating your open source dependencies and product security processes now.
The Cyber Resilience Act includes specific provisions for open source software. As an individual contributor to a free and open source project, you have no obligations or responsibilities under the CRA; life continues as normal. It only applies to Products with Digital Elements, defined within the text of the law as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.”
For example, Kubernetes on its own is not a Product with Digital Elements. However, once you are consuming Kubernetes or any other open source project as part of a product you intend to release within the EU, you have obligations. It is entirely up to you to investigate the security posture of that project, stay on top of vulnerabilities, and react to them. One of the first things you should investigate when deciding whether or not to consume a particular open source project is the health of that project.
Under the Cyber Resilience Act, the obligation is on you as a business to ensure that your product is not vulnerable to a security incident, so it’s important that you ensure you aren’t reliant on an unhealthy piece of open source software. There are a lot of metrics that can be used to determine project health, but a few are always important to consider.
Choose a project with multiple active maintainers. If at all possible, you should avoid relying on projects with only one or two active maintainers, or projects where just one or two people are making more than 50% of contributions.
Open source contributors have no legal or social obligation to work on a project if they do not want to; they can and will leave, and so you need to look at each project and ask yourself whether or not issues will still be resolved should the largest contributors leave unexpectedly.
It may not be a requirement for all projects to release updates on a regular basis. Some tools simply don’t need feature releases three times per year. However, a healthy project should be responding to vulnerabilities in a timely manner. Look at their history of patch releases, not just minor or major feature releases.
Look at a project’s issue tracking and pull requests. When someone opens something new, how long does it take for a maintainer to respond? How long does it take for an issue to be resolved, or for a PR to be merged? How quickly do they respond to disclosed vulnerabilities? Consider your organization’s risk tolerance carefully here.
Maintainers are not obligated to respond or resolve issues on your timescale, or even at all. A healthy project you can rely on will ideally be responding to new issues and PRs within just a couple of days, in most cases.
Open source software has clear benefits over proprietary software when the project is healthy and properly maintained. However, it can be overwhelming to stay on top of security releases and vulnerability mitigation when relying on multiple large open source tools, especially when you’re also working to maintain compliance with the Cyber Resilience Act.
Instead of playing a never ending game of whack-a-mole trying to remediate vulnerabilities in your critical infrastructure, start by building on top of minimal, automatically updated images with unnecessary components stripped out and the majority of CVEs already addressed for you. Minimus images are a smart alternative to public images you have to clean up and maintain yourself.
Minimus provides secure, production-ready container images that are minimal by design and continuously patched, giving you a stronger foundation without the maintenance burden. If you're ready to simplify your open source security strategy and prepare your stack for the CRA, get started with Minimus today.
