Roman Zhukov - Making EU CRA (Cyber Resilience Act) simplified and non-scary for OSS contributors

[music] I lived in heaven as a developer.

My source code was a beautiful create creation and I dedicated myself to the whole open source void. I was so relaxed

until something happened. This guy came and they took the music down and put my cocktail away.

And the worst thing about it, they didn't mention anything about living.

Welcome to the new world of EU library resilience act. And that is how some of

resilience act. And that is how some of us as a developers especially in the open source world feel ourselves about the CRA. But I hope I can demystify some

the CRA. But I hope I can demystify some of the things about the regulation itself during this this talk and also provide some technical advice how to

navigate it. Welcome everybody again. My

navigate it. Welcome everybody again. My

name is uh Roman and I'm from Ireland.

Um the beautiful home of Guinness James and all of these good things. Um also I work for Red Hat uh when I'm principal architect and responsible for uh strategic community and industry

engagement in security space but also and I'm practitioner I work in security for almost 20 years uh doing all the things from uh vulner vulnerability

response to architecting uh the systems and defending enterprise and products from cyber attacks. But recently in the um in the last year I jumped into this

compliance activity uh into the EU cyber resilience act as an expert uh for the European standardization organizations

uh because this thing matters and um if we don't do it right, it's uh going to provide a lot of harm to the ecosystem and to all of us actually.

Um and yes also I am huge supporter of open source and uh typically um help open source projects on their security journey.

All right. Um what is CU cyber resilience act? Um I think it's good to

resilience act? Um I think it's good to start with the definition of this thing.

This is regulation. Okay. that aims to safeguard consumers and businesses buying or using so-called PTE products with digital elements with introduction

of mandatory cyber security requirements for manufacturers of these pro products throughout the entire life cycle and notably its supply chain. Also imagine

third parties and open source components that are obviously included in all of the products that you can um see uh out

there and CRA actually applicable to um all who does commercial activity in or with EU so that it's not really solely EU thing especially when we think about

software it's really international thing that's why all of the big American companies and other international companies are actually concerned about this things. And if you're wondering

this things. And if you're wondering what's on the picture, this is the famous cheese picture that's produced by European Commission I think roughly one year ago and represents the good

intention of the cyber resilience act to fix those supply chains that's on the left like holes in the chin and to make it finally right to make security

finally as a mandatory thing for all the products which is good.

Uh now what PTE are um and this is the one of the common misconception when I talk to people um about the scope of the

cyber resilience act. Sometimes we think okay this is only for devices or for the physical things that are out there.

Actually uh PDEs are everywhere as you can see on this picture and the regulation defines the certain classes of this PD that you can see on the

slide. For example, smarthome operating

slide. For example, smarthome operating operating systems or even web browsers, password managers uh or uh firewalls, hypervisors or in the critical category

hardware devices with secure bo boxes, smart mirror gateways, smart guards. Um

I think they're all really important and critical to secure and at least to think about them. Uh that should be secure but

about them. Uh that should be secure but actually everything else is also in in scope. All the consumer devices that are

scope. All the consumer devices that are out there and all the software because PDS includes hardware and software

separately. Okay. And actually

separately. Okay. And actually

everything else is counted roughly as more than 90% of everything else. Um so

that means the scope is really wide is really huge.

Uh now what's out of scope which is very important to mention. Um out of scope products covered by the regulations like automotive medical aviation or um

national security regulations something like that which kind of makes sense. uh

pure websites are out of scope as well as software as a service platforms. But this is with a huge caveat because uh there is still uh yet to be developed

the clear definition for RDPs remote data processing uh solution. Basically

if your cloud is essential to operate with your device say you use your cloud to uh kind of tune in your uh fridge or a microwave or something like that and

this is untouchable from the product.

it's in scope as well but the general clouds solutions like AWS Google and etc when you just rent uh some compute there is out of scope free and open source

software FOS you will hear this um acronym a lot during this presentation if not used in course of commercial activity also out of scope which is great which was not uh in the first

version of cyber resilience act but we as a open source community made sure that we made this exclusion Now uh what could go wrong with this

exception? Um of course everything uh

exception? Um of course everything uh unfortunately uh it could be quite small but I will I will describe what's in this picture. It's uh an email that the

this picture. It's uh an email that the open source project lipsy and maintainer of this pro projects received um a couple of month ago and

that states this is queries for to vendor and the questions are is a secure software development life cycle followed

in your lipy open source library do you comply with CRA requirements and my favorite one do you provide proof of conformity

regarding adherence to U C. And on the left hand side you can see the uh dates um and the date of the email and the uh

int um the the date for required response and thanks for giving us exactly two weeks open sour um big vendor to the open source maintainers to

to respond to this and this is happening. This is actually represents

happening. This is actually represents the huge complexity and the huge misunderstanding of the C CRA across the industry and hopefully that gives you

all the perspective why uh we do these things, why I do these things to kind of explain what CRA actually means to uh everybody and most importantly to work

within these uh officials to make sure they do the right things with implementing the regulations so that opensource ecosystem

uh continue to live uh and ensuring their longevity uh because you know what open source maintainers owe you nothing right and

regulation like is not an exception here. So we definitely don't want to

here. So we definitely don't want to regulate open source and you know right now is a good time to actually make it right instead.

Now um important opensource software roles in cyber resilience act. I think

it's uh really it really would be great to clarify them. There are not all the roles here

them. There are not all the roles here on the slide but to simplify and to uh so that you're not bored with all of these things. Uh there are three main

these things. Uh there are three main key roles related to development related to open source. Uh first of all manufacturers there are key

um there are key actors in the in the act. This is uh who actually develops

act. This is uh who actually develops the product and sells them to the market. Right? This kind of makes sense

market. Right? This kind of makes sense manufacturer. Uh and this is weird to

manufacturer. Uh and this is weird to hear manufacturer for software, right?

This is great to hear or or appropriate to hear manufacturer of a car but not manufacturer of piece of software. But

they're all manufacturers. uh oss

maintainers and contributors as I mentioned they're out of scope uh largely but they are mentioned somehow in the regulation and the uh very

important role is actually first appears in the regulation entirely and in the standards in general we didn't see this role before open source software steward

if you can think of the foundation for example Linux foundation of ASP or Python foundation or um Apache they they

kind of all um typically non-commercial non-for-profit organizations that help to govern open source projects. So those

are stewards. Um the sad news here is that most of the open source projects will not have open source software steward obviously because there's still a lot of projects not even this the kind

of small and hobbyist project but also the big projects that are very popular that just developed by one maintainer or a couple of them and they don't belong

to any of the foundation. So this is very important to keep in mind. Um

now the timeline uh I also found it's useful to put the timeline here because um a lot of us ask uh a lot of uh people ask me these questions during these

multiple days. Um the timeline is

multiple days. Um the timeline is actually pretty hard. The regulation is already here. Um and there is the

already here. Um and there is the timeline you can see on the slide but I would like to um drag your attention to uh the September 2026 where reporting

vulnerability obligations will come to um enforcement and December 2027 is the full application of the law. So

the all of the products that will be a that will be put onto the EU market should be compliant with the CRA after this date.

Uh and fines of course uh there is nothing to do uh you know if there are no fines right uh fines are pretty huge that's why the all of big corporations

and actually small corporations as well small companies that produce software or hardware they are concerned and they're must pay attention to this if not

already uh requirements I didn't mean to didn't mean to include this slide but again during in this uh two three days uh was a lot of question what actually means uh

to comply with CR what the requirements are and I decided just to put them blanket uh list here and most of the manufacturers

that's very important to keep in mind uh like 99% them really for manufacturers and for everybody else like stewards they're they're light regime so that they

supposed to be not enforcable uh but along this manuacture lectures are like all great things that uh we as a security professionals have been

actually um talking about for decades to all of the engineering teams, right? And

all the people out there, hey, do security by design and security by default configurations. Uh do the proper

default configurations. Uh do the proper risk management um vulnerability management, you know, take care of the uh or at least check the actively exploited vulnerabilities, something

like that. uh sbombs also is the big

like that. uh sbombs also is the big thing in the C C array. Some of the new things that's coming up with the conformity assessment and C marking. If

you look at your device like phone or I don't know printer at home, you probably can spot on this C mark uh that is uh affixed to the device. So the same

concept would apply to under the CRA as well. It would be interesting to see how

well. It would be interesting to see how to stick this mark to the piece of software that's hanging out out there in the internet. But we will see and also

the internet. But we will see and also free updates uh for the five years at least support and updates.

Now there are all the kind of requirements and glance uh and they they will be clarified actually under the standardization effort that is ongoing

right now.

Um now uh this chart uh again this is small but I will be giving away the presentation anyway. Um this is the um a

presentation anyway. Um this is the um a lot of people are still asking of course I'm affected or not but what but should I do anything if at all under the CRA if

I somehow work with open source right and I will try to spell this chart for you. So first of all if you contributor

you. So first of all if you contributor to the open source project that are you not maintainer for go down so you don't have any

obligations under s just relax like this guy on the first um on the first slide on the beach. Uh if you're a maintainer of the open source project or or help

somehow to maintain the project and don't take money for anything at all. If

answer is is yes you're out of scope. Um

if you maintain a maintainer and accept donations that covers the actual cost of living and you know the actual cost of the development of the platform that you may use maybe something else you also

don't have obligations under the CRA you're all good only if you're maintainer of the open source project and charge for support service or data

or sell somehow the project or licenses um related to this project you you might be in scope of C but if not you're also

out of scope. This is very important to understand. If you're just developer or

understand. If you're just developer or even open sourcing enthusiast something like this or even take donations but do not earn kind of the real big profits out of your projects you are out of scope. Again this is very important to

scope. Again this is very important to understand.

A couple of other things important to understand uh is yes like to reiterate contributor developer you're out of scope. Just to

make it clear, if you work for company and develop something or contribute to something, don't be bothered, right?

It's it's at minimum it's the company's obligation. If they do some products

obligation. If they do some products or, you know, and sell them, but you are all good. If you're a maintainer, you're

all good. If you're a maintainer, you're out of scope. Don't monetize. If any of those uh you are out of scope, if your project is not a product with digital elements, this is again very important

to understand. I know this is all boring

to understand. I know this is all boring stuff regulations but uh think of documentation or research projects or

alphabets or something uh test that you can put out there uh on the GitHub prepo for example it's all out of scope it's not a product by definition right it's not intended to use in any production

capacity and etc and you are also out of scope if the uh PD is not placed on the EU market which is very sophisticated definition, but it's if it's not

monetized, if you don't sell, um you're out of scope.

Um I hope that makes sense so far.

Um and again, all of the requirements and fines uh for manufacturers for these companies, right, not for maintainers and even not for stewards to some

extent.

Um and yes, if you are still scared a little bit and think that is that is something that is you know uh is going to hit um you're not alone with this

understanding. We're all scared to be

understanding. We're all scared to be quite honest. Um and you're not alone

quite honest. Um and you're not alone here. Uh we can help these brilliant

here. Uh we can help these brilliant guys you can see in the picture. I will

explain uh who does what in this picture. Uh first of all I would start

picture. Uh first of all I would start with the beautiful initiatives um that are um happening out there under Eclipse Foundation. There is the ORC that's why

Foundation. There is the ORC that's why this little ORC picture on the top right corner. Uh this is open regulatory

corner. Uh this is open regulatory compliance working group purely open source. Uh we do awareness and

source. Uh we do awareness and guidances. We do inventory. We help

guidances. We do inventory. We help

projects and manufacturers and everybody actually navigate the CRA compliance. Uh

we will be building specifications and etc. If you go if you want to join, you can simply Google us or or see working group or go to the GitHub or scan the QR

code. It's all free of charge. It's open

code. It's all free of charge. It's open

source. You can jump into the calls without any registrations or SMS or something like like this. So it's good collaborative activity. Please join us

collaborative activity. Please join us uh to work on the beautiful things. What

exactly we do? We for example answer all of these questions that a lot of us actually still have, right? What is CRA?

What's the where's the official text?

What is not in scope of CRA? For

example, is distributing binaries or container images of open source project considered as making it available on the market and therefore your in scope or or

or not. So there are good questions that

or not. So there are good questions that we do uh CRA FAQ for this and now it has a beautiful website cra.corkinggroup.org.

cra.corkinggroup.org.

Uh you can find some of the questions out there or just Google us. Um what

else we do? Um under the uh OpenSSF which stands for uh opensource security foundation which under Linux foundation we do a lot of brilliant things around security.

uh but specifically uh I am co-chairing this global cyber policy working group which is also working to simplify some of the CRA uh requirements

um to the to everybody actually again we're not limiting ourselves to help open-source maintainers um exclusively or manufacturers we want to help

everybody actually to put them all together under the one table so that we can talk to each other which is actually the core point of the cyber resilience act specifically when it comes to open

source ecosystem it demands manufacturers finally to give something back to open source even if it's conversation it's already a good start

so what we do under this working group we do serial clarifications blog post workshops we have done uh the the recent brilliance workshop in gant in Belgium

actually last week um and we do some tools and etc And the beautiful thing is this CRA free class again you can Google

it easily opens uh CRA class which is free of charge and it provides some basics about the cyber resilience act it's not that deep it's super quick but

then you can get the basic understanding first and also you uh get this nice page you can attach credly page to LinkedIn so this quite nice it's already more

than 5k Okay. Uh people uh have taken this class. Again, this is kind of

this class. Again, this is kind of purely free. Uh and if you want to join,

purely free. Uh and if you want to join, just uh join us. We also have the regular meetings. We have the uh

regular meetings. We have the uh materials that you can learn. Uh jump

us, ask questions. Um we're happy to see everybody. Again, open source is so you

everybody. Again, open source is so you can join whenever you want and do whatever you want.

Now, uh what practical things we do? uh

uh it's I promised that's the uh inside the presentation I'm going to show some practical things not only this overview of the regulation but how uh the current

security practices and tools could be as easily as possible uh and as meaningfully as possible applicable to uh projects and that actually would

applicable to open source project but also to um your own pro uh your own products if you work for enterprise or for companies is first of all I'm going to start with this beautiful projects

also under open ssf which called opensource product security baseline this is the framework basically uh as of last

release of October I think 2025 62 requirements across three level of maturity covering eight areas of security practices but if you have a

look at the slides you can see um among others documentation legal uh quality governance they're not purely

security right it's just good practices that uh I think all the projects or definitely product would like to undertake would like to implement uh just because we all want to do the right

things right and we and I think I mean as a former developer I always think that we wanted to do the quality products right the best in class so this is the best practices uh they're focused

they're only must requirements uh no shoot. So there's no like uh wiggle

shoot. So there's no like uh wiggle wiggle which is good and they're realistic and practical to implement. Um

one example is uh this for example I see uh 02.01 01 when a new collaborator is added to your Git repo for example the version control system must require a

manual permission assignment or restrict uh the collaboration permissions kind of makes sense the list privilege uh principle which is one of the core principle of the security overall right

kind of makes sense to do it actually or to enable this capability in whatever uh your favorite g platform you use um now how can it help with the cyber

resilience act uh would be the next good question. Um actually this is already

question. Um actually this is already existing mapping between the uh open source baseline to the other security fra frameworks that are developed by

NIST for example US um agency that's that's uh throw out some of the security requirements and other technical requirements to other popular frameworks

but now uh the group did the mapping to CRA and for example uh just the one top here um uh OPS uh all compiles released

software assets must be delivered with a software bill of materials as bomb basically which is a good practice to do in general of course but in C actually this is a mandate for sbombs now so all

the manufacturers at least would needs to do to produce these sbombs and this is onetoone connection between the good practice that is written in OPS and the

CRA the same is applicable for uh for example documentation must contain security context It kind of makes sense if you produce documentation uh whether it's open source projects or the

products it makes sense to provide some some context right to report the vulnerabilities um and so on and so forth. So this all mapping uh we assume would be really

helpful for manufacturers and developers and companies and also for uh open source projects that's out there to just okay

I'm implementing uh OPS at the certain level and that would help me like almost 100% to cover the CRA requirement

again this is not one but I'm doing the good things and most probably I'm going to be all Right.

Uh also this all things if you pretend you enable all of these so you kind of do this this this and that all these um

combined may help with so-called voluntary artistations uh or uh how um I personally call it um CRA compatible for

uh projects right for the piece of software um the notion of voluntary attestations actually pretty simple It's um it's intended under the C there is a

special section talking about the voluntary attestations for open source project that basically mean if you would like and only if you would like it's not an obligation but that is possible for

you as a project to um do all of these security practices and call yourself a tested kind of CRA compat compatible. I

don't like compliant because for open source project compliance is not a thing right but I do all of these things and that means I'm I'm good so this is

voluntary attitation thing intended to help them then manufacturers to um to make sure that they consume secure third

parties in their own products simple example uh imagine open SSL right or Linux kernel even or some other libraries JC whatever packages you

consume. Um

consume. Um if you as a company who ingest all of this into your own product, if you kind of can check that these guys do a great

job in security, I think you uh would be sleep much better. So that's the uh that's the intention again voluntary thing that's the goal only for those

projects who really want to show off that they do uh good things.

Um uh this is a good picture actually how CRA compatible may look like. Uh

this is the recently published um GitHub repo. Again you can go and check it's

repo. Again you can go and check it's it's all open. It's all free uh by uh this brilliant person James Serling. they um they've done the whole

Serling. they um they've done the whole GitHub preper with how how this could be shown at the at the project itself at

the GitHub preparate for example how to exactly uh how to exactly write down that the project's kind of compatible with essential cyber security requirements or uh how to produce the

conformance assessment evidence how it may look like with all these markdowns and etc. pretty much nice illustration how it potentially could be done. There

is no standardized way so far how to to do this and this is brilliant attempt at least to get some of the sense how it may look like.

Okay. Uh now uh maintainer um do we have any uh open source contributors in the room who contributes to open source?

Yes. Good. um if you are a maintainer uh how to react or if you're a contributor but close to the kind of project governance and etc how to react remember

I showed you the request that put it that way by ugly uh big company hey open source projects are you compliant actually so how to react for these type

of things uh that could be like are you CRA compliant or provide please security related information about your project uh or some or something else. Uh

consider it as a collaboration opportunity, right? If um most of the

opportunity, right? If um most of the open source projects quite obviously are under resourced and they don't want to do anything beyond um the bare minimum

which is absolutely understandable and I get it. Uh but if you have something uh

get it. Uh but if you have something uh that you are not doing and you know you need help with you can express your interest back and say hey why don't you help with this this and that so that we can kind of collectively achieve this

goal of the good security posture for my open source project because I believe you manufacturer actually reach reach out to me because you consume my product

uh my open source projects right so why don't we do this all better together uh point out to another entity who actually monetize your project that could be also

an opportunity to collaborate. Uh for

those advanced maintainers who are not kind of uh monetizing their project but probably would like to or have the good handles with the companies who do this uh kind of good collaboration

opportunity and there are two examples how curl and the brilliant uh Swedish guy Dennis Danberg does this with the uh commercial company and opens also does

this with their commercial company. So

this is kind of uh two um good use cases uh how to navigate this both for open source project and for the uh commercial offering of this open source project.

Don't be overdefensive. Uh I would suggest to provide gentle I'm not your supplier just in case if you don't want to respond again you you don't have to.

You can just think in your head go away and do nothing. But if you still want to respond for some reason, uh just uh provide gentle response. I'm not your

supplier. And in the CRA FAQ that I just

supplier. And in the CRA FAQ that I just showed you under the ORC working group, we have this template that's also in the

screenshot here. Um like how to respond

screenshot here. Um like how to respond uh with the references to the CRA text itself so that these manufacturers go

away of you.

Um now may if you're a maintainer or just open source supporter uh you may wanted to improve security posture of your product and I intentionally crossed

out this CRA because uh to me the uh majority of the things and the spirit of the CRA is actually good and you know it's supposed to lead to the just good

security posture and the quality product and projects. uh what you can do is the

and projects. uh what you can do is the kind of uh simple things enable uh available security features on your favorite g platform. Unfortunately, as I am engaged to a lot of open source

projects out there, I still see they don't enable uh MFA or they don't enable just the native uh security uh features and all all of these scans that are

offered for free as for open source projects for them at the majority of the platforms of the G platform. So just

enable all of these things. Uh check

security and vulnerability management policy. Uh it's uh often the written uh

policy. Uh it's uh often the written uh under the security markdown file and there are a couple of examples. Uh I

also can can you can follow the link and find them out there. Uh but the vulnerability reporting is the major thing under this series. So we probably

would need would like to revisit this explore security baseline. uh as I mentioned this is a good thing. This is

a just good framework of the good security practices and level one even level one is a really good step. Uh that

is nothing really dramatic uh to do in the level one there again just mostly sec secure by default configurations that you wanted to enable and probably

adjust your your documentation a little bit but uh it's it's a fantastic step.

Now if you wanted to go and these three things actually arguably would be enough for the CRA stuff as I mentioned there is no

standardization yet but we are working on kind of making sure uh there the the bare minimum of the good security practice is standardized in some way so

that it's first applicable to the uh majority of the projects if not to everybody and second understandable by all the parties including in all these regulators and etc. So this top three

now if you are a little bit advanced uh document your security development practices there is the another uh specification or framework that called

security uh- insights.yaml YAML that is basically machine readable notation or kind of format of the security practices that you already do for your project.

For example, okay, this is my um you know my uh I do threat modeling or I do SAS scanning, right? Or I do composition analysis scanning or I do sbombs or

something like this. declaration of the good security practices that you actually do but in machine readable format. Quite nice because it could be

format. Quite nice because it could be consumable by others to actually verify uh very quickly and assess your project if they need to. Open the SEF best page

uh I will go to this example uh a little bit later. um document security self

bit later. um document security self assessment also a good practice um as well as sbombs uh generate and store and there are a lot of open source tools of

course to generate uh sbombs and now you can store and analyze them with the open source projects like guac and trustify for example the again completely free and open source project that you can

roll out either within the organization or for open source project to store all of this sbomb information security advisory is combine them all together in machine readable format and have the

nice picture do prioritization quite nice actually with a even user interface if you want if you don't want it's of course uh supports CLI but it's

it's kind of user friendly thing um and about minder I will um tell you just in a minute now automated uh you can ask the

question okay um there are all good security practices but uh it sounds like a little bit manual work which could be at some extent especially when you're working on documentation and etc. But

for some of the things uh you can automate it uh to to some extent and this is uh one example key clock is actually just open source pro project I

think the most popular and most adoptable open source project for SSO um uh kind of management and identity and access management. Uh but if you kind of

access management. Uh but if you kind of look into the GitHub repo itself, it has best practices page which is um justification that this project

implements all of the security practices, all the best security practices and this is nice on the GitHub repo itself so that everybody can go and

check and of course project can brag about that. Um, open SSF scorecard is

about that. Um, open SSF scorecard is also good project uh under of uh open SSF which is um essentially the job that

could be performed in the GitHub actions for example or another automation and periodically can check that the project utilizes all the security practices and

then produce also the batch within the score and all of the security practices are more or less aligned with what I have been talking about previously, right? Whether or not there are any

right? Whether or not there are any dangerous workflows, do you sign your release if you do binary releases? Do

you perform code reviews? Uh how you handle token permissions which is um quite important and actually uh is the um is the very popular attack vector uh

to through the open source project to the companies. That is how uh my

the companies. That is how uh my previous company got hacked a little bit. Um so this is nice automation that

bit. Um so this is nice automation that you could uh implement to the um to the project whether for your own uh project in the company or for the open source

project.

Uh minder uh another brilliant tool under opens and also open source completely that actually implements some of the uh automation out there so they

can roll out some of the policies. Uh

and on the screenshot on the right hand side you can see the YAML files with these configurations for example actions check default permissions uh check pins

tags um you know uh salsa which is uh the the uh framework and standard for provenence for the software. So this is

this this tool can help with automation of all of these good practices that you uh may already uh implement within your projects and open source of course.

Um now uh finally uh why we care as a Red Hat about all of these security things and most importantly about the CRA things. Uh that's actually a good

CRA things. Uh that's actually a good question because we as a company um occupy the weird position uh under the cyber resilience act. We are a

manufacturer because quite obviously we are a vendor of enterprise open source software solutions. think of rail

software solutions. think of rail operating system or open shift uh our cloud uh platform right but also we are open source software stewards uh because

we uh host some of the most popular open source project and support them like Fedora for example operation system oral lama recently and something

like this so we are steward remember this roles right and this manufacturers stewards and also redartters are contributors and maintainers ers for the thousands of

open source projects out there starting from Linux kernel and so on. Okay. And

we also try to lead the efforts on this space. What I've taken uh today is

space. What I've taken uh today is already uh channeled through the standardization efforts and the U official uh officials channels so that we make sure that those good security

practices are actually incorporated in the meaningful and reasonable way into the regulation and the standards.

Um on the positive note, right? Um

hopefully you're not that scared so far.

Uh on the positive note, why CA CRA is good. This is like a compiled message

good. This is like a compiled message that I keep hearing from uh some of the security experts that I talked to and also represent my personal position. CRA

uh actually has a potential to make more for supply chain security and finally aims to fix this problem at scale just in a few years because we have

deadlines, we have this pressure.

Then we as a security experts were lurking uh behind the engineers and trying uh developers to convince just to do the good security things right. So

CRA is naturally a good thing but of course we'll want to make CRA even better uh because that goes far beyond compliance again that's why I jumped

into this activity I'm not necessarily compliance person right but CRA also goes beyond the compliance because uh regardless of your role steward manufacturer maintainer just developer

uh you probably want to join this effort to make it all right right as to make finally the the kind of could uh in collaboration make it all right.

And you can read um other statements uh in the Red Hat Cray blog uh that we do uh also kind of uh good good to good to good to know what what we think about

all these things and takeaways. Um would like to uh leave

and takeaways. Um would like to uh leave you with uh a couple of takeaways. Um do

not stop contributing and support open source because of the CRA. This is the major takeaway, the main one, right?

Please continue to contribute as I showed you. Likely you're out of scope

showed you. Likely you're out of scope actually uh at least as a person, right?

Definitely learn and educate others in uh the community. It's actually free for most of the cases as I showed you classes, you know, and other uh avenues when you can collaborate and learn. Take

is take it as a call for improving quality and security posture for open source. Join community efforts. We need

source. Join community efforts. We need

your voices. This is super important because otherwise we don't know whether what we are offering and what we're working on is applicable to you your

case or not. If it's not, speak up. Join

our efforts. Ask these questions so that we have more voices in the community and opportunity to answer these questions and to address these concerns and again

to make it all right and act now. Uh

this is not like a very long time before uh it all kicks off. uh by following good practices already and automations and tools that I just showed. If you are

like a person who wants to listen not to uh watch uh or read uh there is also a podcast that was recorded um by by me

and uh with with me and Emily Fox also from Red Hat hosted by Mike Sham. This

application security weekly great podcast in general I listen it actually for quite a few years. Uh you can listen also some of our thoughts about CRA there as well.

Um let's build a secure future for all and in open source way in collaborative way. Um

way. Um I hope that was helpful. Thank you very much.

>> [applause]