Okay, next up, our gig and storm us, we'll be talking about creepy data, we need better open source data for CRA compliance.
Yes, we do. Take it away, guys.
All right, welcome all. I know it's already getting late. It's dark outside, but we're happy to see you here.
My name is Thomas Timbergren. I work, I mostly help organizations by using open source should you be safely and effectively.
And with me.
I'm Gail Blink. I'm an open source strategist. My focus on helping organizations become more professional in their use of data and metrics.
We are here because we have the Cyber Resilience Act.
It's coming. The dates are approaching when we need to start to do our reporting and comply with all the obligations there is.
And we want to talk about the data aspect.
For those who are new to the conversation, a little background on why we need Cyber Resilience Cyber Security.
There have been many more attacks over the last years. The trend is increasing and it is on the EU to say, okay, enough is enough.
We need to regulate this. So the software industry is becoming regulated.
And with AI, this is only compounding and we need to have not just new tools to manage the situation.
We also need to make better decisions for which we need data.
When we look at the solutions that are emerging, there are a couple things we want to say to this.
And we need real solutions, not just work around. We cannot rely on doing things by hand.
We need to automate things. We need the reliability of the data and the tools that we are using.
And there are a lot of things already in the works.
And we will need to, of course, support open source with whatever companies and organizations that have the obligations.
They will need to work in the upstream ideally that is my hope as an open source, strategist and advocate.
So one of the things that I believe in, the re-believing, is that we have the digital commons for the software supply chains and there are shared solutions.
And if you picture what the world could look like in the ideal scenario, we have best practices that are shared and easily available.
We have practical standards that are adopted for consistency across the ecosystem.
And in this ideal world, we also have interoperable tools where the data is a standard across and usable anywhere.
And we can plug and play and choose the tools that we want to use.
And then, of course, we need that reliable data, which is in an ideal world available to everyone.
And if you look at this ideal world, there's already a lot being done on creating those shared tools, shared standards, the collaboration is there.
And there's a lot of logos with a lot of initiatives, but really behind the scenes, all of these people working on this, no each other, they're working together, collaborating.
And there are emerging, de facto standards.
Some of them have even gone this step of becoming the Azure standards, like ESO standards in this process.
So there is a lot already happening in this space.
And it really comes to show that when we have good community consensus, we create practical standards.
And that is what we are seeing here some examples, again, of these standards developed by the community, where these are already available today.
It's a mix and match, and I'll pass this to Thomas to talk about this more.
Yeah, so one of the things that I commonly see, I work as a to do ospms with a lot of different organizations, is they come from a world where they have a single vendor, they bought a vendor.
And like, oh, we have to use this vendor for this poem.
In the world where I live in where most of the time I would say, like, look, no, there is not one magical, physical tool that fixes everything.
You have to use and mix a match of tool to basically use a base of what you need.
I know most vendors will promise you everything, and nothing about more should our great commercial benefits as well.
But in reality, most software companies, unless you're very small startup, you don't have and one is just like where everything is the same.
You have multiple different problems, and you just like just simply said, don't think everything, because you have everything is a nail.
Sometimes these players, unions on this soul, it's exactly the same, you need to have a tool set.
And so that's really where you see the difference happening, and you see actually the leading edge when you look at the CRA, it's all open source tools.
Because people are like, oh, hang on, we need to do things, we can't do this, we need to do this differently.
And that's where you're basically like, yes, oh, I need to mix match of tools that this interval, I need to be taking from one thing, I need to connect to the other thing and be able to do my CRA patient.
Oh, ideally, I wanted to be community driven, because guess what, the CRA is still developing, we don't know, like everybody in the community's old trying to figure out the CRA, how it works, how it can connect things together.
So you really want to have a community driven tool where really input is done.
You also want to have a decentralized and fertilized, because guess what, there are slightly different differences between each country.
We're in jurisdiction, the law is not the same. So you want to have tools that, hey, one tool might be perfectly working in France, because that's the particular way how they operate in this particular organization.
But in other side, they're like, oh, hang on, we're not, but still, that's why the benefit on the opposite side is to code this open.
I take things that are happening in France, that as well, so I was in Germany, that completely don't apply in my legal session, but still, I said, hey, that's a clever idea to do package detection.
I will take this little snippet they're doing, they are writing it in goal, I were writing it in Python, but I just take that bit that is useful.
Of course, given credit, don't don't, don't, don't think so. And also, what I look, what we do as a responsible for the program office, we work together.
So don't, what I see in specialists, you're ready, a lot of things. Oh, it's a security topic. No.
Yes, it's a security topic, but it's also a legal topic. It's also a topic for your developers.
You really need to start learning to work together.
And this is where having basically open source software
is usually easier because the people in those teams,
they can play with a tool already beforehand.
And they can discuss within their group, within their peers.
Like, hey, I have this new open source tools,
but do you think about it?
And you see basically a more diverse of the opinions.
So, this picture, I've just put the futures.
So, in reality, I try to have more than 180 different tools
related to this array.
Because I often get asked about it.
We try to put some of the major ones.
So, again, it is a little complex.
Yes, I would love.
We were working on, we had a workshop yesterday
in a licensed security workshop, where we actually discussed,
like, hey, we would be ideal if we started making a landscape
picture out of it, so it's made for easier.
And their open chain project, there is actually a tooling mapping
already being worked on, so to make it easier.
But it's said, just keep mind that there's not a single tool
that is perfect.
And I'm saying this is my tool created myself.
I, on a regular basis, advise people not to use
even my own tool.
People like, hey, but you are an organization, why are you not
to advise about this?
In the context of that organization, my tool,
it might not be the best solution.
A tool from somebody else, maybe a better solution.
So, I'll talk about tools.
One of the projects that we are working on, which we got some
subsidy from your permission.
It's a project called OctatU.
If you have any questions, well, Martin is also in the room,
as well.
We're basically trying to work for small media and businesses.
Oh, yeah.
Dad.
And, I know a lot of faces in the room.
I know some of them work for large companies.
You have to benefit a big corporate backing view.
Small media enterprises might not have that support.
So, luckily, You commissioned said like, hey, we are working on a
solution for that.
But, said, Yeah.
We have a saying in my little net of the
� police of community.
A little full with a tool is still a full.
In this case I hear's all things saying, like,
So I was not saying garbage in garbage out.
What I see with a lot of tools when I compare them,
and I do this in a regular basis, is like, oh, yeah.
Why is there such a difference between these tools?
And then you start looking at, like, yeah, it's data.
All the tools operate on different data.
Luckily, there are more and more projects coming.
And if I, like, why is there not one project?
Do you know how big the Opusus ecosystem is?
You know how many millions of Opusus packages in there,
with all their various specific things?
So there's, yes, there's different people working
on different parts of the corners from a different angle,
which is good, because then you have different opinions.
And you can say, basically, help.
Eca-sasmas says this.
Oh, as V says that.
I know we're working this in, I know,
because I worked with sometimes.
In some ecosystems, I trust this provider better
than the other provider, and then I just make some match.
But it's very good to see the differences.
We do not want to have one provider that is dominant
and leads every.
I like diverse opinions.
I think, in Europe, we're trying to prefer this as well.
Otherwise, we would have thought to be the United Nations
of Europe.
So what do we still need?
If we have all this projects on all of this stuff,
we have already so many things on.
And well, data, data, data, data.
We only start scratching the initiatives that we have now.
They look, they're great.
But we don't have deep data.
Like, we now have, like, oh, we have all the package metadata
that is great.
But we don't always have good data, for instance,
on what Gurgers work on project health.
Can I type in a random thing?
And so it's like, how is this project doing?
Like, yes, you have most of them.
Oh, the amount of maintenance for this project.
I myself work with no-bentainer.
Josh Brescher, one of the security guys I follows.
He showed me, in the MPM, the top 10,000 MPM packages.
I think half, like, 40% has a single maintainer.
So if you write a policy or a serious policy,
oh, our risk profile says, like, we do not like
partnerships with a single maintainer.
Well, then you don't use note anymore.
You can exclude all of that from your stack
because the majority of note packages are maintained
by a single maintainer.
And are they ecosystem to have a single picture?
But you need to know that.
So what do we need?
We actually need open, trusted, actionable, and curing data
that you can rely on.
And this is still in there.
We run out of time.
Woo.
Then I'll go quick.
Three bills of data that we need.
Your clock was telling me something different.
We need data about packages.
We need data better data about vulnerabilities.
As I said, the purchase work on this,
and we need to community data.
As I said, there is a lot of screen
to projects already working in.
We ourselves are fortunate that we are working on a new project
in this space.
Again, I'll find it by the year of promotion.
So keep posted, we'll post on Zoom.
Let's all collaborate on data.
That's it.
Thank you.