Hello, the movement, but anyway, let's start.
I think we are behind schedule anyway.
Thank you for having me.
My name is Julian, I'm the, that's quicking.
I'm the development lead at the Centre for Digital Solventy
and Germany, and I had to scratch an inch,
and I will tell you all about it.
We are seeing the supply chain change,
especially in terms of delivering containers,
and security information.
And I want to tell you about what we did about this,
and how this might impact the field
on a more broader scale.
I don't have it that easy as Dutch barn,
but everybody knows the Centre,
so quick introduction.
For those who weren't here before,
the previous talk asked who does no Dutch barn,
because it was everyone, of course.
Zenders, we are the direct,
we're directly owned by the German federal government,
the originally from the Ministry of Interior
now for Digital Affairs,
and we are tasked with bringing back digital sovereignty
to Germany or the German public administration.
This is a nice task, so we wonder how to do it.
Two things, this is the first thing I kind of want to put forward.
This is our basic, our shared infrastructure,
for software development in the public administration.
So one of the things we do, this is not going to be the core today,
but this is something I want to mention,
is we create a safe space for open source
for the public administration.
So in tenderness, we have an easy way,
a regulated way where we can say,
publish it on open code on this shared infrastructure,
and we know that it is open source by policies.
This is a way for us to provide feedback,
provide tools for the broader ecosystem,
and also for us to work ourselves.
One of the things I want to mention is the security suite,
because this is where I want to dive in.
But first, the scratch, a ditch,
bringing digital sovereignty to a federated state like Germany,
is a complex thing.
Regardless of which definition you follow,
all definitions of digital sovereignty,
it's some degree boiled down to the four freedoms.
And at that sense, we don't really have a choice,
but to use open source,
and bring free software to the public administration,
and this is what the core product of us,
the open desk really does.
It brings collaboration suite for office,
to the administration, packaging what existed before,
of course, where we didn't invent mail.
We take mail systems that existed before,
there's a tough cut in sight, of course.
File sharing, video and project management,
are things that pre-exist,
but we make them into a coherent thing
that the public administration now can rely on.
That thing is surprisingly hard to,
well, to formally make secure, to formally get right.
But this is what I have to do.
We have to put this thing into the public administration,
a highly regulated thing, and people are curious,
curious about security, this new thing,
does it work, does it not?
Just to give you a size,
the open desk is 100% Kubernetes based,
so all we do is contain us on hand files,
and we have about 100 containers,
until it scales, then it's become larger, of course.
So it's a rather big thing,
and that's problematic, that's problematic,
because it's open source,
everyone can look inside,
but we have software as a service offerings,
we have on premises,
everyone can just check out the hand file and get cracking,
that has its upside.
The downside is everyone can look inside,
everyone gets the containers,
and everyone sees the whole supply chain,
the whole code base, everything inside,
and people get curious, what do I see,
and they ask, is it a problem,
right?
There are bound to be CVs somewhere in there,
and we need to manage that.
So on that scale,
we have to figure out a way
to get into this sort of management.
The next thing, by the way,
some resilience actually states, you have to have an S-bomb,
so people know why I have an S-bomb,
they don't want to do it themselves,
so how do we go about that?
Quick hot take on S-bombs,
and in this room, this is common knowledge,
but not everywhere else.
S-bombs are,
to get a certain amount of S-bomb,
a certain data sets of it,
this is super easy,
the last 20% is where things get messy,
versions of mismatched packages,
of wrongly identified metadata.
Yeah,
preaching to the choir here.
Next thing is hot take about S-b-e,
CV-matching is hard.
It's about as annoying as the S-bomb before,
and if the S-bomb before wasn't fun,
it's not going to be fun as well.
So, even if I succeed in creating my S-bomb,
and match that with CV,
my customers are going to have different tools.
They had different tools in the past,
so this is discussion, right?
I have to discuss what exactly are we seeing,
who is doing what,
and there are things that are just irrelevant,
I think it was last month.
I had the great case of a large CD,
it was, I don't know,
it was 8.6,
but it was a high CV-e on tar,
from 2005,
stating that if you unpack something with tar,
it could go into the wrong places,
and tar doesn't mention that in the UI,
and the developer said,
I don't have the UI,
and the won't fix.
It's there till now.
There are annoying things that you just have to write,
but firmly there is a large CV in it,
it's annoying.
So, in comes the Vax.
Again, I think the room kind of knows,
but Vax,
this standard for basically giving that thumbs up thumbs down,
is this CV-e actually a problem, or is it not?
Now we can put this together.
Suddenly, I have a data set that,
at least, in theory,
kind of solves all my problems,
and this is what we now deal with the open desk.
We build the S1s,
first, of course, someone has to,
and we distribute them.
We directly distribute them as visible,
as the image as well.
This is just SCA, right?
Everyone could have looked at the image themselves.
There is no secret inside.
The S1 is, of course,
attested to the image.
The CV information as well,
with the caveat that we need to have life or else
for updates, I get that.
And the sample Vax.
So, when I distribute an open desk image,
it contains,
not just the image itself,
but attested to it.
We have the whole S1, the whole CV,
all CV is with life update,
and the current Vax situation at the time of a testing.
Sometimes they get updates.
And this is something my users can now work with differently.
Now, they get something from me.
They get the assessment.
They get to see what are the CVs,
other problems inside, or other not.
And this, I hope you can see it down there.
This kind of formed our new supply chain in things.
We have,
so maybe one thing I have to emphasise,
the most components from the open desk are vendor driven.
As I said, we didn't invent mail.
We use someone who does mail for us.
So, this is what I call a vendor,
and they have experts.
Whenever there's any CV popping up,
and I want, I ask,
is that a problem?
They, in a second, they say yes or no.
Right?
This is expert knowledge.
Now, the first step we did is,
okay, we centralized the concept of building
S-bombs, matching CVEs,
because we don't want 10 different tools.
Take a central tool just to do that.
And all I want is your expert information.
Give me that.
Give me that expert information.
Give me the Vax.
And I'm just redistributing it to my users.
Maybe I have to layer it a little bit,
it's on the next slide.
Ideally, and this is something,
some of the supplies are already moving towards.
They do it themselves, of course.
Right?
They have to supply,
they make the S-bombs themselves.
So, we are slowly changing from I,
make the S-bombs,
and I make the CV management,
to they supply it.
They create themselves,
and still we are working
about OCI organizations.
All the data still works directly,
runs with the image.
It's as public S, the image.
If it wasn't an in public image,
it's about a hidden aspect.
That's the ideal.
This is where we slowly moving towards.
So, you can see, if I come from here,
I just inject the concept of,
this is S-ca.
So, this is the S-bombs.
This is the matching.
All I really need from you is the expert knowledge.
And the next step,
if you want to enhance this,
because like there is,
there are more customers asking the same questions.
I'm just consuming your data then.
And the need part about this process,
and I think this is something
that hasn't been stressed enough in the recent times.
This is completely recursive.
And I'm just talking about containers at the moment.
This can of course apply to packages,
but what we find very important is
it applies even to,
to instances, for instance.
We now have a layered system of,
a fixed, of a fixed image of a fixed state.
So, I can, for instance, say,
my upstream supplier,
the upstream project, anyone,
has a vulnerability that is true.
A true vulnerability.
And even the vendor, for instance, couldn't fix it.
It's still in the certain use case.
It's still a true vulnerability.
I just wouldn't have the use case.
That use case, for instance, for me,
once it's part of the open test,
maybe if it gets changed,
we fix this vulnerability.
So, we can untick this,
or in the hand file, then we can tick it as well.
So, this is really what we do, right?
We attest to the image, all the hand file.
The idea of whether or not something is,
the concept of the response and the vulnerability
management, because this is exactly the scratch
we have to each at the moment.
And our users get exactly this information.
So, they get live information on what is affected,
what not.
The whole idea is just to reduce the workload.
CVEs shouldn't be large numbers,
that you just don't ignore it.
Just ignore it.
They have to be broken down wherever they come up.
And just two positives should tick it down.
So, ideally, and this is really what we do,
the last instance should only on rare occasions.
When a true CVEs really comes around,
get that notification.
Everything else shouldn't even reach the last instance.
And this is exactly what we're doing at the moment.
This is exactly the target that we are currently working with.
I said, tool chain.
What we use is a tool called DeafGuard.
This is basically an HGPL.
Five minutes, yes.
An HGPL project from OSP.
It's, of course, I said we have the shared infrastructure
that's available for the public administration.
As a hosted service, there are various other instances as well.
And this is our attempt to create a free reference
tooling for security metadata, especially for CVEs.
Because this is one of the problems we are going to face
with the several zillions, right?
If everyone is starting to create S-bombs,
especially looking into open solutions.
And we don't have one algorithmic thing that works.
Everyone's going to just have different answers.
And this, I don't think, is the right thing.
So what we do with DeafGuard, we put the focus
into what really is CV matching.
Not yet the S-bombs.
This is what we take from other sources.
And we find out what can we, what can we all agree on
is a correct matching.
And the rest of it is really just an interface
to your attestations.
At the same time, if I put enough attestations,
it becomes my central hub.
But this is just by accident.
And apart from this, as I said, we are the,
we are shared infrastructure for the public administration.
We provide the CSF and the VX live feed
for our projects on the platform.
Such that not everyone has to provide these things
and we need them for the open disk anyway.
Large story ahead, the general public administration
realized that the dependency, especially on containers,
with a huge container or cloud strategy, is massive.
Most supply chains of containers are very centralized.
And not like the decentralized things
that we know from operating systems in the past.
And this is something we have to kind of work with.
And this is a large paper SSDLC with open code
and the BSI from Germany on what can be done about this.
And one piece of answer of this is that the public administration
started sharing their own hardened container images,
following exactly the paradigm as a state it,
with clear one-size-fits-all S-bombs and VX information.
And the clear policy gate, if the containers are not accurately
vexed, they are just not managed.
So this is kind of the policy we had the moment go with,
but the system is growing.
And it is designed to harbor the images of entities,
using their own edge for us.
We distribute the things of open disk.
The Ministry of Foreign Affairs does exactly the same thing
as they do for their platform or the data.
Management platforms.
And I think this is very similar.
Some of you may be know the iron bank of the US military.
Similar concept.
But more decentralized.
I think I'm right on time, so if there are any questions,
or clamping.
Questions?
Yes.
Not yet.
Sorry, the question is, can a private company join this container registry?
The thing is, at the moment, not.
It's designed to feed the contents to help us share the contents that we have ourselves.
VIA, a public entity, containers, of course, can enter.
And we are currently looking into the idea of how can we federate this.
So for instance, salsa can provide a way for us to inject any source into this.
But then we have to focus on the sovereignty part of things.
So we are interested.
We don't know how yet.
Thank you very much, Julian.
Sorry.