Download the Free eBook: Built to Last: Understanding the European Cyber Resilience Act (CRA)

What’s in the SOSS? Podcast #70 – S3E22 Private Forks, CRA Deadlines, and the True Cost of Open Source Compliance with Dave Russo

Summary

In this episode of What’s in the SOSS, host Sally Cooper sits down with returning champion Dave Russo, Policy and Standards Lead at Red Hat’s Open Source and AI Program Office, to unpack the European Union’s Cyber Resilience Act (CRA). Together, they explore the stark realities of the 2026 CRA Awareness and Readiness Report, exposing why three-quarters of North American tech companies remain completely unaware of the strictest cybersecurity mandate in history. Dave breaks down the hidden $250,000-per-release financial toll of maintaining private forks, the crucial legal distinction between software manufacturers and open source stewards, and Red Hat’s framework for “champion stewardship.” Whether you are facing the upcoming September 2026 vulnerability reporting platform launch or preparing for full December 2027 enforcement, this conversation delivers clear, actionable guidance to get your organization compliant, collaborative, and secure.

Conversation Highlights

00:25 – Welcome & Introductions
01:28 – Meet Dave Russo
02:01 – The Global CRA Awareness Gap
04:46 – The Hidden Cost of Private Forks
07:32 – Manufacturer vs. Open Source Steward
09:09 – Red Hat’s Light vs. Champion Stewardship
11:37 – Crucial CRA Deadlines Explained
13:51 – Actionable Compliance Steps Today
16:47 – Rapid Fire Fun

Transcript

Sally (00:25)
Welcome to What’s in the SOSS, an OpenSSF podcast where we talk to amazing people that make up the open source security ecosystem. I’m your co-host, Sally, and today I’m really excited to welcome back, returning champion, Dave Russo, the Senior Principal Security Program Manager at Red Hat. Dave, welcome back.

Dave Russo (00:49)
Thank you for having me, Sally. I appreciate the invite to be back. It’s great.

Sally (00:53)
Yeah. Last time we had you on the show was during the Council of Dave’s. That episode was epic, all about education. Yeah. And today we are on a mission to unpack the CRA. We have the CRA readiness report. We’re gonna talk about private forks and the role of the stewards. So yeah, welcome, Dave.

Dave Russo (01:17)
Great, there’s a lot to unpack.

Sally (01:18)
For those of us who maybe didn’t hear the Council of Dave’s, you we’ll link it in the show notes and maybe aren’t aware of you. Can you give us a little intro?

Dave Russo (01:28)
Sure. So I am the Global Policy and Standards Lead on Red Hat’s Open Source and AI Program Office. I’ve been at Red Hat for 10 years. I spent most of my time on the product security team working with internal governance, which changed to a little bit of external work when all the executive orders and EU legislation started coming out for security regulation, which has been awesome, and moved over to the OSPO team this year.

And what I can say is that there’s plenty to do and none of it’s slowing down.

Sally (02:01)
Yeah, none of it is slowing down and there is plenty to do. I mean, this is why we’re here, right? We have the 2026 CRA awareness and readiness report in front of us. It highlights there’s stagnant global awareness. There’s a massive financial drain. just a lot to unpack. Basically in the report, I read that 66% of the global community are unaware, and this went up from the 2025 results.

And hit 72% in North America. So yeah, nearly three quarters of the North American tech sector is operating completely unaware, frankly, of the strictest cybersecurity mandate ever. What’s going on here?

Dave Russo (02:46)
Yeah. So you know, I remember when the report came out last year, we were not surprised by the awareness numbers simply because of the nature of what the CRA is and the broad regulatory net that it’s throwing out there. It was disappointing to see the numbers actually gone up this year. There’s an increased sample size, which may have something to do with it, but I I think one of the driving forces behind this is really about

How this regulation applies. You know, if folks worked in a regulated industry like banking, they are more used to having to deal with regulatory bodies and meeting regulatory requirements. CRA applies to any and all products with digital elements, aka software and firmware for that matter, that are sold on the EU market. That’s everything. I mean, if you sell anything that has a software component in Europe, the CRA applies to you.

So, you know, most I’d say most engineering folks have not had to deal with these things and therefore are unaware. I think another aspect of this is we’ve been doing a lot of socialization for the last

one year, 18 months on this. But I think we might be in a bit of an echo chamber. we’re talking, you know, in a similar sphere with folks that are in compliance roles and are more in tune with regulatory bodies and the open source community. I think we’ve done a lot of good work with the OpenSSF working groups. But I think we need to try and expand our scope to try and hit folks that are just not seeing or hearing things ~ from the typical ~ avenues ~ that would released that information.

Sally (04:29)
Yeah, ~ that is a problem. And it sounds like we are doing a lot with the Global Cyber Policy Working Group, the Awareness SIG, but we need to broaden and we need to find people who don’t know about these things to get them the information so that it’s not so scary, right? right. Yeah, the report points out a massive trap that companies are falling into as well, which is maintaining private forks.

So pulling it back instead of collaborating upstream, can you break down why you think this is happening and what the financial toll it takes or what could be the financial toll that it takes?

Dave Russo (05:05)
Yeah, I was really happy to see this data point added to the report this year. ~ It’s very interesting, it’s very telling in my opinion. I can understand why some companies ~ have been maintaining private forks and may be interested in continuing doing that moving forward, but the sheer scope of what the CRA is asking ~ to do is going to probably increase the amount ~ of that work that would have to be done if that’s the path that that companies would like to take.

I believe, ~ the numbers in the report pointed out that for an average company, it’s about $250,000 per release of additional cost, which is a lot. A lot of hours involved in there, there’s a lot of work involved in there. ~ And I think that I’m hoping, hoping that this this starts a shift in mindset. While private forks may be necessary for short-term issues, maybe like vulnerability patching and meeting certain SLAs, I I think companies need to take a look at where they’re putting those resources and and looking at doing ~ a better job of collaborating and contributing upstream because it’s always easiest to address you know a situation ~ at the the point of failure, quote unquote, “point of failure” by providing resources, time, effort, funding, whatever the case may be, and and contributing that upstream to help make the project more sustainable, you’re gonna get benefits from that as a company, you’re going to get a better level of readiness.

You’re probably gonna get a better level of response with patching, especially around vulnerabilities. None of that’s guaranteed, obviously. But you know, working with the open source ecosystem, working with the projects, being an active contributor and collaborator will save some money in the long term because the technical debt that could potentially continue to be accrued from this is massive.

I mean, there’s a lot right now, the way things are set. Once the CRA enters into full force, and once more companies are more cognizant of the amount of open source that they’re using and what needs to be done in order to meet the obligations in the CRA, I I think it it’s going to increase the the amount of of time, money, and effort to to maintain these private forks.

Sally (07:19)
Yeah, it’s interesting thinking about the short term and the long term. And knowing that there’s some deadlines coming into effect in weeks. yeah. okay. I wanna talk about another topic because I read your blog, the Red Hat official, I think it’s called stewardship guidelines.

Dave Russo (07:29)
Yes, there are.

Sally (07:30)
Yeah. okay. I wanna talk about another topic because I read your blog, the Red Hat official, I think it’s called stewardship guidelines.

Dave Russo (07:41)
Yes.

Sally (07:42)
Okay. What’s exactly the legal difference between a manufacturer and a steward under CRA? Can you explain that a little bit more to me?

Dave Russo (07:50)
Yes. So CRA actually formalized the idea of stewardship and ~ I think it’s probably one of the better outcomes of ~ the regulatory legislation. So a manufacturer is any entity that is putting a product with digital elements, aka a software, firmware, for sale on the EU market. So ~ if anyone is marketing something that folks are going to pay for or there’s a paid aspect to it, it has a digital element to it.

Those are manufacturers under the CRA. And there’s a list of obligations that the manufacturers have to meet. The stewardship is a bit different. So stewardship is intended to apply directly to the open source projects themselves to help sustain them and support them. An open source steward has very limited obligations under ~ the CRA. We’ll probably talk about them in a little bit more detail here shortly.

But essentially, if a entity provides a sustained level of support to an open source project, they’re considered an open source steward. And depending upon the actual nature of that support that they’re providing, they have certain obligations that that need to be met. again, with the end goal of improving that project’s security and making it more sustainable long term.

Sally (09:09)
Yeah, thanks for that. In your blog you distinguish between a champion steward for projects like Fedora versus a light steward. What does that mean for the maintainers of those projects?

Dave Russo (09:21)
So that is something ~ that is a red hat creation. There is no mention at all of any kind of different levels of stewardship, light stewardship, championship stewardship in the CRA. When we were looking at all the projects that we are involved with upstream, we wanted to make sure that we were putting an appropriate amount of effort into stewarding, being a good steward, the different projects based upon you know the nature of those upstreams and how they’re used as part of our portfolio.

So, what we call light stewardship is the exact requirements that are outlined in the CRA regulation itself. Very few things, basically having some policies around handling vulnerabilities, messaging, licensing, that sort of thing. Not a whole lot of requirements there, as well as reporting. There’s an obligation to actively…excuse me…to report actively exploited vulnerabilities or severe incidents on the project. So those are the things that the CRA says a steward must do. We looked at certain projects and the level of involvement and criticality that they had to Red Hat’s portfolio. We want to go above and beyond with these projects. That’s what we call the champion stewardship. We want to not only meet whatever the CRA says needs to be done as a good steward, but we want to help work with that project, collaborate with that project, doing it the way that they do it.

And in in providing, you know, best in class practices for improving their security and providing information to all the downstream users of that of that project.

Sally (10:57)
That is some great work that Red Hat is doing and thanks for unpacking it. It makes more sense to me now. And I’m really interested in all the roles and you know, thinking through how we all work together to meet these upcoming deadlines. The immediate reporting cliff that I’m thinking about is September 11th, 2026 for the strict vulnerability reporting.

And how we prepare for that and then also the December twenty twenty-seven full compliance deadline. So let’s just talk about the calendar. Walk us through what happens on September 11th regarding vulnerability reporting.

Dave Russo (11:37)
So on 11th September of this year, a little more than a month away, the European Commission created what they call a single reporting platform. And that is the platform that needs to be used to report to the European Commission any actively exploitable vulnerabilities and or severe incidents that affect the product with digital elements that the manufacturer has placed on the market, or that affect a project of a steward.

So essentially they don’t want all vulnerabilities reported. That’s ~ too much. They are very concerned about an incident where there may be a data breach, an infrastructure breach of some sort. They’re also very concerned about vulnerabilities that can be exploited, especially in open source projects that are used in a lot of different pieces of software, products of digital elements in the EU.

So they want to have ahead of time notice that there’s something going on or something needs to be concerned about. And the reasoning behind this is to make sure that the appropriate level of transparency is being provided, both to other companies that may be using these open source components as well as to consumers that may be affected by them. There’s a lot more detail around exactly how this information is going to be used and the timing on it that’s in the legislation itself. But that goes into effect ~ in September.

In December twenty twenty seven, the CRA regulation is in full effect, which means that all of the obligations that a manufacturer and a steward and the other roles have are expected to begin. So all the different you know manufacturer requirements ~ that need to be met have to be done by December 2027 in order to place the CE mark on the product with digital elements ~ and assert that it is in fact meeting what the CRA requirements state and is safe to sell in the European Union.

Sally (13:34)
Dave, you make it sound easy. I appreciate that. for folks listening who might not be aware, maybe they’re in that 66% who are unfamiliar or feel like they’re behind, what’s the step that they need to take today?

Dave Russo (13:51)
So I would say, and I don’t want to panic anybody, ~ if your organization is not aware of the CRA and you are marketing things in the European Union, you are a little bit behind. However, it is not untenable, it is not too late. You need to have folks in the compliance roles to take a look

At the CRA legislation itself, there’s three documents that those people should be looking at. It’s the actual CRA regulation document, it’s the FAQ document that was published a couple months ago, and the CRA implementation guidelines that were just published earlier this week. Those three documents will give you all the information on exactly what it means to meet the obligations outlined in the CRA, who it affects, how it affects them, ~ and the steps that need to be taken.

There are also, just FYI, standards being created by a couple different groups in the European Union. Some that affect all products of digital elements, they’re called horizontal standards, and there’s some what they call vertical standards that only affect certain classes of products, such as operating systems, hypervisors, etc.

A lot of public comment has gone into these documents. they are coming out with ~ the final first versions of these over the next several months. There is expected to be revisions down the road, but if you market certain types of software, you want to probably take a look at those ~ and see what it’s saying that needs to be done specifically for all software in general or specific categories of software.

If you’re not a compliance person, you can certainly read the CRA. It’s a lot of information, these documents, as I stated, contain quite a bit of info. But compliance folks can help the engineering counterparts understand what this actually means in practice. What needs to be done as part of the SDLC for their software. Different steps and practices that need to be put into place, and the appropriate level of evidence and types of evidence that needs to be collected in order to do these assertions to these self-attestations that the software actually does meet this information.

I would recommend, in addition to all that, the OpenSSF has quite a bit of excellent information that breaks down these different documents and a lot of the details involved in there on the it was the policy.openssf.org webpage, there’s a number of CRA specific documents that we’ve put together as part of the global cyber policy working group and the SIGs.

I would definitely reference folks to that, especially folks who may not have a lot of compliance background. It does make it easier to understand and presents information in a straightforward manner.

Sally (16:33)
Yeah, it does sound like these resources, having them available makes it easier to understand and unpack. So I really thank you for that. And we’ll put all the links you know, in the show notes for everybody to click through.

And alright, Dave, before we let you go, it’s time for our favorite segment of the show. This is our rapid fire round. This is gonna be fun. You’re pro at this, you’ve been here before. I’m just gonna throw a few new questions at you and just to let me know the first thing that comes to your mind. Are you ready?

Dave Russo (17:04)
Sounds good. I’m ready.

Sally (17:05)
Okay, and maybe some of them have changed since last time, favorite food?

Dave Russo (17:08)
Yeah, probably.

Sally (17:09)
Yea right?

Dave Russo (17:10)
Favorite food? pasta.

Sally (17:11)
Pasta…spicy or mild?

Dave Russo (17:14)
Mild.

Sally (17:15)
Ah, excellent choice. Tea or coffee?

Dave Russo (17:18)
None of the above.

Sally (17:20)
Ohhh. Star Wars or Star Trek?

Dave Russo (17:25)
Oh man, I I knew this was gonna get me. I…you know, ~ I gotta say Star Trek, I love Star Wars, but I was a Trekkie from a very, very young age. so ~ that is a tough one though. I’m gonna get flacked for that when people hear that.

Sally (17:40)
Yeah, it’s so loaded that question. But Star Trek Next Generation used to watch reruns when I was in college, totally dating myself. But yeah, that was great. Okay, favorite open source mascot.

Dave Russo (17:32.325)
Honk.

Sally (17:53)
Yay! Okay, Dave Russo, thanks for being a steward of the community and providing all this great information for people around the CRA. And until next time, that’s a wrap.