you
many years on porous soil.
is useless and in fact it's dangerous because you may be making decisions that you
technically cannot trust. You don't know the license that you are
making sure that it doesn't get into your production environment. It is there.
So we need to make sure that our S-bombs are uniquely identifiable and
forcible, complete and available.
And now we need to actually figure out how can we build that? How can we build
a system that could give us some... We'll answer some of those questions that we were
talking before. So we came up with this diagram which has five main properties.
Availability, uniqueness, integrity, provenance and generation. It goes all the way
from the life cycle of an S-bomb. So for example, availability, can you make sure
that the S-bomb is there? Can you make sure that the uniqueness? Can you make
sure that it's the one that you're looking for? Integrity hasn't changed. So on and so forth.
And what we're going to be doing now is we're going to go through each one of
those boxes and we're going to be finding some open source tools that you can use
today and how can they play together?
And the first one is attestations. So attestations is just a JSON file.
I'm already simplifying this but somebody will kill me but it's a JSON file that can
have arbitrary information about a software artifact. So if you are building a
container image, you might want to store there how you're building information about the
build system. You might want to know who approved the change. You won't want to
any arbitrary information including obviously the S-bomb. And the second part
that is very important about attestations is that it is authenticated.
And what that means is that it is signed. And by doing that, if we put attestations
in our provenance verification layer, we will basically manage to have S-bombs that
are integrity and provenance verified. So the way that we could do that is by taking
an attestation, wrap the S-bombs inside, plus some additional information about the
context of how the S-bomb was built and sign it. And the nice, the good news are that
there are actually tools today that can help you to build this flow like using
SIGSTOR or in TOTA framework which is the attestation framework. And most recently we
have S-bombs which is this effort to get one step further on how to know how that
S-bomb was crafted and being able to make sure that, yeah, you can trust it.
So we have now the provenance verification we're going to keep going. So at this point
we have this JSON file super, like nice and signed and the S-bomb inside, this is good.
But now we're going to keep going to the distribution side of things. And for that, there is this
old concept that is called Contender Resolute Storage which again, it's a very offensive
way of saying that it is a database where you can retrieve its data by the address of
its content. But something as simple as that will give you integrity and immutability because
you can commit overrides, you can detect that something has changed. And again, we could
technically take one of those Contender Resolute Storage and put it in our distribution layer
that way we can guarantee uniqueness and integrity. And for that, a tool that you might be familiar
with are OCI registries which are all over the place and OCI registries is a good implementation
for Contender Resolute Storage. So again, if we put together the whole picture and we
use six-storey, total and cell-cell, the provenance verification and OCI registry, we will get
some of the materials that you can trust in identity, integrity, and origin. And this
is something that you can build yourself. This is something that you can put together,
you can use cosine and sine, your S-bomb, and a rapid interstation, you can do that,
all that. But now because we're biased, obviously, we're going to talk about a project that we
started that it's an opinionated way of doing that. And it's Chainloop. So Chainloop is,
we call that a metadata vault for super-supply chain. So basically it will take any piece of
evidence, it will wrap it into the stations, it will sign it, and then it will route it to
different locations. You can route it to different OCI registries, S3 buckets, dependency track,
WAC that have been mentioned before, so on and so forth. And Chainloop gives you two additional
things. So the first one, it gives you an evolution of what counter-dressable storage would be, which
we call federated counter-dressable storage. And what it does is create this layer that makes
sure that you can have data distributed across multiple back ends. So you might have five
different OCI registries. You might have S3 buckets, or maybe from the same, or different
organizations. You might be using this to send some of that data to your customers. And the other
thing that it enables is advanced routing for replication. If you have some requirements for
geolocation, for example, we have a user that needs to make sure that some data that gets
generated goes to a back end in Europe because of data policies, so over attention rules. That's
one. And this will give you availability. But the second part is, as mentioned before, it's
collection. How do you make sure that you can reassure that your organization is collecting
this piece of evidence, collecting metadata? And the way that we did that Chainloop is you
can write a, we call it a contract, but it's a declarative statement of the pieces of evidence
that your developers on the left side will need to provide. So if we put everything together, as
you can see, the main pieces in the middle, they're the same. Chainloop doesn't use all these open
source components, but extends on the availability side of things and on the enforcement. And now
it's time for the demo.
I have a microphone.
Yeah.
I'm over here.
Wireless.
Okay.
Okay. So now let's see how we can do it in practice. So what I'm going to show you, I'm going to show
you three demos. The first one is about collecting a cycle in the X and artifact. We are going to wrap
it into that station. We are going to store it in different cloud storages. In this case, it's Azure. And we are
going to send it automatically to dependency track and to Quack. The second demo is about, hey, I want to scan
my, let's say, a jar file for CVEs. But I want to find the S-bomb and I want to find the latest VEX file.
S-bomb may not be generated by the same team, may be generated by some other teams, let's say, by someone who is going
to put it in production. And the VEX file may be generated by, I don't know, the security team in my organization
or someone else who is pushing the application to production. And the last demo is about how can I share
my S-bomb or any metadata or attestations with others. So let's jump to it. First of all, what I would like to show you is,
one sec, can you see my screen? Yes, this is the Chainloop open source project under Apache 2.0 license.
We are going to talk about Chainloop architecture for now. We have CLI and we have a service. So let's assume that right now I'm an
operator or platform team or city office or the OSPO team. And I have Chainloop branding on my site. And I have a few
storages connected and I have dependency track. I'm going to show you how does it look like. So I have a Chainloop, the latest
version of Chainloop branding here. I can see all different backends connected. We are going to talk about the OSCI and the
Azure Blob. I have different integrations. We keep adding new integrations to Chainloop every week. But the main one we are going to
show you today is dependency track. I have one instance of dependency track running at home. And we have GWAC as well, but unfortunately I will
just show you the documentation that we have because I don't have it running. And yes. Now you understand that I have the Chainloop
branding and I have also that contracts in place. So this is my contract. Me as a platform team or as a security team, I expect some
metadata to be pushed to Chainloop and I can modify that contract and I can see how many different teams are following those contracts. And I have
everything ready. I have a token. I will pass the token to developer. And now I'm developer. So the developer, we are building a sample Java
application. It is the demo spring clinic and we are doing pretty well. But we have been asked to integrate with Chainloop and we have been
asked to start sending new metadata. So it was quite easy just because we have a reasonable workflow. Of course at some point we are going to have the
GitHub action. But the reasonable workflow is just fine. We just need the, we call the Chainloop robot account. But we will have more
organization tokens at some point. And I have to specify how to find those artifacts and S-bombs and Chainloop will do everything for me. If you don't use the
workflow, just to show you how the CLI does it. Yes, here. So like our flow, the user experience is following Git flow as well. So you initialize
the station and then you keep adding new artifacts, new evidences to the station. We validate all of them. So we are validating the contract. And then in the end you can even add different
annotations. We didn't talk about annotations here. But we add some kind of annotations and we are pushing if everything is okay to Chainloop. So now imagine that I had my workflow run again with
Chainloop on my project. We pushed all the different artifacts. Yeah, we got notification from Chainloop. Great job. You are making compliance and SecOps teams and
Ospo teams happy. You get some summary of the contract. And yeah, that's it. Like we didn't have to do much on the developer side. Let's get back to the operator side. On the operator side, let me get to my script.
What I want to show you, I want to show you that now we can see all these different runs for the very specific workflow. I will show you the attestation, the envelope and what kind of information we are storing because we are not
storing all the metadata. We are storing everything around. And today in this very specific basic case we are storing just different environment variables provided by GitHub. So let's try to run those commands.
Oh, sorry. Yeah, we are here. Okay, so as you can see we are collecting all information about those workflow runs. So you have some kind of visibility across all these different CI tools that you have across organization.
You have the client envelope. You have in total statement with all information inside. It's not about like we automatically detect the head of the grid repo. We collect some other information about that commit.
Those are environment variables I was talking about. You have annotations and information about the second DX and the artifact. And this is the same, but in more user friendly way. It's also verified because I have the publicly available in this machine and I have the proper environment variable defined and set.
So now what I would like to show you is what if I'm someone else in my work or in my project and the only thing what I know, I know the shot or I have the the the the draft, the output that was provided to me. One nice thing about chain loop is that I can discover things about.
That binary. So chain loop allows you to to to ask questions about. Okay, so I have a jar file or I have a git commit or I have a content image. I will get the we call it software barcode. I will take that hash and I will ask chain loop to provide me with more information.
And now I can see that there are different attestations generated by different teams by different organizations by different people related to the very specific to the very specific.
Container image or jar file in that very specific case so I can see that we have vex registry workflow which is ready to which is adding different vex files for that very specific.
Jar file or other container images or jar files in my organizations. I have the main attestation that's the demo spring. But cleaning PR workflow. I can probably get jar fire from here and as bomb and I have some other the stations. This one is also related to the vex file.
So what I can do.
I can right now get some of the of those attestations and I can even download.
Very specific artifacts just by providing just by providing show.
And that gets me to the next demo. So what can we do about that right like we are storing all these different data we are throwing metadata and s bombs and vex files and everything was related to what we are building a chain loop based on different code.
And I can build a very simple tool and the tool is about scanning for cities. I want to do something different. I want to get a very specific as bomb for my organization that is following very specific conventions.
And I want to find it automatically.
I want to retrieve the latest version of the vex file somehow as well just by knowing the the the hash of that of the jar file and that's what we are doing here.
If you take a look at the of the code of the tool I wrote yesterday sorry it's bash.
It's not go.
We are using the sea lie.
To discover different information about the very specific hash of the jar file.
We are we are getting attestations. We are getting the latest one for a very specific workflows in this case for the most print spring pet cleaning and for vex registry.
And in the end we are running trivy or you can run any other CV scanning tool with that very specific as bomb and Jason and vex file.
And the result is that if you run that trivy with that drop file you will get CV as you can see.
Sorry.
Yeah, yeah, I see.
I'm getting stressed.
There is one there is one there is one there is one CV out here and we are removing it just by applying our vex file.
Just because we understand that for instance this application is run behind the firewall so we are not concerned.
Let me get to the last demo the last demo is about sharing.
Everything like you can you can you can mark workflows as public at this point you can either have something starting organization or you can make it public so our attestations are also shared.
If you go to releases you can you can see that our attestations reports are available.
You can either have the UI but the best part is that you can actually get the the the Jason and you can automate different processes in your organization this way.
Yes, so just just very quickly.
Okay, just just to finish.
Basically the final thoughts is that the the bar in terms of compliance and security has been raised and as one trust is what we think is going to be the next challenge.
I know that there are many challenges on the way on the all the way in the life cycle but you know as one trust is something that we need to start thinking about.
But the good news is that we can start thinking about that we can start building our own you know we can get that head start with open source security tools today and that's that's why we are very excited to be here.
And that's it that you can find us in discord please join and yeah and you like what we do give us a star and thank you for your time if you have any question we might have I'm not sure.
Hi, I'm Olle Johansson.
You set the bar very high in the beginning saying as one trust and then you quickly said something about the public key you already had.
Yeah, you mentioned six doors.
Yeah, for individuals most of the right.
What kind of solution do you see for trusting as well and validating as well as between customer and vendor here.
You didn't really touch.
No, okay, so the question was that we will be talking about trust on the signings of things but then we should have them with the public key and private key and what do we think is going to be there.
I mean that's a very good question.
I mean the current implementation with Chenle piece is you know it's a good implementation of Chenle.
Obviously we have you know killer signings on the on the on the horizon to implement and and work like the entity and all this good stuff right this is basically the nature of the open source project but in terms of customers.
I mean this is tricky because we have we have we have users because we have users that actually more than the press out things and even they're like talking about just give me access to KMS and my old of my vault instance and things like that.
So I mean it's if you have any thoughts the answer is we don't know yet I would say so if we have any thoughts on that I would love to talk to you and hopefully we can shape it in the right way.
Thanks again.