Keynote: The CRA and What it Means for Open Source Communities - Greg Kroah-Hartman (ASL)

This talk discusses the Cyber Resilience Act (CRA), a significant EU legislation impacting software developers and maintainers worldwide. The speaker, Greg, an expert committee member representing the open source community, explains that the CRA requires software devices to list their components or 'ingredients' and ensure they are safe and updated. He highlights the importance of reporting security vulnerabilities and interacting with upstream communities, which benefits both consumers and open source developers. The speaker clarifies that individual developers and hobby projects are largely exempt from these obligations, as the law primarily targets manufacturers and foundations. He emphasizes the simplicity of compliance for developers, suggesting practices such as providing a contact for security issues and utilizing tools to produce a software bill of materials. As the law rolls out, developers have time to adapt and align with upcoming standards and best practices.

Good morning, Amsterdam. Ik ben Greg. Ik woon hier in Nederland. Ik ga praten over de CRA. Okay, I'll switch to English. Um, the CRA is going to affect us all. It's a EU legislation that's going to especially affect here, but it's also going to affect the world cuz everybody deals with software everywhere. I am one of the expert committee members of the CRA, representing the open source

community along with a member from Eclipse and from Apache. Apache's done a great job with this. And I'm going to talk about how this affects us as developers and maintainers. Not us as companies, but us as distributors or anything like that, but us as individuals and programmers. Um, I'm sure your corporate lawyers know all about this, but let's talk about for this for developers. So, first off,

what is the CRA? The CRA is simple. I call it just a list of ingredients. Food has to list everything that they have in it. Devices need to list all the software that's in it. And we have to make sure those ingredients are safe. They have to be kept up to date. They have to be fixed all the vulnerabilities. They have to report all the vulnerabilities. And

they have to interact with the upstream communities when they report those vulnerabilities, which is very important. And this is a really good thing. This is a good thing for consumers, end users of software and devices in the EU and the world. And it's a great thing for us as open source developers cuz we actually will learn more about where our software's being used. They have to report

this. They have to tell us when they find security vulnerabilities. This is a really good thing for us. There's a lot of stuff that's outside the scope of the CRA. We don't have to worry about services, websites, specific devices already are covered under different legislations like automotive, medical, marine. And if you have a hobby project, you have a hobby project, nobody really cares at all. It's not

going to be covered at all. Until somebody actually uses it. And this is the trick. Once it gets added to a product, and you don't know that because of open source, we don't dictate use. We can't tell people how to use our stuff. But all of a sudden, now we're covered under this law. And what does that mean for us? And how's that going to affect us?

Luckily, it should be all just fine. There's different classifications of groups under the CRA. Developers, that's us. Stewards, and I'll talk about stewards in a second. That's a special thing that they've carved out in the law. That's a a good thing. Manufacturers, integrators, and distributors. And those are all corporations. Those are companies. Developers are individuals. Stewards are foundations. So, like the Linux Foundation, Mozilla, other open source

foundations, Apache. Those are foundations. These are legal entities that are not an individual. They're not an individual person. And this is important because the way the law was originally written, there was some uncertainty whether individuals could be a steward or not. They've clarified this publicly now. Stewards are not individual people. So, nobody has to worry about this. That's good. So, as a steward, as a foundation, you're

the responsible for distributing the product or doing the releases or not. So, when you're a steward, the CRA mandates that you do two things. And this is something you should do today. All you have to do is provide a contact for somebody to report a bug to you. That's going to be a security issue. And if you fix the security problem, report it. That's it. That's all

you have to do. This is all the CRA requires you to do as a foundation, as a steward. An individual developer, you don't have to do any of this either. Consultants, you're not covered. This is it. The CRA is very simple for us. Don't worry. And also, uh you do have to do this for a foundation. Uh report if your infrastructure has some problems. Like GitHub had

the recently break-ins, things like that. You would have to do that. GitHub will be a steward as well. That's okay. You have to report these things. And when you report these security fixes or um security failures, there will be a single reporting platform within the EU. You also can go to individual um C search within the company uh within the different countries, if you want to use

one of those. Linux Foundation's probably going to use one specific one that's close to us. Do that. And these are things again that you should all be doing this. A simple security.text. You can become a CNA to assign your own CVEs. I really, really recommend that you do this. Pearl or Python paved the way for us. They allow that open source issue and assign their own CVEs.

Please do that. I strongly recommend it. Um the best practices badge that the Open SSF has been doing for over a decade now. If you follow that, you're covered. You are doing everything you need to do for the CRA plus some. That's great. Then companies when they take your software and put in their product, they can look at that and say, "Hey great, they're covered. We're okay."

They know that you're following the best practices of what the CRA does. All is good. The reuse tool from the Free Software Foundation Europe, great. I use that for my open source projects. It gives you a software bill of materials automatically. Does an audit of the licenses. Gives a nice standard machine readable format, great. CNCF many projects have today already have tools that create S-bombs, whatnot. Use

those. More projects should be using that. I think only about 1/3 of the CNCF projects are doing that. I saw a dashboard the other day. More should be doing that. It's just these good things. There's a whole checklist on GitHub from Open SSF. Um the slides will be available everywhere, so you can look at The timeline. The law is in force today, but it's not actually being

implemented today. In June of this year, the government will be ready, the single reporting platform will be ready, and assessment bodies will be ready. So, that's the government is working very hard at this. I've been talking with them. They are heads down. They got a lot of work to do. In September of this year, manufacturers have to start paying attention to this. They must report any security

vulnerabilities that they know about, that they have been fixing, and that they have been found. They will be using this and they will be stress testing it. Us open source stewards and developers don't have to worry about this for another full year. So, we get to watch them work out the kinks, work out the bugs. Then, we need to start reporting bugs. So, we have plenty of

time. It's all going to be good. There are some standards being written as part of this stuff. Um the use of standards is voluntary at this point. Standards aren't finished. There's a lot of work going on the standards. Um Madeline from OpenSSF gave a talk the other day um about this. Go talk Go look at all the standard stuff that's happening within the OpenSSF and within the

CRA if you're interested. Um some of the work will be finished till afterwards. We're participating. If you have questions, I I strongly recommend your companies get involved. They are defining what an operating system looks like, what a router looks like, what the vulnerability process looks like, all these good things. Get involved with there. And then finally, there's a whole bunch of links. All the CRA resources. Um

the new ones are the one-page summary and the playbook by OpenSSF. They did a great one there. Take a look at those and um follow them. It's just summarize it all. But again, you don't have to worry about this as a developer, as a maintainer. It's all going to be just fine. Thank you very much.