7 MIN READ
Mirko Boehm | 14 November 2023
Summary of the panel on the topic at Open Source Summit Europe 2023, Bilbao
The upcoming EU Cyber Resilience Act (CRA) will be a crucial instrument to regulate the security of digital products in the EU market. With the heated debate about the impact of the CRA on the open source ecosystem reaching a new peak, it is important to hear the responses of the different stakeholders affected by the CRA. The open source relevant economic operators referenced in the CRA are primarily distributors, importers and manufacturers. At least for distributors and manufacturers, in the context of open source development, we distinguish between upstream communities who collaboratively develop free and open source software products, and downstream businesses that integrate those building blocks until they reach the consumer. We invited panelists representing a diverse spectrum of these essential operator roles: Greg Kroah-Hartman is a key Linux contributor who maintains the kernel’s stable branch. Cheuk Ting Ho joined us in her role as director at the Python Software Foundation. Laura Seay manages Product Security Supply Chain Operations at Red Hat. Justin Colannino represented GitHub as a major software development platform provider. Phil Robb represented Ericsson as a major European digital product business. Together, this group of industry and community actors from very different perspectives shared how the concerns that have been raised with the CRA affect them. The recording of the panel is available on Youtube. Read on for a summary of the panelists' responses to discover where they agreed or disagreed, with a few outstanding moments highlighted at the end.
How will the CRA improve cybersecurity and where do you expect problems?
Greg Kroah-Hartman, Linux kernel community: Greg explains that the kernel community welcomes the goals of the CRA and especially the requirement to report vulnerabilities to upstream projects. In some cases, manufacturers have been sitting on security fixes for months and years without reporting them. Enforcing the reporting of these issues in a timely manner will help mitigate that situation. However, the requirement to report exploited issues within 24 hours will not work. Sometimes bugs take months to fix. The biggest issue with open source software is that the communities don't dictate use, they provide the source code and downstream users decide how they are going to use it. The Linux kernel is used in keyboards, in satellites, in wind turbines and routers. Since the community does not know the downstream use case, it is an impossible task to decide if an issue is a vulnerability or not. Because of that, the goal of the Linux Kernel security team is to fix as many bugs as possible and swiftly release new versions with them.
Cheuk Ting Ho, Python Software Foundation: The Python Software Foundation is concerned that the CRA draft places the responsibility for vulnerabilities in the wrong hands. Many open source projects are actually maintained by a few individuals that may not be working full time on maintaining the project. The Python ecosystem is already aiming to do the right thing for example by working with OpenSSF, especially Alpha-Omega.
Justin Colannino, GitHub: Justin echoes the support of GitHub for the push to improve security everywhere. The responsibilities under the CRA should be placed with those businesses who are making the actual products, not open source communities. For development platforms, clarity is essential about who is considered a distributor. This role should be with those that assemble and deploy software, not development platforms like GitHub, PyPi, NPM or Nuget.
Laura Seay, Red Hat: The positive aspect of the CRA is that it is looking at cybersecurity from an end user perspective, specifically requiring secure configurations by default which would solve a lot of problems. The CRA has been a catalyst for opening these discussions between foundations, commercial software producers as well as the public sector. It also identified a strong need for education and training on what the open source ecosystem is and all the various supply chain roles from the producer all the way to the consumer. A potential difficulty is that in software development, the roles are not so neatly defined, since cybersecurity is everybody’s business.
Phil Robb, Ericsson: Phil made the panel unanimous in voicing Ericsson’s support for the intent behind the CRA and the need for improved cyber resilience. Since 80-90% of the software in any given product is likely to be open source, having a baseline of cybersecurity responsibilities is important. These responsibilities should be with those who receive the benefits from bringing products into the market. Ericsson is certainly ready to take on that responsibility.
How will the open source community and commercial vendors adapt to the CRA?
Greg Kroah-Hartman, Linux kernel community: The kernel community is worried that some developers will stop contributing upstream. 80 percent of Linux contributors by the number of developers for the past 20 years are paid to do this work. This is a concern about the viability of the open source development model if developers are made responsible for the code they contributed upstream. With the risk of losing contributors from the EU the capability to use open source software in Europe also declines.
Cheuk Ting Ho, Python Software Foundation: There is already a shortage of maintainers and contributors in the Python community. Burdening them with cybersecurity requirements and obligations will make their role more challenging and may discourage their contributions, making the open source sustainability problem harder to solve.
Justin Colannino, GitHub: The goal to place the liability upstream with the expectation that then more people will contribute is laudable. However, what is really going to happen is that contributing upstream will be considered risky for example by corporate legal teams, focusing development efforts instead on in-house products, forks and patches.
Laura Seay, Red Hat: The CRA blurs the lines especially for Red Hat who has pioneered the upstream first development model. Red Hat partners with customers and open source communities to fix bugs and patch security vulnerabilities in upstream projects. Reducing contributions from EU countries will also lessen resiliency because it won't be so easy to push fixes upstream, not knowing what the implications are to that.
Phil Robb, Ericsson: Open source software comes with an as-is clause, so it is up to those that use that software as to how they're going to support it. Even without regulation, there is a natural evolution of more and better activity going upstream, like OpenSSF and the many different projects to improve software security. There is trust and a long term working relationship with the contributors involved, including the panelists. If they are concerned about the effects of the CRA on the software supply chain, that is a problem for Ericsson who relies on their work.
How does the CRA interact with established cybersecurity practices?
Greg Kroah-Hartman, Linux kernel community: The EU intends to try and duplicate the US practice of maintaining a centralized security vulnerability database. However, this approach does not work well. There is hope that the EU won't make the same mistakes. That being said, there needs to be some form of insurance that devices are secure and safe over time. It is a very good step forward requiring devices to be updated regularly. If implemented properly, it will make the EU more safe and devices safer and more secure. This would be a great shining beacon for other parts of the world to emulate.
Laura Seay, Red Hat: The CRA could help with the consolidation of the growing number of cybersecurity industry standards and government regulations. Every time a new regulation passes, established security practices need to be paused and evaluated for compliance with a gap analysis. A more unified international set of standards would be helpful from a security standpoint.
Where would the CRA have unintended consequences?
Greg Kroah-Hartman, Linux kernel community: The CRA is a departure from the idea that open source software is provided as-is, but with no warranties of any kind. In fact, it changes the playing field less for commercial businesses, who are used to and expect to be responsible for their products. This will benefit companies who feel the competition from open source software, as well as the professional services businesses that provide third-party audits and certifications. Many of those spoke out in favor of the CRA. For the Linux kernel community, the playing field would not be a level one with the CRA as it currently stands.
Justin Colannino, GitHub: It is clear that open source has won because it has reduced the barrier to sharing. By reducing that barrier it sparked a wave of innovation. One unintended consequence of the CRA is that it adds a new barrier to sharing. If you share, you might be liable, This liability must be put on the deployment, not the development of software.
Laura Seay, Red Hat: There is a community of security researchers, white hatters or ethical hackers and even gray hatters who share the information about security vulnerabilities with Red Hat and others. Their motivation to contribute may be supplanted by a fear of punitive damages. This would undermine security instead of improving it.
Phil Robb, Ericsson: Disclosing vulnerabilities within 24 hours is particularly problematic if no fix is yet available. This may have unintended consequences, especially because some vulnerabilities cannot be easily fixed, meaning devices with known vulnerabilities would be operated on the internet. On the other hand, security advisories are often ignored by manufacturers and consumers, which the CRA aims to improve.
Closing statements - One thing to change to #FixTheCRA?
We asked all the participants to describe one detail that they would change in the CRA to improve it. These are their thoughts:
- Greg Kroah-Hartman, Linux kernel community: Just create a level playing field for all software, including open source.
- Cheuk Ting Ho, Python Software Foundation: Let’s make sure open source projects can be open source projects and are not being punished for that.
- Justin Colannino, GitHub: Don´t put obligations on sharing, regulate the deployment of software.
- Laura Seay, Red Hat: Transparency, clear roles and responsibilities help, but also keep in mind that compliance does not equal guaranteed security.
- Phil Robb, Ericsson: Don’t add friction to contributing to open source software, and the fines levied against commercial companies who are not compliant with the CRA should be invested upstream.
Overall, there have been a couple of “mic drop moments” during this panel discussion. Two statements stand out as take-aways: We should avoid creating new barriers to sharing source code, as that will undermine the open source development model. And compliance with regulation does not equal guaranteed security, so best practices and collaboration beyond what is being regulated will still be required.
It is welcome and encouraging that, in the meantime, there are indications that the EU is considering the feedback provided by the open source ecosystem and is reviewing changes that would address some of the concerns mentioned during the panel. The Linux Foundation and Linux Foundation Europe will continue to offer the EU our support, advice and input. Many thanks to the panelists for volunteering to participate! We hope that the insights provided by this panel and summary will help shape the Cyber Resilience Act to improve software security everywhere.
