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

This talk focuses on the Cyber Resilience Act (CRA), a new EU legislation set to impact software developers and maintainers significantly. The speaker, a committee member representing the open source community, explains that the CRA mandates software disclosures similar to ingredient lists in food products, ensuring all software vulnerabilities are reported and fixed. This helps developers understand where their software is utilized and encourages communication with upstream communities regarding security issues. While there is some uncertainty concerning hobby projects, individual developers are not held accountable under this law, only stewards, which are foundations responsible for software distribution. The speaker emphasizes that there is time for developers to prepare as the law's enforcement timeline progresses, and highlights tools and resources for compliance.

Good morning, Amsterdam. I come from Greg. Ik woon hier, Nederland. Ik ga praten over de CRA. Okay, I'll switch to English. >> [sighs] >> 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 [snorts] 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, not 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. This is a really good thing. This is a good thing for consumers and 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 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. They're 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, oh, 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 groups issue and assign their own CVEs. Please

do that. I strongly recommend it. Um, the best practices badge that the OpenSSF has been doing for over a decade now. If you follow that, you're covered. You are doing everything you need to do 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 SBOMs or not. 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 good things. There's a whole checklist on GitHub from OpenSSF. these slides will be available everywhere, so you can look at that. 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're 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 go look at all the standard stuff that's happening within the OpenSSF and within the CRA if you're interested. Um,

some of them are not going to 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, 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 just summarizes 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. >> [applause]