In this conversation, Rachel Stephens (Research Director at RedMonk) and Mike Milinkovich (Executive Director, Eclipse Foundation) discuss the EU Cyber Resilience Act (CRA). Mike explains the law, its implications for the software industry – particularly open source software – and the responsibilities it places on manufacturers. This episode covers:

• the evolution of the CRA from a “near-death experience for open source” in its initial drafts to a “workable piece of legislation”
• understanding the responsibilities the legislation places upon different industry roles
• exploring the CRA’s potential impacts on open source communities
• discussing how to get prepared

This discussion is emphatically important if you sell software into a European market. Come listen to Mike to help understand the new legal obligations that come with the CRA.

Links

• LinkedIn: Mike Milinkovich
• Open Regulatory Compliance Working Group
• ORC FAW

Transcript

Rachel Stephens (00:12) Hello everyone, welcome to RedMonk Conversations. I’m Rachel Stephens and with me today is Mike Milinkovich. He is the Executive Director of the Eclipse Foundation and we are here to talk about the CRA, everybody’s most favorite and exciting topic. And I say that with a little bit of jest, but also everyone needs to stick around and listen because it has vast impacts to what is going to be happening in this industry. Mike, would you like to please introduce yourself and what you do at the Eclipse Foundation?

Mike Milinkovich (00:38) Yeah, hi Rachel, thanks. So Mike Milinkovich Executive Director of the Eclipse Foundation, that’s like the equivalent of CEO of a nonprofit. The Eclipse Foundation has been around for 21 years. the first 16 of those, we were a US incorporated 501(c)6 trade association. And a couple of years ago, we moved our headquarters, legal domicile to Belgium. And we’re now an international nonprofit association headquartered in Brussels.

Rachel Stephens (01:04) And that becomes pertinent later. First, let’s talk about, so CRA is what I mentioned at the top. That is the EU Cyber Resilience Act. Mike, can you start us out with a really high level of what the CRA is just so we’re all on the same footing?

Mike Milinkovich (01:18) Sure. So the CRA is the world’s first horizontal regulation of the software industry. Today, historically in the software industry, it’s been an unregulated industry except in particular areas like the primarily it had safety concerns like automotive, aerospace, medical and the likes. And of course, then there’s some finance and so on. But we haven’t historically had regulations that apply across the entire industry as it pertains to cybersecurity requirements. And so the CRA is a piece of legislation that applies to every product that will be made available in the European market after December 2027. And that means that every product that either is a software product or embeds software, like an IoT device, for example, will be required to comply with the cybersecurity requirements.

And it’s really important to understand the motivation behind this. So the motivation is primarily to protect European consumers from shoddy software. And the genesis of the CRA goes back to some, you know, incidences that we’re all familiar with where botnets were made out of webcams and so on, where the cybersecurity practices that went into these devices was very, very minimal.

And during the construction of the CRA, the original drafting of the CRA, if they had stuck to that original mission of devices, it would not have been that big a deal. But during the drafting process, Log4Shell happened. And that was sort of the software industry’s Ralph Nader “unsafe at any speed” kind of moment where governments and policymakers around the world realize that there’s this thing called open source software and it is literally everywhere and It’s completely unregulated and so they decided to modify the scope of the CRA to include all software and just adding that and software Fundamentally change the framing of what the CRA is and how it applies to products around the world.

That’s really sort of a quick explanation of what the CRA is and its motivations and how we got here.

Rachel Stephens (03:26) Yes, and so when I talked with you previously, when the genesis of actually having this conversation publicly is we decided I talked with you and I said everybody needs to know about this. But when I talked with you previously and we kind of talked about expansion to and software and open source software, you described that as a near death experience for open source software in the first drafting of the bill. So can you talk about kind of what the law looked like in that first iteration of the and software expansion into where we’re at now that the bill has passed?

Mike Milinkovich (03:54) Yeah, absolutely. And fundamentally, the good news is that the policymakers listened. So that’s the good news. But the very original drafts of the CRA when they were first made public basically didn’t differentiate between open source projects and products.

So what it meant originally was that all the full weight of the compliance requirements that you would expect from a software company like say Oracle or SAP or a product company like, you know, say your Bosch dishwasher or whatever, the full weight of those regulatory requirements were going to fall upon anybody who’s working on an open source project.

And that’s what I mean by a near-death experience, because if that had happened, it would have fundamentally changed the equation for what it means to be an open source project and the obligations of being an open source developer to the point where pretty much it would have just made it almost impossible to legally make your open source software available in Europe. And a number of different things, scenarios could have played out. Fortunately, didn’t get to that.

Rachel Stephens (04:56) Yeah.

Mike Milinkovich (05:00) I could have imagined a lot of open source developers saying you are not allowed to use this software in Europe, for example.

However, we at the Eclipse Foundation and many of our colleagues at the Apache Software Foundation, the Linux Foundation, Mozilla, all everybody banded together rallied around this. And we convinced the drafters that they were making a significant error in establishing it that way and they listened and what we’ve got now with the final version of the CRA is it’s not perfect but it is a lot better to the point where I think we’re generally very happy with it. Of course, know, anytime you take an unregulated industry and make it a regulated industry, ⁓ lots of things are going to change and the…

Rachel Stephens (05:35) That’s good.

Mike Milinkovich (05:47) the ripple effects will be vast, but we have a workable piece of legislation for the open source community.

Rachel Stephens (05:56) Okay. And when I said we are coming back to you being located in Brussels, like everyone rallied around you because you were the only open source foundation that had an EU based presence, is that right?

Mike Milinkovich (06:06) Yeah, I mean, they listened to other ones as well. But I think the Eclipse Foundation, first of all, we were one of the early ones. And I think it was partially because we had just moved to Europe, we felt the impact a little bit more. So we were definitely one of the first organizations to really start to sort of rally support around, hey folks, listen up, there’s an issue here. And now we weren’t the first, there was a gentleman from NLNet Labs, the Internet Society wrote some early stuff as well. We were not the first, we were not the only, but I think we deserve a little bit of credit for being one of the first and ones that really kind of really raised awareness of the issue. And of course, we invested a bunch of time and energy in reaching out to the policymakers and trying to convince them that we weren’t just cranks, and we we share their goal of improving software security for everybody.

As Europe’s largest open source foundation, we also have a particular desire to see Europe succeed and to have a really dynamic, innovative economy and society. And the original drafts of the CRA definitely threatened the future economic activity in Europe because it would have really stifled innovation. And that would have been a tragedy.

Rachel Stephens (07:30) Absolutely. So I would love to dive into the different roles that are spelled out under the CRA. Can you kind of walk through the different responsibilities that exist?

Mike Milinkovich (07:39) Yeah, so there’s lots of ways you can talk about this, but let’s just sort of start at the top. So what is in scope for the CRA are what they call products with digital elements.

And so a product with a digital element is fundamentally a piece of hardware that embeds software or a pure software product that is put into the European market by a manufacturer. Now, there’s really, there’s two classes of products with digital elements, sort of regular ones, where the manufacturer can self-certify that they comply with the requirements of the CRA. And then there’s important products with digital elements – identity management systems, operating systems, these kinds of sort of more important pieces of software – you actually need to have an external notifying body, think like TÜV SÜD or these kinds of companies to come in and actually look at your cybersecurity development processes and certify that you as a manufacturer are complying with the requirements of the CRA.

When I say this is the world’s first horizontal regulation of the software industry, this is ultimately every single software product that is sold in Europe after December 2027 is going to have to have a CE mark affixed to the product. And that CE mark will denote that it complies with the requirements of the CRA. Now.

It is manufacturers who have the responsibility to comply with the CRA. So these are companies that are building and shipping products for the European market. As we know, everybody in the software industry uses open source.

Rachel Stephens (09:14) Absolutely.

Mike Milinkovich (09:14) So that’s where open source starts to come into play. And so the requirements on the manufacturer is for the first time ever, the manufacturers have to actually care about the open source software that they’re putting in their product. And they actually have to demonstrate that they know what software they’re putting in and they have to be able to produce SBOMs software bill of materials. So you have to know what software is going in and they have to have some ability to deal with any security issues with that software during the life of the product. And that’s fundamentally new. I think we’re all aware that many companies use open source software in their products and they never ever engage with the upstream. And this changes that equation in fundamentally, we still, you know, it’s gonna be interesting to see how this all unfolds and what the both the ripple effects and the unintended consequences are going to be. But now every single manufacturer that’s shipping a product in Europe is going to actually fundamentally have a choice.

for their open source dependencies. They’re going to either have to engage with the upstream project and make sure they understand what the security practices are of that upstream project, or they’re going to have to fork the project and maintain it themselves. Fundamentally, those are the only two choices that manufacturers have. Of course, forking is a terrible idea.

So in the long run, it’s always going to be much more expensive to maintain a fork than it is going to be to engage with the upstream. Yeah. So what we have now is what a behavioral economist would call a nudge. So we now have a nudge that says that companies that are building products on top of open source have an economic motivation to engage with the upstream projects in ways that they have never had before. And that’s really, I think, how the CRA is going to change the equation in open source is largely around that. And I think so, so I’m cautiously optimistic that the, you know, the full outcome of the CRA, once it all completely unfolds, is going to be very positive for the sustainability of the open source projects and communities. And now there’s some interesting sort of scary scenarios in that where, you know,

And we should talk about this too, like most manufacturers today don’t actually realize what the CRA is. They’re basically ignoring it.

Rachel Stephens (11:30) Mm-hmm.

Mike Milinkovich (11:31) if they even know about it. And I’ve had some very unfortunate conversations where people say, the GDPR was in the end was super simple. I’m sure this is super simple. No, it’s not. This actually means that you have to do things in your product development cycle that you have perhaps never had to do before. Now,

Every manufacturer who’s basically doing cybersecurity best practices today, like following best practices around secure by design and supply chain security, they’re already in great shape. Because that’s basically what we’re talking about here. It’s just, you know, basically do the right thing. there’s like, there’s nothing earth shattering in the cybersecurity requirements of the CRA. But there’s a lot of manufacturers out there that perhaps don’t have those processes adequately documented.

They don’t actually verify that every single product release that they ship has actually followed all of the best practices. Like these are the things that are going to be changes. And they’ve never had a legal requirement to care about the upstream open source projects that they use in their product. So these are all massive changes and the manufacturers really have to wake up and pay attention because this is not a small thing. is a really big thing.

Rachel Stephens (12:40) And I think, hold on, so you said nothing earth shattering, but I actually think that some of the timelines to provide fixes might be earth shattering for some orgs. Can we talk about that a little bit?

Mike Milinkovich (12:49) So in terms of like requiring to maintain the products for five years and those sorts things.

Rachel Stephens (12:55) So I think it’s two-sided. I think there’s the timeline to turn around to patch if there is a security issue. And then I think also there’s going to be a whole lot of companies that rely on long-term support revenue streams that are going to all of a sudden be legally required to provide that anyways. So think both of those factors might be really impactful.

Mike Milinkovich (13:03) Yeah.

I’m trying to remember what the actual timeline is, but yeah, once you know that you have a security vulnerability, the clock starts ticking right away. I’m sorry, I don’t off the top of my head remember what the actual timeline is.

Rachel Stephens (13:22) it’s like matters of days though, like months, not long periods of time, it’s a quick turnaround

Mike Milinkovich (13:34) Yeah, and in addition to that, there’s an actual legislative responsibility that if you find a security vulnerability in an open source package and you fix it, you now have a obligation to provide that fix to the project, regardless of whether it’s a copy left license or not. And that’s another sort of huge change that has never been there before. Earlier I said that they have to engage with the upstream. Now they actually have a legal obligation to provide patches to upstream if they find something and fix it. I apologize, I can’t remember the exact time in terms of how fast they have to fix things, but it’s super quick. And so that’s on the one side.

And the other side is when you ship a product into the European Union, you have a, I believe it’s a five year obligation to provide security fixes for your software for a minimum period of time. And that’s another obligation because there’s lots of scenarios where devices are put into a market and then

You know, there’s no security fixes or or in many cases. There’s not even a mechanism by which to to to fix it Right. it’s just a best practice But now it’s written into law. You’re not going to be able to ship a product into Europe that you can’t update

Rachel Stephens (14:44) Right. I also just want to clarify for everyone, like manufacturer, at this point, we’re not just talking like IoT devices with embedded software. This is anyone selling software in any form, correct?

Mike Milinkovich (14:54) Well, it’s a little more subtle than that. for example, so software as a service is actually covered under a different piece of legislation called NIS2.

If you have software which is already covered by a different cybersecurity law in the European Union, so for example automobiles are already covered under a separate law, so the software inside an automobile doesn’t necessarily have to comply with the CRA. So there’s some corner cases like that, but…

Rachel Stephens (15:24) So there are big corner cases, but software as a surface is a very big corner case, but yes. But basically, I just want to make sure everyone understands, we are not just talking about someone who’s got a device that needs to be flashed, like IoT device. That’s not what we’re talking when we’re saying software updates. We are saying general enterprise software.

Mike Milinkovich (15:28) Yes, yeah.

Yeah, enterprise software, desktop software, all of these things are gonna be required by law to have some mechanism by which they can be updated in the field once they’ve been shipped into Europe. And the fact that that’s a legal requirement on a product is new. And again, all of these things are fundamentally best practices, but when you add them all up and realize that they are now enshrined in law, it’s a fundamental change.

The thing that worries me a lot is, again, going back to what I said before, a lot of manufacturers don’t seem to be really paying attention to this. And if they are, they’re thinking, it’s not that big a deal. I think it’s a really big deal. And we need more manufacturers to kind of wake up and engage. It’s kind of funny because there’s lots of people in the open source community that have been thinking about this and are worried about this and have been for a year and a half or more now, it’s weird that in some sense, that in some ways the open source community is ahead of the industry in terms of actually thinking about how this is gonna all play out and what their roles and responsibilities are gonna be.

Rachel Stephens (16:46) Absolutely. And when you say it’s weird, it’s weird because open source projects don’t have any of this direct liability like the manufacturers have, but there are likely to be downstream impacts. Could we maybe talk about that a little bit?

Mike Milinkovich (16:58) Sure, so you’re right. Open source projects in and of themselves don’t have any direct responsibility for this. And in fact, the Act specifically says that manufacturers bear the responsibility. So I’ve seen a few things, you know, where open source projects have said, I read the CRA, I don’t want to put up with this, I’m shutting my GitHub repo and I’m giving up on open source. And don’t you don’t if you’re a developer, don’t do that. So there’s a whole bunch of reasons why.

First of all, if you’re a developer and you’re just building something and you’re not monetizing at all, which is a huge percentage of open source packages and components, you are clearly outside the scope of the CRA. You are not liable. If you are monetizing it, then it’s a little bit of a gray area. And it’s like, if you’re monetizing basically just to cover your costs, you’re fine. If you’re turning this into a business, and you know, if you’re like a single vendor open source project, then yeah, then you could be a manufacturer and the requirements of a manufacturer apply. So it’s a little bit complicated, but in general, if you’re an open source developer, you really don’t have to worry about this. And on top of everything else, when the CRA is in full force and effect, I mean, the regulatory authorities are not gonna go after some little project on GitHub when they have manufacturers shipping, know shoddy goods and charging people consumers money I mean, it’s just there’s not they’re just not on the on the radar screen in terms of enforcement So I really don’t I really don’t think that open source developers have to be in a panic.

In addition to that, if you are a contributor to an open source project that you’re not part of the governance of, you are clearly outside the scope of the CRA. If you are contributing to an open source project, you absolutely do not have to worry about any of this. Now, all that said, we talked about manufacturers. One of the most innovative parts of the CRA is for the first time, in any piece of legislation in the world, it enshrines a role for an economic actor they call open source software steward. And open source software stewards are primarily the foundations that you’ve probably already heard of, know, Eclipse, Linux, Apache, Mozilla, they’re clearly open source software stewards. But an open source software steward does not have to be a nonprofit. So for example,

Not a lawyer, could be a little fuzzy, but I think, for example, Red Hat is the steward of the Fedora project. So you have these cases where a for-profit company can also be a steward of an open source project in community.

Rachel Stephens (19:25) They could be both a manufacturer and a steward at the same time?

Mike Milinkovich (19:28) Yes, exactly.

So they’re a manufacturer for RHEL and a steward for Fedora. And they have to be able to switch hats depending on which piece of technology you’re talking about.

Rachel Stephens (19:39) No pun intended. (Sorry.)

Mike Milinkovich (19:48) So yeah, and hat does not have to be red except in this example. So open source software stewards. are rganizations that have sort of skinny in the game for open source projects, but they’re not there to monetize it. They’re not there to make profit, but they’re there to make sure that the projects are sustainable for the long-term and so on. so what an open source software steward does, and this is again, another interesting potential consequence for the CRA is we, by the way the act is written, we take any possible risk that the CRA applies to you as a developer, we take that off of you as a developer.

The open source software stewards are going to be the ones that are going to be responsible for the projects under their stewardship, never the developer. So in the case of the Eclipse Foundation, our projects, we’re the ones that are going to be responsible to the market surveillance authorities if they have any questions about our security practices that we apply for the projects. this is kind of interesting in the sense that first of all, it’s the first time there’s any piece of legislation that recognizes that there’s a role for foundations in the industry. So that’s cool and innovative in its own sense.

But it also provides a clear mechanism by which a developer that is wondering whether or not they want to, they have any obligations in the CRA can basically wash their hands of it and say, I’m going to bring my project to a open source foundation. And then I know that it’s not my problem. And so we expect that, you know, as we get closer to the implementation date of the CRA, that there could be a lot of projects that are saying, “hey, Apache, Eclipse, Linux, can we move our project into your stewardship and take advantage of this open source software steward role?” And so that’s again another interesting wrinkle with the CRA.

Rachel Stephens (21:32) I think that’s very interesting, especially when you were talking previously about economic nudges and like the ideal scenario is people who are utilizing the software are going to be contributing back to the upstream. I think one of my fears is that what’s actually going to happen is that these maintainers just get like absolutely hounded and like bombarded by requests from people like, hey, like I need this documentation. Hey, I need this fixed.

And so hopefully having like that steward role helps alleviate some of that.

Mike Milinkovich (22:03) Yeah, so this is already starting. We, and I’ve talked to some of my counterparts at other open source foundations, we at the Eclipse Foundation and other foundations are already getting emails. And I don’t know what these people are thinking about sometimes when they draft these emails. We’re already getting emails that are, you two years before the act comes into full effect, demanding to know what our plans are for CRA conformance. And it’s just like, yeah, no. I do share your concern that there will be a time where, we have so many people looking to help us all at once that the open source software ecosystem kind of gets inundated with helpful people all at once. that’s, anybody who’s worked on an open source project knows that if one or two people show up looking to help, yeah, that’s probably really cool. If 100 people showed up to help all at once, that’s not actually help. That’s just a problem.

Rachel Stephens (22:56) And even worse is if a hundred people are showing up demanding help, because I think it’s worse.

Mike Milinkovich (23:03) But I mean, and so we at the Eclipse Foundation are playing a role to try to help figure all of this out. So there’s a couple of things that are going on.

So one is we have this thing called the Open Regulatory Compliance Working Group, which is basically what we’ve done is we’ve gathered most of the world’s open source foundations with a collection of leading manufacturers to come together to figure out how we can make all of this work. in addition to that, we’re also, we’ve received funding from the European Union itself to work on projects to do things like build open source compliance tools for small and medium enterprises and make sure we do it in open source so that SMEs have a toolkit to help them with their CRA compliance without actually having to pay a vendor a whole lot of money. And then we have another funding mechanism where we are working on what will the security attestations for an open source project look like.

And one of the things that is not an open question yet is open source projects, open source foundations in the role as open source software stewards are gonna be expected to provide some sort of security attestation that basically says, this is how we deal with security in this open source project. Are those attestations open source? Right, do we give them away for free?

It’s a whole bunch of extra work. It’s not the code. It’s the only reason why you need this is you’re building a product. I don’t know. Is it like, how does that all work out? So one possibility is this is a way for open source projects to make a little money to help with sustainability problem, both at the open source software steward level, but at the individual project level.

Back to sort of the economic nudge sort of ideas, like I said, is that open source? I don’t know. And is there a way to help with the sustainability issues for open source community and ecosystem and projects by making the manufacturers help chip in a little money to make all the security stuff work?

Rachel Stephens (24:59) Yeah. And I wanted to clarify, because it sounds like when you’re talking about things kind of still being up in the air and nebulous, the law itself has passed, but a lot of the implementation details are still coming together. Is that right?

Mike Milinkovich (25:08) Yes.

Yes, and it’s horrendously complicated. So the law itself is passed, and there’s a timetable by which it’s going to come into effect. However, the way that a lot of these laws work in Europe is that to…

implement these regulations, there are these things called European Harmonized Standards. And European Harmonized Standards are developed by one of three organizations in Europe. One’s called CEN, CENELEC and ETSI are the three. And these organizations create standards for Europe. There’s a total of 40 or 42 standards requests that are related to the CRA that are in flight as we speak. And some at ETSI some at CEN/CENELEC and the details of how these standards are going to be written is going to determine a lot of the final details in terms of how the CRA is actually implemented.

In addition to that, there’s also what they call delegated acts where, for example, one of the things in the CRA is it says that open source software stewards are going to be subject to a light touch and tailor made regulatory regime. So we don’t actually know exactly what it is that open source software stewards are going to have to do, and as far as I know, that’s not even being drafted yet, or at least a first draft has not been made public. So that’s another example of where there are a lot of little details that need to be worked out in how to implement this. Now, a good resource for developers on these topics is under the ORC working group, we have a CRA FAQ, frequently asked questions. And this is a living document that’s going to be evolving as all of these details emerge. But if you kind of want like a one-stop shop, one place where you can go read everything you need to know about the CRA as a developer, that’s a really good place to start.

Rachel Stephens (27:06) Wonderful. So we will be sure to link to the FAQ for developers. And if you find yourself in a manufacturing position and are finding any of this to be novel, probably you should join the ORC overall. Yeah.

Mike Milinkovich (27:20) Absolutely.

So we need manufacturers to engage because this is going to be a journey for all of us. Open source foundations, open source projects want to do the right thing for industry. We’re all motivated to know, improve the cybersecurity of our projects and the products that rely upon them. So we’re all in this together. And we need manufacturers to engage to make sure that we understand their use cases and to make sure that the things that we’re thinking about is the processes that we do inside open source projects

in terms of how they feed into these processes that are inside manufacturers, that has to be as seamless as possible. Because otherwise, the economic cost is going to go up more than it needs to be. The more we can align what we’re doing in open source with the needs of industry, the better we’re all going to be in terms of the cost of implementing this legislation.

Rachel Stephens (28:09) Absolutely. Well Mike, thank you so much for your time and thank you for helping us kind of spread the word about the CRA and the actions people need to start taking now because we cannot wait until the year of.

Mike Milinkovich (28:19) Thanks Rachel, I really appreciate the opportunity.

Rachel Stephens (28:21) Thank you.