Please take your seats as quick as possible, we are starting.
Can you take a seat please?
Yeah.
Good.
Thanks very much.
Guys, take your seats up there.
All right.
All right, guys.
Take your seat please.
Thank you so much.
And we are moving on.
And that's going to be a lightning talk, but, you know, the last one.
Of course.
The next up is Sinti and Casey.
We'll talk about building Sierra Rady open source communities.
The critical role of community managers.
So important one.
Please give all the applause to the next speakers.
Thank you.
Hello everybody.
I am Sintiya.
I'm a PM at GitHub and joining me today.
The super lighting fast talk is Casey.
Hi everyone.
Casey, I come here as an independent person.
Yeah, but I'm working with World Health Organization.
WHA on open source related work previously on healthy emergencies.
And now on medical records related things.
So very happy to speak to people about that.
But here today on an independent capacity.
Okay.
Sorry about that slide.
It seems like everything had gone wrong.
But please excuse us.
And also, excuse us if this has already been covered.
But I thought if everyone is bit like me.
And sometimes bit confused what like CRA actually means.
And what it covers, I thought it might be helpful to start with bit of very, very brief context.
So CRA does introduce what they call like mandatory cyber security requirements for hardware and software product throughout their whole life cycle.
And we'll talk about what that means in a second.
And it is meant to complement European cyber security rules and strengthen the security of the whole what they call supply chain.
So in the recital which is if you ever look at the actual legislation.
If you ever go to the exact source on European Commission.
Anyone have trouble how to navigate that.
I'm very happy to support you on that.
So what in the recital which is the first like line items that they give people it goes into act which is like actual law so to say.
So it's mentorship cyber security from a post market issue from to a regulatory obligation that's embedded in product governance.
And it's meant to treat cyber security as what they call collective supply chain responsibility not just the manufacturer concern.
I saw from the previous question that like that someone mentioned that our clients would be considered manufacturers on their cyber security.
Cyber resilience act and so on.
And then very briefly we'll talk about the scope of application for CRA.
And to that the most important thing the bottom circles like cut but that's meant to be open source stewards.
Like yeah, unfortunate but like that had happened.
So it does so how it applies is like twofold one is like what they call in a covered product categories.
So they specified and like it's basically connected hardware device and examples like IoT network equipment.
And then software that's embedded and connected devices that's the wording that they use in the legislation.
And then also like non tangible digital product basically software where supply that's part of a product with digital element.
And then it does have some exemptions so one is basically like if it's covered by other regulations that's often more strict.
Such as medical device for human use and accessories for such device that's a regulation you 2017-746.
And then another is the IVDR in vitro diagnostic medical devices for human use and accessories for such device.
They often have even more stricter requirement than the CRA so that's mentioned.
Another is if it is already if there is already like a comparable certification scheme.
And then another is the product that's developed exclusively for national security defense or military purpose or processing classified information.
And then the other ones I thought it might be a bit more interesting like unfinished product prototypes but then provided like you have to make it very clear that this is a prototype.
And then also mentioned that this does not comply with CRA.
And they're placed on the market solely for testing and says that's covered by other kind of legislations.
And then I will quickly, how much time?
Yeah, okay.
Oh, sorry.
And then another bit like how it's applied is that they use a term called economic operators.
So as in like a product is placed in the market as in it has a commercial bit to it.
Like so that's what they meant by economic operators.
And then it does have three different categories of that economic operator.
One is like manufacturer, the ones that manufactures and then another is the importer.
And then another bit is distributor.
And I'm sure like it's like preaching to the converted like to talk to people in this room.
Like where does the open source of stewards or community fit?
And that's the term that they had introduced here as well.
And I will just like we wouldn't have time to go through the obligations that they have set out for different categories of economic operators.
But we'll quickly just talk about the obligations of manufacturers.
So there's a general obligation and a reporting obligation to that.
So the general one, one through like I would say two.
It's like a normal healthy software like development lifecycle.
It's like yes cyber security is taken into account in planning designing developing sort of thing.
And then there is quite like heavy reporting obligation which if we have time like we will like get to that.
But then other like interesting things are the like how long that that this should be ensured that basically the safety of the product should be ensured.
And how long the security updates should be made available once the product has been placed into the market.
And then another bit like number five which I thought interesting very clear and understandable instruction for the users.
And then reporting bit also interesting.
It does have a quite like stringent timeline on like as soon as the manufacturer identifies a issue.
That like within 24 hours to inform the like sister or any or any about the vulnerabilities.
And then as they mitigate like work on it like patch it the vinyl report to be made available within like 24 hours.
And then we'll like talk about the specifics like with the like false community of sorry.
There we go.
Yeah.
So when the proposal of the legislation was introduced in 2022 and the vinyl version introduced like at the November of 2024.
There had been a lot of advocacy or like work from the open source communities like if you were to actually read through and compare the two legislations to drafts like it's quite different.
And the specifics on the open source like this is the best place to look for that would be article 24 like that's dedicated space for that.
And then it is asking to establish and document of very viable cybersecurity policy and ensure effective vulnerability handling.
It does not specify how or what it should look like but then it does say that.
And then um, cooperate with market surveillance authorities.
Um, I don't know like if people had heard about this term, it's a term that had been also like introduced there.
So market, market surveillance authorities are meant to be national ones and that's chosen by each member state and the European Union.
And they are to ensure the implementation of the CRA.
So each member state can choose one or more existing new authorities and such.
Um, okay.
To me, oh my gosh, okay.
I'm so sorry.
Yeah.
And um, with that I just want to, I'll skip this slide.
The concerns that had been raised.
But just want to end with the point that like for open source communities, what CRA.
At least like from the law, what it actually values is the evidence of process, not necessarily perfection.
And yeah, with that I'll learn to Cynthia.
Awesome.
Thank you.
I don't know.
All right.
So I'm going to go through.
So I want to highlight a little bit more on.
Thank you for going over about CRA.
What it means.
Um, and as you know, we have to December 2027 when it's in full effect.
Um, but I want to highlight some of the concerns if anybody here might be a community manager or a maintainer for project.
Here are some concerns that community managers had highlighted with the CRA.
Of course, I want to highlight the CRA really values the evidence of the process and it just has to be completely perfect.
There is time right now, but we definitely want to get started.
And also there's some concerns for the community managers that might feel that downstream.
So companies, manufacturers might push questions upstream to the project.
So you want to be able to reduce uncertainty.
Um, ahead of time as soon as possible.
I know the thing to consider is, um, being able to really support the maintainers and support the community under the area.
So these are the concerns that the community has, both the fear of burdens on the open source software.
And of course, the cost community really has done a lot of advocacy.
So it's really great.
Um, and there has been updates to that desk.
Um, it was mentioned earlier.
Um, and to go through with the timing that we have here.
I want to highlight.
It's going to slowly.
There we go.
Some things, um, to really be ready across the project as we're scaling CRA readiness.
Of course, this is not legal advice.
I'm not a lawyer.
I'm not your lawyer.
Uh, so I just want to highlight here are some things that you may want to consider when you're preparing your project to under the CRA.
So of course, um, first figure out if your project does fall under the CRA.
I believe there's a couple of really great tools out there for assessments to see if your project would fall under that.
Of course, think about also organizing.
Um, your repo, your projects to have all CRA related documents.
And you're contributing file in your repo somewhere where new.
Um, uh, contributors can figure that out somewhere where it's very clear documentation.
To reduce any confusion in communication.
For any CRA related documentation, whether this is what happens.
This is, um, the type of verbiage that you always use.
So with that also consider perhaps using issue templates.
Whenever there is a security, um, vulnerability, any vulnerability,
vulnerability reporting, having templates that have the same across, um, your project makes a little bit easier for new contributors to join.
And I have zero minutes.
The last thing I want to highlight is clarify the role between your technical writers and the community managers.
So it's very clear who will do what when there's a new version that comes through during onboarding.
Uh, thank you so much.
Uh, we ran out of time.
And, um, it was all virtual.
Thank you very much, ladies.
That's fantastic.
The best presentations are given when the technical things go wrong.
I mean, that's, that's great to overcame this.
Please give it another round of applause.
That's, that's just fantastic.