All right, hi, everyone. My name is Tobi Nongen. I run a small consulting firm. In
right now, I'm very focused on helping the Clips Foundation, implement the CRA, was the
open regulatory compliance working group. So initially, I thought I was just going to be
able to give you the same slide deck as I gave you this week, but then we decided
to sort of like change the organization of today. So you still get to see the picture
because I think the picture kind of like says a lot of things, but I kind of want to
give you an update of where we at and how the open RSE is really dealing with this whole
process. So I'll address like five topics, the key issues we've done the way, the consequences
of those issues. I do have some good news. I'll give you a quick status update of what
we're trying to fix. And then like some key learnings, which I think I use full for us, but
just more broadly. So the key issues that we bumped into really quickly was a knowledge gap
and an awareness gap. So first we really saw the knowledge gap because everyone was kind of
like scrambling to figure out what the CRA thing was, you know, myself first. And secondly, you know,
as we move through the year, we realize that like a lot of a lot of folks just like didn't even
know the series was a thing or what it meant to whether it impacted them or not, right?
The third issue that we really had is that open source is just unused to top them.
We're used to like scratching our edge and getting together to do that, but they were essentially
told by an external party, you have this edge to scratch and no one really knew what kind of
edge it was or where was itching or felt the edge. So you know, that created like this kind of like
lack of a sense of urgency that was really, really hard to go through. And then lastly, you know,
there's a mismatch between a house software is built in general and how some of the institution
in the EU are structured by no fault of anyone. This is just historically things about
some institutions are way older than software and hence that adds a bunch of friction.
The consequence is, well, I mentioned no sense of urgency already. The second point obviously is
very few experts, right? I mean, the sheer fact that I'm the one running this thing, I mean,
should like be a big tell, right? I'm scrambling. We're all scrambling to try to figure out
this completely new field. And then the third point is sort of the ideal solution situation here
would have been, you know, manufacturers coming to open source was clear requirements of,
hey, we need to do due diligence, these are the things that we need. The problem is the open source
system ecosystem is a little ahead of the curve here and the manufacturers really don't know
what they need. So we have to kind of like figure out this together,
you know, building the plane as we fly it. Good news. This is news for everyone, right?
Everyone everywhere and every meeting that I've been in, whether it's in the institutions
or whether it's, you know, in the standardization organizations, everywhere, we're, you know, in
ourselves, we're trying to figure out this completely new thing that is regulating software.
And so, you know, I think some of the outcomes of that is like show each other some empathy and some
understanding. And that's also, you know, going to get us a long way faster. I mentioned this open
source because the CRA encroached on open source and that kind of raised a panic,
um, an important panic in the open source communities, um, we're just, you know, we feel like we're
very far behind, but we're actually a little bit ahead of the curve here, which I find like really
interesting. And then yeah, the last thing that I think is really important is everywhere, um, you know,
despite seeing, seeing scrambling, I've also seen like a lot of willingness to collaborate
and figure out ways to work together and to move forward. And so I think that's really, really,
that's just really beautiful, so very happy about this. Um, so status update, um, I think we're closing
the awareness and education gap. Well, at least we had like starting to have a sense of how to do this
and we're starting to execute on this, which is really cool. Um, second thing is we're finding the
right way to communicate because it's really difficult to just figure out how to, how to, where to talk,
how to talk, uh, what to say, et cetera. Um, and then, you know, in the, in, or I see itself,
I think we're identifying the right deliverables now. Uh, we're understanding, uh, we're understanding
how to deliver them, went to deliver them and also to whom, right? Um, and so, my key learnings
is the first thing is you have to do parallel tracks, right? There are a long term things that we
want to fix. Uh, for example, like quite clearly the standards organizations, uh, the European
standard organizations don't fit software very well, right? Can't fit this, we think we can
cannot fix this for the CRA. We have to have a long view on this and there are mechanisms for this,
there's a revision of 10, 25, et cetera. And we can be effective and do work there, but at the
same time, we have to figure out real room and ways to work on the CRA now. So there's these two
things that we must do on parallel. And I think it's super important all the time to try to
figure out, like, okay, what's the long view here, like how can we work on the long view and what's
what we need to focus on right now to solve this specific problem. Um, then, um, yeah, this is chaotic,
but there are opportunities in chaos, right? We have to embrace it. Um, you know, and I think, uh,
uh, a presentation was, uh, bored before really shows this. Like this actually, I think was really
useful for a bunch of people who saw some really nice slides. In the past, you just see the whole
thing again on a whiteboard was a completely different perspective. There's just a tiny example,
but if it's chaotic, like, there might be, uh, things to get out of the chaos. Um, and then
focus on best possible outcomes, right? Like, we're not going to get things perfect where, uh, let's
not get lost in, um, in trying to make everything perfect. Let's try to make things, like, not bad.
And that's, that's like a, that's a win, right? Um, and then lastly, and I think that's the most
important, and I think this is why it's amazing to have all of you here. It's all of this is at the end,
it's about, it's about people, um, and like the best way to fix and to make this work is to build
bridges and work with others. So that's, like, really my, you know, if there's anything, I want to,
you all to remember it's that last thing. Um, and that's it. Thank you. Uh, you can come in the
help us, uh, uh, here. No, no, I know, I'm putting this away.
then we then have all worked up with Toby is going to be leading. So, uh,
between the lines, hello.
We get involved, so they don't receive it for the flow, that's simply a thing there.
Hello.
Thank you very much.
Thank you.
Sorry.
All right.
What much does it be asked?
Okay.
And...
So if we could finish off the rum change over quickly, that would be great.
Do take a seat.
There's two spaces in the middle there.
You'll sit on the stair.
Okay. You'll come behind.
Hold it right here.
Yeah.
If you want to be on the video, you have to stand in this box here.
I don't want to be on the video, that's why don't care.
Okay.
So this section is a panel, and the question that this panel is wanting to examine is what
are the lessons that we've learned over the last year from taking forward the legislation
that you're representing?
So in particular, I'm fascinated to hear Philippe, what your experiences of working with the
urban source community have been on what lessons you've learned.
Clearly, you can see that it's made a big difference.
And then I'm also interested to hear from your team, have you heard from the open source
community?
What lessons have you learned about open source this year?
And Toby, if you could proxy the people who aren't here from the AI team at the commission,
that would be great.
But if you can't, don't worry.
Okay.
Sorry.
So the first question to whichever you would like to take it is, your team came to foster them last
year.
Was it any use?
Oh, yes, Mike.
Oh, Mike.
So I'm a big fan of stakeholder engagement, and I feel, so I like this concept of policy
making us permaculture.
And I think what that means is you need to plant things in advance so that when you're ready,
when you need it, you can, you can sew them, you can collect the fruits.
And I think stakeholder engagement is like that.
It needs kind of a constant attention.
It should be low maintenance, like any good permaculture garden, but you need to be there kind of regularly.
So that it's ready.
It's always fruiting throughout the year.
And I think that's what we've been trying to do as much as possible with open source folks
in a number of different ways.
And so coming to foster them two years ago, and then last year, and then again, this year is a part of that.
Another thing is that in general, for policy implementation, a lot of what is needed is a development of societal structures.
And of course, it's really nice to have a very decentralized and a bit chaotic community going on.
That's really important.
But in order to facilitate top-down communication, which is also a part of life,
it's necessary to have certain structures.
And these structures need to be perhaps more dynamic if the ground is very chaotic, but they need to be there.
And so I think that's also part of maturing and developing social structures, specifically for open source.
But in general, for everything to do with product security, because for this year in particular, it's really the first time that product security becomes mandatory.
I think in many ways, this is the same for my colleagues with platform regulation or AI regulation.
And so I think it's really about how do we develop the social structures that are going to facilitate and support the dialogue of all social stakeholders.
In order to help that to participate into the more high-level regulation processes.
Thanks.
How have you found it on the DSA team?
How has your engagement with the open source community been?
I wrote.
So we are not very software-oriented.
We are more in the functioning of the platforms.
I will say, so it's more about transparency of the practices of the platforms and the data access.
So I said that we, the DSA introduced many new data sources, like the advertisement repositories or, for example, the transparency reports, etc.
We are also engaging with the community, so we already had, I think, if I'm not wrong, three open.
Yes, sorry.
We already had three open consultations for three of the implementing or delegated act that were, so the implementing the second level legislation that came with the DSA.
One, it was for the data access.
One was for the transparency data basis structure.
So the schema to put and one here now, it's about the, so it was the taxes, transparency, and then there was a third one about the,
the embedded researchers, for example, the definition of the researchers.
So I think we are more engaged in with the civil society organizations, etc.
Which are, yeah, let's say, checking or monitoring the effectiveness of, for example, of the take-down of illegal content or it's speech.
But we are indeed, I mean, we are indeed meeting with the also open source foundation members, etc.
Yeah, maybe we use a lot of open source in our day to day work as a wish show, and yeah, maybe.
Have you had very much feedback on your thoughts in life?
Yeah, I mean, it's not very popular yet, this data source, but we have some feedback.
As I said, we are very open to any contribution from the also the word.
I mean, it's there to for you to pull a push request, pull requests or our penishes.
I don't know if you want to compliment.
Yeah, I'm just a few bits.
So it's a tool, we are at more engagement with the academic communities, resolution and open source so far.
But open source and all the tools and the software is also like super useful for our daily enforcement work.
And one aspect that I would highlight as well is we are providing quite a lot on food party, data, notifications,
be it like CSS or researchers.
And the fact that we can build tools in the open source is also a way to level up and to ensure that the practices from these communities.
At the highest level and that we can like the data which is coming from these communities or from these built parties,
be it like CSS or on journalist or researchers can actually be useful afterwards in the enforcement pipeline.
Because we are built on robust software, robust methods and something that we can vote for.
Thank you.
So I've got a question here from the matrix chat.
You would like to run into the matrix chat as far as this way to get it out.
So in the matrix chat, pink out asks, is there a way to provide input on the fundamental choices related to the standardization process for the harmonious standards of the CRA,
especially when it comes to the pitfalls of integrating the EUCC certification scheme?
Sure, thanks for the complicated question.
But I hope to have a simple answer.
First, I think the CRA, the Cyber Resilience Act is the first legislation that covers all products with digital elements and what that has shown us when we look at existing frameworks of product security,
is that underlying all of these products frameworks despite the market fragmentation of all these different frameworks and standards,
at the end of the day, good security has the common set of practices.
And it's actually always risk based.
And that's really interesting.
So you always start with your risk assessment.
You always start with your security problem definition or your intended purpose.
I mean, give it the name that you want, but this is how you have to start.
So in order to, so what is a good standard?
It's actually the same as what is a good protection profile or a good scheme.
It identifies risks and it proposes mitigations.
And I think from now on, my job is just going to repeat this whenever people have questions.
Risks mitigations.
That's all we need.
That's all we're looking for.
That's all anybody needs to give.
So that's what I hope that we can all start thinking about very systematically and coherently.
So having said that, the CRA, the Cyber Resilience Act also has provisions for, sort of, integrating the existing certifications,
schemes, the EUCC, common criteria stuff into its regulatory fold by giving them also this so-called presumption of conformity.
But again, the presumption of conformity would only apply to the extent that, for a given use case, the risks identified are correctly mitigated.
So it's exactly the same reasoning from the standards and the protection profiles.
So we're engaging with, with industry and which stakeholders both to develop the standards and to update existing protection profiles in their common criteria.
So it's really sort of similar track even parallel track.
In some cases, the protection profiles from common criteria can be updated as part of the standardization work.
In other cases, the updating of protection profiles can happen separately and can then be sort of copy-pasteed into a standard.
So it's really like very much sort of two sides of the same coin.
The processes are going in parallel.
If you're interested in common criteria, you can do exactly the same work as if you're interested in just the standards in general.
Thanks.
Thank you very much.
There's a question from over here.
Well, actually, I may, I give a statement in which I call an assistant.
Because actually, when I call an assistant, you see.
Yes, well, my name is Sebastian.
I'm, well, I start, I do, I do free software longer than Linux exists.
And I happen to be employed with Red Hat, which is one of these open source product development companies.
So point here is that I see a broad misconception actually in the way that we talk about open source as something.
Well, the misconception is that there is the community, the development part that is basically collaborative and opening up lots of opportunities for example for competing companies, but also for individuals to create something.
And there is the other side, the consumption part, which is much bigger.
And the problem that we are talking about, for example, with the cyber resilience, is mainly a consumption problem.
It is that people do not understand how the open source, the open source, the source code software boils down.
And tickles down the, the past to the consumers and the problem lies in the artifacts that these consumers typically use.
And the release management and the patch management.
And, you know, all this stuff that is in between the upstream and the consumption.
And trying to regulate to solve the problem for, on the consumer side, by giving oblique making obligations to the communities.
Simply doesn't work, this is the wrong address, see.
And so the problem is that those that consume open source at large do not quite understand how this whole thing works.
So at least this is my, my take of this whole story.
And so yeah, well, I think this should be addressed somehow.
And even if we go to the, to the, to the AI, and the question, what open source AI is, this is, if we, if we get the better understanding of the, of the consumption and the creation part.
So contribution into those models, having those companies that provide the stuff.
Open to, you know, for, for actually cooperation and contribution.
This is the point that makes this whole thing open source.
So do you have, well, is there, is there any idea, do you, do we have plans to enter the notion of, the, the consumption, the artifact release management part into these whole stories.
Thank you.
Hey, thanks for the question.
So in general, the cyber resilience act puts responsibilities on the manufacturers or developers, but it's actually part of a bigger picture of shared responsibility.
I wrote that on the, on the board while you are asking your question.
So it's, so you can see it, for instance, in conjunction with other legislation that put specific risk management obligations for instance on certain critical users.
The critical infrastructure owners, that's the NIS directive.
And in general, I very much agree with the idea that, you know, there's a huge space between the developer and the end user and all of this space needs to kind of start to mature.
The communication needs to be structured to make it efficient.
And that is kind of what I was saying in my initial statement that to implement the legislation, we need the social structures to be in place.
Some of that are more regulatory, others are not fully regulatory and that can be a good thing that civil society can just respond in an effective way.
But for the CRA in general, there's a lot of emergent benefits because it covers the whole supply chain.
Everybody has to respond at their respective level. Everybody just has to listen to the level below for the level above.
And that way is kind of sort of reduced scope to what everybody has to do, but if everybody does that and everybody does have to do that under the regulation.
Then you're going to have the big picture and those emergent effects can already happen.
I've been calling for exactly what you're saying for the people who are standardizing these horizontal standards.
Tell them, please notice that the CRA covers the whole supply chain.
We need to facilitate, we need to produce the frameworks that are going to facilitate the communication across the whole supply chain so that this is easy and simple for everyone.
And they struggle, I have to say, it's very abstract for them, it's very high level.
But okay, we're getting there after a year and a half, it's becoming clearer.
I've been talking about this notion of risk levels as a way of defining certain kind of categories of use cases and to communicate that throughout the supply chain.
This piece of software is, you know, secure for low risk use cases only.
So if you have a high risk use case, you shouldn't use this piece of software.
You can use other piece of software that sort of discover high risk use cases.
That would be a simple way in my imagination that you could perhaps sort of start to structure the communication across the supply chain.
It's just an example, it's not like law, but, you know, we need to develop those market practices.
We need to develop that social structure that will facilitate and all of that communication.
Thanks.
I do not know where the NGA level, but it's a corporate level.
Yeah, I know.
Consumers are corporate.
So the social structure is industrial is public sector is corporate.
So as I said, right, there's actually legislation giving cybersecurity risk management obligations to all of the critical corporations and entities.
And yeah, I don't think the CRA applies to all of the steps of the supply chain, knowing that almost all of them are corporate.
In fact, all of them are corporate because the non-commercial local consort is fully excluded from the CRA.
So, you know, actually all of them are corporate.
So we're running to the end of the session here.
I've got one more question that is actually completely different place to that, which maybe Toby would get us started with.
So we've had a question in the RC from Teaspoon RC.
Is it possible if not too complicated for a new be in the area to have an explanation of how the CRA actually works in practice?
So for example, as an engineer, I produce a product, who should I contact to make sure my product is compliant?
Who is the, who are then, how do I find them?
How have they got the power to verify that I can put my product on the market?
I think that's the shape of question quite a lot of people have asked me.
Yes, it is. It's also, a lot of different questions was a lot of different answers.
At the same time, I'm going to try to keep it short.
I think right now, a lot of this is being defined.
And so being a new be in this space right now, if you want to enter this space and see how things are being made, I think.
Well, I mean, of course, we're doing a lot of this work at RC was an FAQ and really trying to collect those kinds of questions.
And then break them down to have clear answers for those.
So I think that's one way of looking at it.
And I think as we move forward into this implementation phase and into the application phase,
well, first of all, the commission is going to issue guidance on some of these topics.
So I think that's going to be a place to get answers.
And then, yeah, I think maybe you want to add a few things about this.
Yeah, thank you very quickly. I think to take a step back before answering to say that this kind of question is exactly.
So once the development of those social structures that we're saying that are needed to support the implementation of legislation,
people need to know where to find answers.
There needs to be a place where people can look at this.
Some clients look like, and the first thing I need to say is that the legislation has just been published.
Last month, it's just entered into force.
And so at the moment, we are still at the very beginning of the transition period.
This is actually the moment of highest uncertainty, which obviously is uncomfortable right now.
But that means, you know, every single week, we will be working to reduce that uncertainty as we work on guidance, as we work on implementing legislation, as we work on standards.
And of the three year transition period, there should be a lot less uncertainty and everything should be a lot clearer.
So, but for now, if you're looking for information where do you go?
Well, look at commission websites.
Look at commission funded projects like cyberstand.eu that I've written on the board there.
Look at the other social structures that are setting up, specifically gearing up to answer to this.
The Eclipse Foundation has set up the ORC, open regulatory compliance working group, which is an initiative that we welcome a lot,
because it meant to be a place where different open source actors can come together and have those discussions of how does this CRA affect them, apply to them.
So, get involved in the initiatives that are already trying to sort this out, basically.
Thanks.
Great, thank you.
And so to be clear, you're hearing all the questions we're answering, and you're going to be publishing some written guidance that addresses some of those questions.
Over the year, not least because the CRA says you have to.
Yeah, exactly.
The CRA says we have to, so we're going to do it.
Okay.
So, thank you very much indeed to these speakers and panelists.
Thank you.
Thanks.