Sally (00:23)
Hello, hello, and welcome to What’s in the SOSS, an OpenSSF podcast, where we get to talk to some amazing people who make up this great open source security ecosystem. And today I have a very special guest. But before we get into that, here’s what I want you to know. The clock is ticking towards a massive cybersecurity deadline.
Research shows that 66% of organizations don’t even know what it is. Love it or hate it. It’s the European Cyber Resilience Act or the CRA. This is important because how do we navigate this shift? Stick around because today we’re going to talk to someone who has a CRA plan.
Roman Zhukov. Roman, thank you so much for being here. Why don’t you introduce yourself to everybody?
Roman Zhukov (01:21)
Certainly, thanks for having me here. Hi everyone, my name is Roman and I work for Red Hat. I do some cybersecurity things on the internet. But approximately two years ago I joined this NICE effort, as we all now call the EU Cyber Resiliency Act. So it is quite a journey, but having fun.
Sally (01:44)
Well, I love that you say it is fun. And yes, it has been quite a journey. And we are going to unpack some of that today and try to help the audience so they can better be prepared. So I guess let us just start with the basics, right? The European Cyber Resilience Act, CRA. How do you define that? And how does it fit in with the various personas who show up to meetings with you or maybe are not aware but need to be aware. I know there are manufacturers, open source stewards, and individual maintainers in this persona group. Can you define those?
Roman Zhukov (02:23)
Yeah, absolutely. and you are right, that is a lot, a lot of roles, a lot of ambiguity. But let us start with the basics. The CRA is the regulation set up to essentially safeguard European customers of digital products by establishing mandatory cybersecurity requirements for companies that operate in the European Union. and suddenly, if not compliant, those hardware and software vendors will be unable to sell their products in the EU market after December 2027. I think it is worth to mention that the first requirement actually kicks in even earlier, a few months from now, September 2026, all of those organizations need to report vulnerability and severe incidents to the authorities. I would use the analogy for the CRA.
And I mean that is so complex, but I will try to break it down to a few things that should be familiar to almost everyone to understand how the series defines the role or roles that you just mentioned. Let us use the analogy of a community garden. Think of the maintainer as the hobbyist gardener. These are developers who cultivate a beautiful, let us say, patch of tomatoes just because they love gardening and they want to share the harvest with the neighbors and the CRA recognizes those actors and the CRA recognizes that forcing them to pay for legal compliance would kill the garden eventually. Therefore, if you are an independent maintainer doing some non-commercial work, you are completely exempt. So you are out of scope.
Contributor or maintainer, if you don’t charge any money for anything for your open source project, just keep planting the code, right? Just keep doing this, you’re out of scope. Now there is an essential role of the open source software steward or simply steward that we call it in the community. You can think of them as a guard garden association, right? There are foundations like OpenSSF or Linux Foundation, they could be big companies, they do not own the veggies themselves, but they provide the land, the fencing, the water supply, you name it, and you know they protect the ecosystem. So under the CRA, a steward is responsible for setting up the baseline policies and basic health checks for the projects they host, acting, you know, as a trusted buffer, I would say, between the community, those planting veggies and the corporate interests.
Now, finally, the most important actor under the CRA that actually has the most obligations and most liability is the manufacturer. We can think in our little example of them as a commercial restaurant, right? This is like basically any company that walks into the free community garden, scoops up the tomatoes, puts them into the premium pasta sauce.
And sell it to paying customers. So the CRA is kind of crystal clear here. If you make money out of software and you know you just sell the software to the European market, you bear the full legal liability for these things. You are the manufacturer and you must run the safety gates to ensure that your product does not give your customers the let’s say the digital equivalent of food poisoning, if it would happen for community garden. So that’s those are the roles under the law.
Sally (06:12)
Love it, Roman. That really makes it make sense for me. I used to love the farm to table restaurants. That’s what I kept thinking of when you were using that metaphor. That’s such a great metaphor. Thank you for explaining it. Yeah, I want to get out into the garden now. Okay, so we have the 2026 CRA Awareness and Readiness Report, which launched on June 8th. Roman, you wrote the introduction for this report, what was the most surprising finding for you?
Roman Zhukov (06:52)
Right. I would start off with writing the introduction to this report was an incredible honor to me. And it was at the same time the sovereign experience because the data what really matters and the data gave us a massive reality check. There are a lot of really mind-blowing findings, I would say. So I encourage everyone to dive into the whole thing. It is hard to pick up.
The one thing, but the biggest finding to me personally was like really the contradictory shocking nature of findings when you combine them all together. Not single number, but when you look at them and you see the full picture, that is fascinating.
while critical enforcement milestones are rushing really towards all of us, as I mentioned, the September 2026, the first vulnerability reporting obligations will be enforceable. At the same time, the global awareness has completely stalled, right? Like over 60% of respondents still entirely unfamiliar with this CRA, which is fascinating.
Compounding this the organizations that are aware on the other hand are attempting to what they think like ease compliance by burying code inside the private forks. Unfortunately I have been hearing this kind of perception or understanding by some companies that you just can simply fork and kind of escape some of the obligations, right?
But the reality check, backed up by numbers in this report is the report explicitly provides that maintaining these isolated codebases can be really a disaster from economical perspective to a company, draining an average of more than $250k dollars per release cycle in pure engineering depth or kind of simply the l the losses if you would.
But I am glad to see this new report came out actually, as it sends an undeniable message, as far as I see it, to executives and to all the companies worldwide, because the traditional checkbox compliance exercise, as well as that we used to call “consume and forget” for open source, right? Those models are coming away actually. And we should stop treating the open source like a free vending machine.
That is going to simply give you some candies for free without any collaboration, anything else, and therefore now for all the companies that are affected by the law, it would be really hard to deny active upstream collaboration, because it is now something baked in the law and not optional.
Sally (09:50)
Thanks for that, Roman. Yeah, there’s a lot to unpack here. The one thing that stood out to me is you said over 60% of respondents are still unfamiliar with the CRA. Why do you think this awareness gap persists even as the deadlines approach?
Roman Zhukov (10:07)
Yeah, first of all, to me as a co-chair of OpenSSF Global Cyber Policy Working Group, which is a home for collaboration between all of those actors that I mentioned, manufacturers, maintainers and other community members, to me that awareness gap means that we as a working group have so many things to do. I feel we kind of do some work on the awareness front, but there is so much more to be done on that front.
But to be serious, I think this persistent awareness gap comes down to a few typical behaviors that we have seen every day in the software world specifically. First of all, that is like somebody calls it the compiler warning syndrome. That means like in software development, I think
A lot of us are famous for ignoring warnings like compiler flags, all of this that is not that red but yellow, something like that. I will fix that later, and along these lines. I think many global companies are treating the CRA compiler warnings to that extent, right? Because the active enforcement and fines and everything will be starting in
2027 and still of companies saying okay, this is not a this year thing, right? We will come to it as it goes. So they are basically waiting for the build. You know, yeah, they are simply waiting for maybe others to start off and pave the way, but also waiting for the actual lag enforcement date, which is wrong of course.
Yeah, that is unacceptable. The another thing that I think is hidden here is the problem to parse the law actually and to convert the CRA to some of the actionable items. And the lack of the clearly lack of the implementation guidance and the standards. Now the EU authorities are working on the standards and some of the other clarifications that would help manufacturers to navigate this the CRA. But so far a lot of them are still in draft mode.
That means all of these companies are simply left in front of the CRA text itself and it could be ambiguous, it is not concrete. I often got these questions like, okay, we read the CRA one hundred times, but we do not understand what we should do exactly because there are a lack of the technical details on it. So this also adds, I think, to this kind of
Awareness gap, I mean we have heard about this CI, but we don’t know what exactly that means and how exactly we would approach this. And the final piece is the geographic kind of illusion. at least previously I have heard a lot of misunderstanding about this, and I think it’s backed by the report itself.
over seventy percent of North American software producers aren’t familiar with the CRA, right? And this is a belief that okay, I you know, I’m in America, I don’t deal maybe with the EU and it doesn’t affect me, but the CRA is so complex it affects the whole supply chain and there is a non zero probability that even if you don’t sell anything directly to the European Union, you are maybe one of the suppliers of those who do, or you simply maybe the contributor to open source or open source steward for instance. Those also have some obligations. So that also adds to the lack of awareness, I think, generally.
Sally (14:02)
Yeah, it does. Thank you for that, Roman. you brought up a critical point that the report mentions the traditional consume and forget model of using open source and that it’s no longer viable under the CRA. How does this regulation change how companies must interact with upstream projects, if you will?
Roman Zhukov (14:23)
Yeah, absolutely. I mentioned it already. I like the analogy between the consumer forget and kind of free vending machine, right? You push a button and something pops out and you just drop it into your commercial application and that is it. You never thought about the maintainers.
And I personally talk to a lot of companies out there and I frequently ask the question, hey, who is consuming open source? Everybody, right? Because open source is everywhere. But when I ask the question who contributes back, significantly less hands, right? But now under the CRA if you sell a product containing the code, you know, you’re kind of legally responsible for your products, that means effectively for all kind of all of the components.
And if something breaks, even if it is third party to you, if it is an open source component, you hold the whole liability to customers, to your consumers. And I think the CRA has a good chance to end this consume and forget paradigm by transforming open source security into nto the obligations, actually, right?
And yes, historically you are right, commercial consumers operated under the assumption that because open source components work fine for years, someone else would always take care. Now there are certain obligations, like for example, if vulnerability is found in the open source, you need to report back to upstream.
If you produce a fix as a manufacturer of the product, then you actually have to upstream this fix back to the maintainers. And this is a huge push and I think a huge paradigm shift from pure consumption to actually collaborating with upstream and with open source projects.
Sally (16:37)
You talked about the cost of private forks. I was wondering if we could dive deeper into that. According to the data, maintaining private forks cost organizations an average of $250,000 per release cycle. Or actually more than that, $258,000. I’m looking at the research. What is the business case for moving that work to upstream contribution instead? Can you talk a little bit deeper on that?
Roman Zhukov (17:03)
Yeah, that is a perfect finding. That actually to me is one of the most compelling findings in this report: the hidden tax of the private forks. As a long-term open source supporter, I am personally convinced that working upstream, as I do and as we do here at Red Hat, for example, is the only path to go, right?
But now the CRA report backs it up with the numbers and provides the actual business reasons for everybody else besides me and the companies that already contribute to upstream instead of forking things. Yeah, the maintaining private forks may cost organizations more than $250,000 US dollars in labor, which is a big amount of money actually. I would justify the business case for why you should actually contribute upstream instead. I can start with the basics, right? And the basics is that maintaining a private fork forces typically engineering teams to pay a continuous rebase tax.
That means that every time that upstream project releases a new version, right, your developers must manually port your customer patches over, resolve conflicts, and et cetera, and et cetera. On the flip side, by actually merging your features or your or whatever you do new for the project directly into the upstream.community eventually inherits the maintenance and etc. And then you subsequently consume back the newer version where everything is integrated and your code is updated automatically and you don’t spend this additional money to maintain all of these forks. The other business reason could be the engineering velocity that we call in the industry.
That means when developers burdened under the technical depth of the private fork, that significantly affects the product roadmaps. Right? You just have limited amount of resources typically, so you want to spend them wisely and by contributing upstream instead, it shifts your engineering resources from defense like fixing broken mergers to more
Building revenue generating features, if you will, for your products to focus on the core innovations and etc. Those are the basics I think that are under the core incentives why you should contribute upstream. But now the icing on the cake is the CRA factor. Because under the CRA maintaining a private fork would
Increase dramatically, I would say legal risk exposure for you as a product manufacturer. Because pretend if you integrate an open source library into a product, it is third party for you in the meaning of the CRA. That means like the biggest obligation that you would need to form against this dependency, this third party is to perform due diligence, which is
Kind of the one obligation. As long as upstreaming fix things, and hopefully you help also upstream to do these fixes. So you are not responsible for vulnerability management, you are not responsible for secure by design and by default, and etc. Now imagine with a fork, right? Your organization would hold hundred percent legal accountability for this library.
That is now part of your product because you forked it, it is now kind of your property, your responsibility. And nobody cares if you actually do not know the architecture, you may not know the design of this component or even you write the product within a different framework, right? Now you should still do secure by design
Risk assessment, vulnerability management, and full conformity assessment because of the CRA. And now the scale factor, imagine now you have 1000 of these open source libraries you are ingesting every day. And you need to assess it, if it would be even feasible to ensure full engineering compliance support for all of them. So that is the massive shift and the massive push towards better upstream collaboration
backed up by the real kind of business case and business considerations from that point.
Sally (22:04)
Thanks, Roman. Well, you and Emily and me worked on an OpenSSF case study based off of Red Hat’s framework for depending the open source supply chain in this new era of regulations, what is the most important lesson other enterprise organizations can learn from Red Hat’s approach?
Roman Zhukov (22:28)
I would encourage everyone to read this case study which is published under OpenSSF now. But if I picked the only one thing that enterprise organization need to take away, it would be something like this: true software supply chain security requires enterprises to transition from passive consumers into active open source contributors, supporters with the focus on practical security.
If it seems like overhead from the you know as it looks like but it is actually not really overhead if you think it is from occasionally watering your community garden coming back to our lovely example in if you think of occasionally taking care of this community garden in your town so that yourself and others can enjoy these lovely tomatoes at the end, that is a different explanation. Yes, companies like Red Hat take up their responsible stewardship approach, for example, because we naturally support and are committed to do so, some of the open source projects that run the entire world, right.
But we understand that voluntary maintainers do not have compliance team, they do not have legal departments, and quite often the case they lack security background, right, to actually deal with complex mandates and policy and things like CRA. So for other companies, I would suggest to actually break one of the myths.
That I constantly hear say, we are not able to contribute to open source because we are not subject matter experts. Or we use the different programming language. It is kind of an excuse, I would say. Instead, think of there is a lot more you can help with actually, starting just from your questions, right? Just asking your questions is good.
Or raising your CRA concerns, or going down to the frameworks, to the white papers. So we have in the communities we have so much work to be done, both from like collaboration perspective and also on the on the practical security front. So you know, that is kind of natural that the companies that of all sides can actually contribute meaningfully to all of this work.
And I would also add that enterprise compliance has historically relied on manual forms to some extent, right? All these GRC questionnaires, legal declarations, spreadsheets. And this approach is not working for the CRA right now. The lessons from our own journey on the CRA is to focus on the tools, on the practical security things.
Because by implementing automated machine readable security tools and specs and frameworks, organizations can shift the burden of evidence away from voluntary communities to themselves, which is kind of the goal of the CRA. By the way, you cannot offload the liability to the community. So you as a company need to figure out this thing by yourself eventually.
Good news here, there are many open source security standards and tools that can help you to do so. Just to name a few under OpenSSF, we have Open Source Project Security Baseline (OSPS), we have SLSA framework, we have Gemara compliance framework, we have GUAC, and a number of other projects that actually can help both maintainers of the projects to do security better, but also can help companies as they as they adopt them.
Sally (26:43)
Love that. I’d love to hear the good news and all of the areas where we can help make this feel easier for the enterprises and for the whole ecosystem. And you know, I don’t think it would be a conversation in 2026 under open source security if we didn’t talk about AI, right?
There is a massive spike in reported vulnerabilities due to AI-driven tools. How can open source projects realistically manage this influx of disclosures?
Roman Zhukov (27:24)
Yeah, you are right to the point. To handle the massive tsunami of AI driven vulnerability reports and disclosures hitting the open source ecosystem now actually even harder than the enterprises, projects have to adjust their vulnerability management practices and of course tooling to adopt what I call the “post Mythos era” we are entering right now.
A few practical recommendations that I would stress out is first, you need to have a robust intake filter to do the basic sanity checks. It is clear that now a lot of AI agents are operating out there, and not all of them produce actually high-quality reports or high-quality pull requests, etc.
And as a maintainer, you need to introduce some of the filters and checking for things like okay, I do require the proof of concept, I do require affected versions, I do require reproduced steps and a couple of other things. If there are ants in the report, they just simply reject them. So as a maintainer I do not have capacity to deal with these reports.
Now of course automation would help. Automation of looking into some metrics even for the reporters themselves, like reputation, maximum number of emojis even in the report and in the pull requests. I have noticed that a lot of AI assisted contributions are flooding with the emojis, right? Maybe that is because some AI tools just like emojis, something like that.
Checking some of these things would actually help to reject anything that is suspicious bluntly for you as the reporter. So those would be my recommendations.
Sally (29:23)
Yeah, I have to tell my AI assistant, no emojis, no more emojis. They flood it. That’s interesting. Okay, so for the fewer than half of the manufacturers that were surveyed are expected to be fully compliant by the December 2027 deadline. What should these uncertain organizations focus on right now?
Roman Zhukov (29:48)
That is a hard question. I would say I think organizations need to stop looking at the CRA as just a 100-page legal monster something, or perceive it as a next GDPR with this cookie pop-up thingy that you need to implement, which CRA is far from actually. And organizations need to start treating it as a standards software engineering refactoring project. I would be that ambitious.
The EU commission itself actually keeps saying that the intention of the CRA is to make sure that companies invest in the real security improvements. And then compliance shall follow naturally. So start exploring the CRA in great detail right now.
Including all of the implementing acts that we have right now. And you will realize that scope is broader than you eventually think. There are a lot of terms, a lot of complexities in the intersection between the software as a service that are technically out of scope, but there are some of the components that we call remote data processing solution that could potentially make some of the cloud solutions be in scope, right?
And the open source is technically out of scope, but there are many cases when open source can be in scope. So understanding your role, whether you are a manufacturer, distributor, importer, maintainer, steward, contributor, is crucial, right? Because obligations differ dramatically.
But I would suggest to remember the one simple thing, liability always flows downstream. That means you cannot really offload the liability of anything to open source, for example. As a manufacturer, you are ultimately responsible for anything. So one of the advice that I can give to all the companies is to just stop harassing maintainers and asking them how they are doing about the CRA, right? It is not their responsibility to make sure they are CRA compliant.
To draw kind of a bottom line here, do not wait. Build your CRA program now. It is because it is definitely a cross-functional effort. I can speak from our experience. Yes, we are a big company, right, but buy-in from across the different functions inside the company is really vital to set a CRA program up for success. Right. And let us be honest, CRA did not invent brand new security practices. Some of the timelines like 24-hour reporting obligations of actively exploited vulnerabilities and severe incidents are hard. But in essence we all should be implementing all of the things like security by design or security by default, and doing proper vulnerability management as well as SBOMs for years now, right? So apply what is available right now to your products, to your practices. And again is good news. There are plenty of mature frameworks and a lot of open source tools actually that can help you, right?
If you do not know what to do the simple thing is just cooperate upstream. Join me, join my company and others, other peers at initiatives like OpenSSF, Global Cyber Policy Working Group, to learn more and to learn how to start. But yeah, there are plenty of things that you should do right now to prepare yourself to be compliant. 2027 is around the corner, really.
Sally (34:06)
I do feel more hopeful now hearing from your perspective and the things that people can do. One last thing that struck me from the report that I wasn’t expecting was that over half of the European small and medium enterprises, those SMEs, remain unfamiliar with the CRA. So how can the open source community best support these smaller type of organizations that lack a large legal team?
Roman Zhukov (34:30)
That is exactly where the community can actually help and help significantly. For example, as part of our OpenSSF Global Cyber Policy Working Group effort, we are creating digestible white papers, checklists, simple guidelines dedicated to different roles under the Cyber Resiliency Act, and they are meant to be easily consumable by those people in those organizations that are not necessarily familiar with the complex legislations or even unfamiliar with the sophisticated security concepts.
I would say one of the biggest and successful assets that we collaborated on and produced under this effort is the free CRA class that is now hitting way over 5,000 of enrollments, and this is really a good starting point specifically for small and medium organizations because it is again short, concise, sticks to the points and is free completely for everybody to take. It teaches you about the basics of the Cyber Resilience Act.
Also in our group we do regular briefings on what is new in the CRA development. Which is again super important to small and medium organizations because they simply do not have time and capability and desire to learn what is happening in the legislation every day. Therefore, we also do the workshops and brainstorming sessions, both offline and online, to handle cases that the members of our community actually bring to us. And this is a real thing. I would encourage all the SMEs that have questions to just come to our group and ask your questions. Bring up your case and we will do our best to provide our community advice for what you should do about this.
In addition, we also collaborate across multiple OpenSSF projects and broader industry initiatives to work on tools that would help companies, specifically smaller companies, because they are meant to handle or automate the large portion of the CRA compliance, at least we believe so. By standardizing and integrating community tools like the open source project security baseline or OSPS and now actively developed due diligence solution for manufacturers directly into the templates, into the development practices.
We actually as a community can bake compliance into the code, right? And finally reach the point when we can tell, okay, this is compliance as code, and we have all the evidence produced automatically. And this transforms to my personal understanding, a huge portion of complex CRA requirements into free, off the shelf, to some point click to deploy guardrails that can allow smaller companies to stay compliant with the CRA and more importantly actually implement the good security practices like secure by default and etc without needing the huge security teams or the army of lawyers or something.
So that is what can really help SMEs to navigate the Cyber Resiliency Act.
Sally (38:16)
That’s really helpful, Roman. Thank you. All right, let’s shift gears here. I want to talk about something that first off, just want to give you a huge congratulations for that you were just recently became part of our OpenSSF ambassador program, named to the first cohort. A quick question, I guess. What are you thinking you’re gonna do with this new role?
Roman Zhukov (30:40)
Thank you. Well, it is so natural to me as I feel I have been an ambassador in OpenSSF for quite a few years now already. I joined an OpenSSF fan club with the introduction of the first they call it beta or alpha version of the scorecards, a tool that analyzes the security health of open source projects in an automated fashion.
Years later I helped to roll out OpenSSF Scorecard across a few companies of different sizes. Right? So that is how my joining naturally started with OpenSSF. So now that is how I get into it. And you know the drill, right? Once you are in, it is really hard to escape from doing these good things.
With the community and for the community essentially. But to be serious, yeah, I am very proud to be named as an official OpenSSF ambassador. It is an incredible honor to me and also a huge responsibility. In this role I hope to provide what we call the open source way. And educate everybody that the open source way is not just a methodology for writing code, but also it is the most effective framework that we have now for solving global security and regulatory challenges, which we do not have a shortage of at the moment. As you mentioned, all of these AI vulnerabilities and regulatory compliance challenges across the world, they add up to the whole picture.
So by bringing a pragmatic engineering centric voice and approach that I personally really try to follow every day by bringing this to the table. I hope we can ensure that the security becomes an active feature of the ecosystem we all depend on so heavily, right? Rather than a blocking thing that is still perceived by some organizations.
So I have done security for twenty plus years now and it is so close to my heart and I just wanted to carry this torch and I want to spread the word about the beauty of security and all of the open source tools and collaborative nature of it so that it can be easily digestible and implemented across the other companies.
Sally (41:32)
Love that. Okay, that wraps wraps up our main deep dive. But before I let you go, Roman, we have a little thing called rapid fire on the OpenSSF What’s in the sauce podcast. So just first thing that comes to your mind, I’m gonna ask you a series of questions. This is fun stuff, not work stuff. All right, are you ready?
Roman Zhukov (41:52)
Mm-hmm. Yes, love it!
Sally (41:54)
Okay. Tea or coffee.
Roman Zhukov (41:56)
Coffee.
Sally (41:57)
Oh, I wasn’t expecting that. Cheers. I love it.
Roman Zhukov (41:59)
Oh really?
Sally (42:00)
Yeah, I was thinking tea. You’re in Ireland, right?
Roman Zhukov (42:07)
But I love coffee as well. I can drink it every day actually. Yes.
Sally (42:111)
I love coffee too. Really? Okay. I love that. Favorite open source mascot.
Roman Zhukov (42:16)
CRA-fish
Sally (42:17)
Yeah, good one. Star Trek or Star Wars?
Roman Zhukov (42:21)
it is hard but Star Wars, I think.
Sally (42:26)
The tracks. All right. So we talked a lot about your metaphor with the food. I loved that and with growing in the garden. If you’re gonna use one of those tomatoes and make salsa, would it be mild or spicy?
Roman Zhukov (42:39)
Spicy, one hundred percent.
Sally (42:41)
Love it. Okay. well, thank you so much, Roman. To wrap it up for listeners who want to leverage OpenSSF resources, like what you mentioned, the cyber global cyber policy working group, or maybe the new awareness sig, the training course. What’s the best place for them to start today?
Roman Zhukov (43:02)
Right. I would I I would end nearly where I started with again going back to my community garden analogy. with a community garden typically you don’t need any approvals or special permissions, you just show up, learn and see where you can actually help as like everyone else with the tomatoes to make sure they they are good then to eat and to enjoy.
Right, that’s essentially what we do in the community. And despite the scary policy compliance angle, we are super friendly at the OpenSSF Global Cyber Policy Working Group. and you have to trust me to here. just join one of our calls to learn what’s going on. It is free, open to everyone. You don’t have to be a member of anything at all. Just just show up, join.
To name a few specific entry points that could can help you depending on what you need or what you’re building. We have the one stop shop hub that we call it policy.openssf.org/CRA. This is the one stop shop that can get a handle on the landscape of the CRA, what’s happening around with the news without the getting dive into the legal text and all of these complexities.
Of course, explore our GitHub repository. Under OpenSSF, we have Global Cyber Policy Working Group. If you want to dive into the governance, check out what we’re working on, like go to this repo. There are a lot of materials published there. As I mentioned, checklists, guidelines and links and all that you need to know how to further participate in the community. Like we have the bi weekly calls of our main working group. We have also calls for our SIGs, which are awareness SIG and also standardization SIG. They all do a great job in their remit. So please consider joining these efforts if you wanted to dive a little bit deeper into either awareness things.
One of the examples I would as an opportunity I would show you is right now at the very moment we’re looking for collaborators for the blog post series that we plan for the CRA. If you would like to be the co-author, please join us and help to spread the word over there. Finally, we also do a lot of meetups across the globe and throughout the year.
But we also have the workshops and online webinars like EU CRA Monthly Tech Talks, when we actually have the guests speakers speak about everything that can be related and can be helpful on the CRA implementation, again from the different companies, from the different entities and different actors on this space. So just keep an eye out on the announcements.
We always have a lot of stuff to share, but also we have a lot of work to be done. Please come join us and collaborate on the overall effort of making this CRA meaningful and actionable for everyone.
Sally (46:42)
Brilliant, Roman. I feel much better about CRA awareness. Thank you. And until next time, stay secure and happy open sourcing. That’s a wrap.
Madalin Neag
Christopher Robinson (aka CRob) is the Chief Technical Officer and Chief Security Architect for the Open Source Software Foundation (OpenSSF). With over 25 years of experience in engineering and leadership, he has worked with Fortune 500 companies in industries like finance, healthcare, and manufacturing, and spent six years as Program Architect for Red Hat’s Product Security team.
Helen Woeste joined OSTIF in 2023, coming from a decade of work experience in the restaurant and hospitality industries. With a passion (and degree) for writing and governance structures, Woeste quickly transitioned into an operations and communications role in technology.Â