Hi, everyone. Welcome to the next talk, CRA integration. How to use open source tools to ensure
your company is compliant to this cyber resilience act. Welcome to Florian Hackel and Anika
Kaniman. And thank you and welcome from our side. We are very happy that we are
allowed to speak here today at first. First of us, I'd like to introduce us my name
as Anika Niemann, my colleague, Florian Hackel. And we are both lawyers and work at a law firm
in Germany. We are something about 25 lawyers there, all specialized in IT law and the most
of us with the focus for compliance. But we also advise on the CRA and on the I act and
everything related to IT law. And today we want to talk about how first compliance measures
support CRA obligations. Okay, we want to start with a short thesis. In general, our aim for this
talk was how can first compliance support CRA readiness. And that is also the picture that you can
see here in the background from our point of view. There is an issue or a topic that you can use
your already existing first compliance to get ready for the CRA and that is symbolized by this
bridge. And that's a very interesting thesis. And we thought we would like to offer you a special
experience today and give you a short insight and our everyday work. And that's why for the next
20 minutes, I will be a manager of a company with many questions through my lawyer, which I have
to ask regarding the CRA. Okay, well let's start. First of all, let's quickly frame
why first compliance suddenly matters so much more than a few years ago. Okay, so it's not
any more just I don't want to get sued because of some copyright stuff, but it's more now.
Yeah, today leaving exposure all the comes from the security vulnerability and especially in
open source components because most of all, so proprietary code is open source now. We all know
that. For example, think about a security system of a company that gets hacked because of
a small vulnerability issue and an open source component. You have the manufacture are
liable for that. Everyone with you and wants your money for that. Therefore, it's really important now.
Okay, so not only copyright issues anymore, but also product liability. Yeah, even before this
year A, there are already many customers or suppliers, things like that that have in
their contracts, indemnification clauses, that assume that you as the manufacturing
are actually now, which was used and on which license as you use it. And you've already mentioned
the CRA, so this is the pivot point of all of this, correct? It is. It goes on top of that.
Now with this year A, you don't only have, with a contractual obligations, but also
regulation basis, where a thumb on, for example, an official attended entity can
get it forth, all the obligations. There are fines. It's even a market entry point if you don't
for through the regulation of CCRA. So a lot of a company has to oversee here.
Yeah, and that's only about your own stuff. If you have a supply chain with a lot of suppliers in mind,
it's getting even, I would not say worse, but more complicated, because you're not only
responsible for your own stuff, but all the for everything that comes from your supplier.
So what I fear is this huge amount of regulations, because I mean, this is not only to
CRA, but we have data protection law, we have the IAC and to be honest, I do not even know where
I can start here. I think that is a point where most of you and our other clients are struggling,
because they all see these imminent threats of different regulations coming closer and closer
without any idea what to do. But the good thing about them is they're all on the same basis.
All of them tried to aim in a similar direction or one-time obligations to be fulfilled, therefore,
if you know about the regulations. And now, how the interact, which is other, you can get
summaries of obligations and perform them to fulfill different specifications of all the regulations.
One example for the GDPR, NCRA both asks for privacy, security by default, or privacy by default,
or by design, and both of them can be fulfilled by a good technical execution of your software,
creating an S-form, things like that, and that helps a lot that you don't have this
mass of regulations that you can fulfill. So I see there is an overlapping, but it's not only
only this huge amount of regulations, but we also have many, many tools. And if I understood
you correctly, we have to classify all of them to be sure that we are compliant. But again,
I wouldn't use all the software or treat all the software the same way. I would try to funnel them
as we describe on this picture and to start with, if you don't have anything in mind yet,
start with an easier attempt. It is three-dimensional from our perspective, and I would start with
the customer risk, though, everything that goes to your customer first level. Every step you can perform,
S-form, evaluation manually, automated, everything you can think about it, do it. On the other
hand, pecking to a third level, you have, for example, the in-group stuff, everything that goes to
sister company, mother companies, a bit of effort, but not that much, and everything you use
internally, I would not say forget it, but see me automated process with a bit of documentation
should be enough. And if you want to adjust this, would they rather an easy level system,
then you can include, for example, points like do a half a supply chain. There are a lot of
suppliers here, one, two, three, then you have to level up your project because it's much more
difficult to get all the necessary information or do you have code from one of your own developers
with five to ten components, that is easy to handle. Okay, I understand it's a risk,
page approached approach, so to speak, and I can focus on the high risk products and spend all
the effort on them and all the others come later. Let's correct, let's see idea behind it, don't
get panic, try to funnel for the relevant projects, spend much of your effort, you write your
80% into them, document the rest, if one of the officially departments come to ask you for that,
but in the end, don't treat them like every customer software you have. Okay, so that already
sounds much more manageable for us, if you pay attention to the high risk products at first.
Okay, the next thing is when we talk about risk levels, you have this assembly line.
Yeah, exactly, I see the assembly line here, because I need a, I see this assembly line,
but what I need beyond this is a guideline, I need to know what I have to do for the single
products we produce. That is where you need a positive framework, because the risk level is only
the first level on your compliance process. When you have the risks for your product, is it's
really relevant to evaluate, okay, for which of the risks I do what, um,
procedure in the end to fulfill the specifications. Um, with our first example, level 1 to 3,
level 1, you need the S-bomb, you need, um, the cybersecurity team to evaluate vulnerabilities,
you need it, if you go a bit aside from the CRA, a legal team though, me and my colleague, for example,
to evaluate, do you have licensed preaches? What about the interaction of components? So a lot of
work, a lot of effort, but everything should be in this policy framework on the other side,
third level, um, bit of documentation that should be good enough. So the, the compliance level,
um, must be, must be graduated, um, depends on the, on the risk level.
Um, that's right, that should be the result, and when you have this technical level of your compliance
process, the third step should be for each, pre-feature or step of this, um, compliance or
policy framework, you should have concrete rules, who do what? Now, it's relevant that each of
these step is, um, uh, pointed to one of the persons in your company. For example, the S-bomb
should be created by the deaf team in this year as a deep pipeline. Um, the vulnerability check
done by your security team. And, um, yeah, the legal point, easy to handle, the legalist,
like us, we'll do the license evaluation. Okay, so let's think about this perfect world.
Um, I, I'm in line with all the regulation you just mentioned, but I'm a little worried about
the following situation. The authorities are knocking at my door and asked for proof that I
fulfill all this regulation. So it says some way, I need to document or I need to, um, provide
information to them. And it would say the, the most legally answer would be document everything.
So if you can from the first step to the, the S-bomb, to the evaluation, to each decision,
your legal, your security team performs, document them as good as you can, at best at one
system, that you have everything ready and available if one of the authorities or, uh,
third party asks for it. But, um, and now this is a bit of a hard attempt if you don't know
what to do, but there are already great templates. You can use for that. For example, the open
chain security assurance template or ISO 5203, all of them are from our point of view, um,
an audit ready structure for espontaneration and false processing. Okay, thank you. Um,
I think I get an understanding. So let me sum up, um, this strategy you just, you just
developed. So first of all, um, I know I understood that I do not have to analyze all my products the
same way, but I can start with the high risk products and then, um, focus on the lowest, uh, low
risk products later. And, um, you agreed there are many regulations. However, um, there are, um,
overlapping means, uh, with a single measure, I can cover, um, different, uh, different rules
and different regulations. So that's, um, less effort for me and for our company. And, um,
based on this understanding, I have now, um, an idea comes up because we already have, um,
false compliance strategy. And, um, here we use, uh, common, uh, scan tools like
phosology or the odd scan. Um, and only for the high risk products, we switch to commercial,
uh, options when we need this depth and analyze. Um, and what I also thought about is we can, um,
get in touch with our open source product, uh, project office, uh, Ospo. Um, because they know
the code very well. So they can analyze the code. They can, um, help us to create the, uh,
as well and also, um, can support, um, regarding the documentation stuff.
That's all it's good. Um, um, okay, great, because now I started to see a picture here.
But, uh, we haven't spoken about another point yet. Um, and, um, this is, um, security. Um,
the thing is, um, even if I know my code, how can I identify, uh, vulnerability issues?
And that is where our first picture comes into place, because the basis for your first
evaluation is your S-bomb. The thing you already generated, um, you already named them good tools,
like, for example, or, or now I know, uh, uh, sift of the tool I heard from, uh, a talk earlier
that there is a new project, or for me, it wasn't just you, which is called S-bombify. So try them
out, um, all of them are good, I think, and this S-bomb that you created. Um, it has a bit different
I would say, including regarding false compliance or CRA, but if you have a standard system,
you can take the B-s-bomb for everything and then do a cross-reference. You put it to your
legal team on the left side for the false evaluation, um, at best with automated pre-filter,
and less human evaluation. And on the other hand, you have your security team, which can, um,
then, um, reference it to, for example, CVE or NVD database to get, um, already known vulnerabilities
and then perform their vulnerability check. So that means we can, we can just use the information,
we got, uh, we got from our open source compliance process and, um, build the vulnerability check
just on it. Yeah, and that is the point from, from our perspective and how our clients experience
it, um, how CRA becomes achievable because it demands from you to evaluate and manage your vulnerabilities
and how could you do that if you don't know what's inside your software. Yeah, that's the crucial
point, what's in our software, but, um, we also receive a software from suppliers and we do not
know the software very well. I mean, for our own software, we know, um, what open source part, uh,
what open source components we used, um, but, um, when we receive code from our suppliers,
it's hard to analyze the sometimes and, um, how can I be sure that we, they are compliant with
all the rules. Um, often from supply, it's, um, much more difficult because, um, for your own code,
as you said, you know everything about it. From suppliers, it can be that you get an entirely
black box. You just get some binders in the end and executable. You have to work with that
and the first step for your future CRA compliance should be to look into your contracts and that
is the point where, um, the league is coming to place because in the contracts, you can demand
from your suppliers that they have to transmit the, the information relevant for the RA compliance,
the documentation you need and all the stuff you want to get CRA ready. And if everything
gets a bit messy and, uh, you're a suit by a third party, by a official, um, department,
then besides this get the information in advance, you should already have liability clauses
and indemnification clauses that you, as the, um, final manufacturer may be an open source or, um,
a proprietary project, um, can transmit the, the costs and things you have to your suppliers,
which, in the end, provided this fault. Okay, I see, so I need an lawyer with a good, uh,
negotiation skills, um, but if I understood you correctly, if I get my own code on a control,
if I get the code of my suppliers on a control, or at least have good, uh, contractual conditions,
then I can just, finally press this fancy button you just mentioned, uh, and receive all the
relevant information I can be asked for. Yeah, and from our point of view, if you performed
all these, you know, not, not easy steps, um, let it the point where, um, compliance turns from
obligation to an opportunity. So as a manager, I would say it doesn't really sound like an opportunity,
because probably, um, it would cost a lot money and effort, um, but in the future, um, this effort
is not only necessary, but from our perspective, it's a selling point, because all of your customers
will in the future ask for the, uh, readiness and here are compliance, and if you come, um, transmit
that with your, uh, purchase information, or after they ask, one or two minutes after the question is
asked, that is a selling point, you won't miss. Okay, so from a manager point of view, probably,
I can say, um, it's a product feature, and not only an enemy, I have to fight, and at this point,
our drama is over and really, it's much back to our, to normal, to our normal rules, however,
um, it was very helpful to try to switch the perspective, to understand the various and the
fears our clients have, and, and to get a better understanding of them, um, and what we like to
give you, and also our clients with, um, are some key takeaways, um, we learn during this process,
and I think the main, main key takeaway is that first compliance is half the battle,
um, where it comes to a clean, uh, vulnerability management, um, and that's why we believe, um,
the topic for us will get more attention during the next years, and I mean, this is very,
very good news for the open source community. Yeah, and that is one point I want to get a bit
more in detail, because yesterday we heard a lot of, um, sessions regarding CRA and our my major,
image, what we, um, here and, uh, the question that we're asked where that most of the open source
developers feared the CRA, this big beast, um, they don't know how to handle, uh, what which
application they have to, um, to fulfill and throw on, but to be honest, um, I think that is
a wrong mindset. From my point of view, the CRA is opportunity for each open source developer,
because, um, think the other way around, most of the manufacturers will have obligations to
be fulfilled. The only way they can get the information to fulfill that is by asking the open source
communities, open source developers, because most of their code is open source. On the other hand,
from the CRA, there is no obligation that you have to transmit this information to them. Therefore,
um, before the CRA, there was a bit of a situation from David Ruther's Goliath, you have this big
companies, small open source developers, um, and they didn't care about open source to be honest.
We visited in our practices all the day now, um, that open source is a nice topic, everyone wants
a bit of compliance, but that's it. But now they have to issue, they have to care about open source
compliance, and they have to ask you, therefore, two things are relevant from my point of view.
The first thing is, um, they will invest a lot of money, hopefully, um, in the open source
communities to get this CRA readiness, and the second thing is, um, you're on the trigger now,
when you're the open source developer, and they need the information from you, demand what you want from them.
Okay, I think that is everything we want to say for today, though, thanks every month,
everyone for hearing, aloud, and listening to us, and yeah, we have five minutes left,
so if there are any questions, point them out.
Hello. So, um, when you talked about the relation between, let's say, business financing,
and how open source developers fear the CRA, and the amount of work that entails,
you're basically opposing big companies to open source developers, but there is also the open source
companies, which are not big companies, they are open source communities that want to build an open
source software and, um, make business out of it in a way that allows them to live and produce open
source. I'm not sure what you mentioned about how the CRA applies, uh, applies to this situation,
how, I mean, in this situation, the cost is to the same community in a way, would you comment on that, please?
Yeah, um, the microphone is not the best, um, but you, if I was on a strength, the question correctly,
it's about, um, when an open source community becomes the, the, uh, the deployer of the software
and has to fulfill this specification of this year, is it correct? Okay, um, I think, hopefully,
or the, the bad thing about this, there are not much, um, concrete rules and, um, playbooks from the,
from the Inisa, the U Commission, or the, in Germany, the BSI, for example, um, to talk about
who is only an open source duet, which is, I would say, the good position, because as an open source
duet, most of the obligations are free. There are now fine, there are now, um, point the, the
commissioner, or other departments can tackle you. Um, my whole will be in the future that the, um,
the, the, the definition of open source duet and manufacturing, a manufacturer regarding
that the software will form a bit more defined and each open source community should try to stick
under the open source duet definition, because then they're good to go.
Um, um, um, um, um, um, uh, question on, exactly the last point that you were just making. Um,
every time I've looked, the U hasn't given much clear guidance, essentially saying. Sorry. Yeah,
but, uh, my close, I'm, I'm closer to the microphone. Okay, uh, there we go.
EU hasn't been particularly clear on whether me maintaining free open source project myself,
kind as a manufacturer or not. Everything that you've just said says, essentially, I'm maintaining
a thing. I put it under an unlicensed, good luck. Where are you hearing that from so that I can have
to sleep a bit easier at night, because I'm worried that I'm myself. You mean that at an open
source duet, you don't have that much obligations, or I, that I don't want to get sued,
because someone gets hacked because of my weekend project that I released at a hackathon three
years ago, but right now, I would kind of like, like, maintainer of that project.
Okay, um, my issue with, um, I just wanted to, um, get the question a bit better.
Though you're afraid of code that you have written years ago, and now you're the maintainer,
or understood as still as maintainer of that code, and that someone comes and asks you to
fulfill the obligation of this year. Uh, um, from my point of view, and the, the, the, the,
the, the, they're unnot that much regulation, but yesterday was, well, the, um, what's the rhythm
speakers from the BSI, for example, the German, um, and from the EU commission. And what they all
pointed out is that they don't want to sue any open source developers, and that there are no,
I would not say obligations, but, um, behind the obligations for open source duet, which
are defined in 24, 25, here a, um, there is no rule set of finding these people, um, getting from
the commission, um, uh, with a strict, uh, obligations to the open source to fulfill the specifications.
Therefore, there are obligations, but they are, I would not call them them for free, but it's
more of a guideline, how open source communities and stewards should support the manufacturers
to fulfill their specifications, because to be honest, without that they're, they're lost in the end.
So we have one more question from the chat. Thank you. Um, someone says they've implemented
SBum generation for all of their packages, and they ask if you have tips on checking whether
that's, uh, sufficient for compliance. Okay. I don't like that microphone. Can you just show me the?
Um, you mean, uh, you mean, it is different for the compliance checking tools. Um,
first of all, if you have, uh, an SBum generated from Tyklon DX, and that is something to be,
sorry for that, but I'm the lawyer, not the technique in here. Um, I heard earlier today, um,
there are already good two links to translate cyclone DX into the, I would say, here are
ready, or licensed, compliant, led, uh, ready, SBums, and for the CRA, there are specifications
from, um, the U commission and the BSI, for example, for Germany for licensed compliance,
to be honest, um, we work with this every day. There are now specifications, what is necessary
for a licensed compliance? The good thing is if you're working, I can work with the information,
um, to evaluate all the relevant licenses, then it's good. And if you fulfill all the specifications
of cyclone DX or SBDX, you're on a good way, um, to work with it, and for the first evaluation,
as far as I know, all the open source tools we use, that is, or scan code, sociology,
they all provide the SBums, um, in cyclone DX or SBDX, and they also fill the, the specifications
that we can work with it.
Fair to finish. Do we?
Anika Florian. Many thanks for your offer, you.