So, welcome to the last session of the Secure to the Room.
Let me introduce Fredrik Skogman with his talk on enhancing up-to-flexicular activities
to get up at the stations.
Thank you.
So, yeah, my name is Fredrik Skogman.
I work at GitHub, and my team is primarily focusing on supply chain security,
active maintainer in a lot of open-source security related things like
six-door and update framework.
And also, thank you very much for coming.
I know it's super late.
You are probably tired.
I'm tired.
So, I will run, try to run this as fast as I can.
Speak up.
I will.
Oh, sorry.
Oh, just sorry.
This is on me.
There we go.
So, yeah, I would like to talk about artifact adaptations.
So, this is a feature that fairly recently out.
So, it allows you to provide a way to guarantee integrity from the build step
to the library for everything that's built on GitHub actions.
This way, we like to offer a very simple way to sign all this open-source stuff
that you're building.
So, it's been around since summer of 2024,
and the work started in 2022 when we were doing a similar way for open-source
NPM packages to provide signed build provenance for everything that's built on a
width for NPM.
And, of course, it's free for open-source to use.
So, I encourage everyone to use it.
And, early doctors include home brew.
So, huge thanks to William, previous presenters.
So, they've been working very hard with us to try it out and make it working.
And, I'm super excited that all bottles on from brew are now signed and built with provenance.
Although the home brew is still in beta, so we're working on them to kind of clear out
a few issues that they're experienced to go full GA.
So, to kind of describe the problem, we like to start a little bit with sort of
typical signing how it happens.
Like, you have a typical build pipeline.
You build something from source code repository.
You put it into the registry, the registry sign set, and then the user can download it from the
registry, and they can verify it hasn't been tempered away from the registry.
The problem is, what went into the registry in the first place?
It's very hard to tell.
You just know that it was signed by the registry, but was it a release?
Was it a dev build?
We don't really know.
Maybe it was a malicious artifact being put in the first place.
And basically, we're lacking some context of the artifacts when it comes from the registry.
You can try to solve it by pushing signer, signing sort of further to the left.
But given a lot of the solutions out there, like, it creates a problem around managing the PKI.
Like, it's kind of complicated and not all open source projects have the resources to
run like a fully complete PKI system.
So, that's kind of what we are trying to simplify with this.
So, with artifact that is stations, when you're building something in the action,
it's signed automatically by the system.
And it's not just signed.
It also extracts a lot of metadata around the build, like, which repository was it coming from,
what are the commit ID, and so on.
So, basically, we're capturing the context around the build, and we add that.
We are also including, like, exact build run.
We're creating, like, a paper trail tracing, this specific artifact back to a specific workflow run.
So, with part of this, we are hosting an entire PKI platform.
And we're also doing it by relying on workload identities instead of, like, human identities.
So, that gives us a way to kind of simplify the policy processing around it.
And the great thing about it is that, from a developer perspective, you don't need to manage.
You don't need to manage any key material at all, like, everything happens automatically by the system,
which I will of course describe.
So, rough.
Yep.
Please wait, if possible.
Yep.
I will get side track otherwise.
We'll get what to say.
Yeah.
Some of the components, like, we have the actions, of course, that you can use in your workflow.
We have a CA and a PKI.
And now the station store to capture the metadata that's generated during the build.
Then we have the GitHub CLI that can be used to run policies around the artifact.
And then there's an integration with the policy controller from six store, which is a Kubernetes,
a mission controller.
So, you can use the same thing to secure your workloads in, in, like, Kubernetes way.
So, everything, almost everything is done fully open source, like, we want to meet the community where it is.
So, we avoid to, you know, build and custom things that only work with what we're doing.
So, we're, teaming up, we're much with six store, salsa, internal, and tough.
So, a quick introduction is that six store is an open source project that aims to simplify signing and verification for everything.
And, according to the six or project, they're trying to be, like, the lesson script for digital signatures.
And it, we're interesting with six store is that it's not just, uh, a lot of source code repositories that you can use.
Six store is also a public good instance that anyone can use, and my team are part of that operation as well.
Like, we are wearing the picture for the public good six or instance to make sure it's operating as smooth as this can.
And for describing the metadata around the builds, we are relying on something called salsa build provenance.
And it's a standardized format for distributing metadata for builds.
And to kind of ship them around and tie them to the specific artifact, we're using internal adaptations, which sort of create that link between a subject and some metadata were predicate as it's called in internal.
And then we have the update framework, which is a framework for securing upgrades over untrusted channels.
So, we are relying on that to manage the trust route, like the route certificates and public keys, etc.
So, we're using it to manage it and to distribute it to the clients.
So, a simple overview of the system is that when you're running a build during, if you're using adaptations or artifact adaptations.
The system first collects the metadata required, like, as I mentioned, repository git commit, workflow run, the actual workflow file being used.
It then extracts the identification token from the actions that uniquely identifies the build.
And then we use that to request assigning certificate from focio.
And then when you have the signing certificate, we can sign the provenance and we can put it in our adaptation store.
And then clients can be adopted framework, get the latest version of the trust route.
Fetch whatever adaptation they would like, because they might have a file and they can compute the digest and query our store.
And then they will get all the matching adaptations for that.
And then run whatever verification they would like to use.
And it doesn't have to be in this case to get a client like it could be co-sign or basically any six-store client we work here.
So, to avoid burden of relying developers, managing private keys.
Six-store is heavily relying on something called the femoral keys or ambient tokens, or you might also have heard keyless signing,
which is of course just a gimmick like keys or definitely used.
So the way it works is that you create an in memory key per, and then you send a public key of that together with identity token describing who you are.
To the CA, who then verifies identity token via Federation to the identity provider to make sure you're not lying.
And then it creates a short-lived certificate that's only valid for 10 minutes, binds it to the public key and then sends it back.
Then you can sign via that certificate.
And because the certificate is only valid for 10 minutes, you need to think about something to simplify the verification,
because you can rely on the typical certificate verification where the certificate has to be valid during the time you're very fine.
So what we're doing here is that we either reach out to that time stamping a 40 or in the six-store public key of the instance,
we are using a public append-only transparency log that also gives us a timestamp.
So we can get a counter signature and then store that together with the original signature.
And then when you're trying to verify this, you can verify the timestamp of the signature when it was made.
And that way you can see like, okay, this signature was made during the time the certificate was valid.
And this greatly improves the risk of a key compromise, because let's say someone manages to extract the key from the memory.
It's very unlikely that they will do it like uncompromise the full attack within the 10 minute window.
So yeah, the benefits of using the store here is like you get identity federation out of the box.
So you have a system that kind of vouchers for your identity.
You don't need to manage the keys.
And especially for all the fact that the stations we rely on workload identities instead of human identities.
So the identity is basically the organization repository and the workflow.
So you don't need to understand like who is the maintainer of this package and something like that.
You can look at where should this thing come from.
We expected to come from this repository.
So as I mentioned, six store operates one instance.
At GitHub we operate a private instance.
The public instance from six stores free for use for anyone, but you need to think that everything that's being signed is also put on a public transparency logs.
If you have privacy concerns, it may not be the right place.
The instance we are running at GitHub is completely compatible with the public goods.
So every tooling that you have will work with both of these instances.
So this also build provenance.
So it's a JSON specification for the format capturing a lot of the metadata.
As I mentioned, we have the basic stuff like repository owner and the exact workflow file that was being used.
It also contains a reference to like the logo of the system like the build rug for action.
And importantly, we also encode the numerical identifiers for the repository and the owner.
So that's to make sure you can have a policy to protect against like rename attacks or resurrection attacks.
You can of course browse that is stations in the web UI.
And if you don't like looking at JSON data, you can have like a view that kind of summarized what's in the build provenance stock.
And these are of course UX like it's continually hopefully being improved.
It's definitely continually being changed.
Right, so if six stories altered out there, there is a public instance that anyone can use why did we spend like a couple of years doing something on top of this.
And it's to get a better experience for the developers.
A six store is mostly concerned around signing and verification.
Six store doesn't really know what the sales have been provenances.
Six store does not provide a solution for storing or discovery of other stations.
So those are the things that we have added on top of the existing six store components.
Yes.
So how to use it, it's pretty simple.
If you're on get abactions, you need to add one more step that reference one of the various attest actions we are providing.
In this case, it's a test build provenance and in this example, I'm a testing container image.
And you can see here that also a parameter called push to registry true.
And that means that when the build.grimmage is being pushed, we're also pushing the build attestation to the container registry.
And the useful thing here is that if you're running let's say Kubernetes, you may not want to allow the cluster to communicate with like around or maybe I such as GitHub.
So we're putting that station next to the image that you already have access to from the clusters.
You can have tighter egress rules.
And this action allows you to attest whatever file that's being produced.
It doesn't have to be a container or a package or it can be basically an individual file like an espon, if you like.
So for the verification side, which is the most important, like you should not sign if you're not verify, then you're not getting anything.
So everything is compatible with cosine, which is sort of the go to CLI for six store.
You can also use the GitHub CLI to verify, or as I said, like if you're running in Kubernetes, you can use the six store policy controller.
So when thinking about signatures, I think it's very important to understand just because it sign doesn't mean that it's secure.
What the only guarantee we're giving you is that we're giving you a paper trail that this artifact was created here.
Safe to run, we can tell, we can only tell where it's coming from.
And of course, you need to follow all the best practices on tightening up your build system, like William's presentation supergulence is more like very relevant technology to use.
On GitHub, we have some solutions like you can rely on for instance code owners to separate who can modify the build instructions, or if you want to go for a real secure model, you can have our useful workflow.
The salsa community provides a builder for most of the ecosystems out there, like go Java, that builds the binary for you, creates the build provenance and signs it for you.
And the benefit here is that you get that complete separation of concerns, because the salsa builder is in the salsa org, like typical developer doesn't have right access and can modify the building instructions.
So that's very useful for a lot of people to kind of make sure that developers can write the code that they can't modify how it's built.
And we'd reusable workflows, you also get other benefits such as build isolation, the workflow is guaranteed to run a separate VM.
So if you have, for instance, a place where you're running unit test, the test, my friends has modified the file system that can change the outcome of the build.
So it's a real strong thing to use.
Just when I just want to mention free recent attacks, like it's no grudge against this projects at all for me, it's just that they are very recent and they are very relevant.
So in December last year, Solona Web3JS had an attack where someone got a hand on the published token to NPM.
So they uploaded a malicious version that contained, I think it was like, cryptocurrency dealer, but it's not super relevant.
But here, like, if they were using build provenance, you could just take that by modifying, so not modifying.
But by modifying the artifact and see that, wait a minute, it doesn't have a build provenance or the build provenance has changed.
It's coming from a different repository than it used to be and that is a strong signal that something may have happened.
As William mentioned on the talk before this, ultroletics had an attack and in this case, the existence of build provenance proved to be very useful during the forensics because they can see what was the offending workflow that built this malicious artifact and approved like really strong during the forensics.
And also, once the first malicious version were removed from the register, another one was published, and that one did not have build provenance.
So if they were verifying the provenance, they will see that the second one didn't have one, which, as I said, like, it's suspicious signal.
The third one is the same scenario as the first one, I just added it there to kind of show that this is a frequent pattern we're seeing like compromised tokens to register is a common way for people to upload bad packages and with build provenance, you can easily detect if that is happening.
So it's getting late, so just going to run through some quick examples of how this can be used.
In this case, it's readable, like, I'm just running the GH or the GitHub CLI to kind of verify that this container image is originating from in this case of specific repository.
And when you run this, it kind of takes the digest of image, interacts with a station store, gets the matching administrations and verifies them.
In and here we can see that we're getting information like yep, it's originating from the expected repository, and we can see a reference to the exact workflow file that was being used to create the sign it.
Is this readable?
The idea here is I just want to show how it can look like when you're using reusable workflows, so this build creates free artifacts.
One does being built directly within the workflow, one creating the bug build via reusable workflow and the third one is a release build via another reusable workflow.
Because the way you're thinking about signer identity changes a little bit with this.
So the first one is the simplest one is just verifying that this file is originating from a specific repository and everything looks good.
Second one, I'm looking at the bug artifact that was created by the debug reusable workflow.
And if I try to verify this, we can see that it's failing, that is because the identity of the signer doesn't match the expected one.
And this is because when you're using our reusable workflow, the signer's identity reference reusable workflow, not the originating repository.
So to fix this, we need to be very explicit that the artifact has to resonate from one repository, but it should be signed by another repository.
In this case, I'm just saying like it anywhere flow in this repository is good.
If you try the same or if you try to verify with the release workflow for the debug, it's of course failing because that's not the workflow used.
You're using the release artifact, of course passes. So this is just kind of showing that you need to think about the signer identity.
And that is the last slide. Thank you very much.
Thank you very much.
What are you looking at?
I have been a fan of Huffland also.
By the way, it's a beautiful question.
If you want pretty pictures, question list.
Okay.
Now I'm going to make some design for you.
I can give you that mostly about what you're signing.
For example, if I'm going to ask you a few questions,
say that the action was something where I can never send to another account.
So what did the any kind of checks into a not sign and probably another project?
No, we currently, we don't care really what you're signing.
We sign whatever you provide.
So the question was around if we have checks from all of our things like that, and we don't.
It's currently out of the scope.
We're basically providing a link back to the workflow.
So we don't introspect the binary at all.
Like we sign what you provide to us.
It's out of scope.
I think it's different mitigation attack.
To kind of introspect and look for binaries.
And it goes way beyond signing and working with build provenance.
Yep.
So the question was around how do we try to mitigate and attack on the runner to extract the key?
And currently, it's not really a problem.
So the question was around how do we try to mitigate and attack on the runner to extract the key?
And currently, it's not really something that's done beyond the capabilities already in action.
And that is one way, for instance, to use our reusable workflow because you move to a new VM when you do the signing from the building.
So that's the preferred way to kind of separate out the concerns.
But otherwise, it has to be a full blown attack on the runner.
And as I mentioned, like the certificate is valid for 10 minutes, you need to work really fast.
Yeah, I think you're, sorry, you're next.
Yeah.
So the question was around basically what data is included in the build provenance.
And I think the short answer is that you get the source code that is being built from.
I think that's the primary indicator.
And everything is defined by the salsa team.
So that's not something we can sort of, or we don't want to mess around with that.
Like we want to use what's already decided by the salsa framework to include in the build provenance.
But it's, it's currently the source code and then sort of the transitive closure.
You can see what's being pulled from that source code.
No, it's only the git commit object.
Yeah.
Assuming that the build step to the source are deterministic.
Just the method that you use is information.
So the question is, if the build steps are deterministic,
does the build provenance give you sufficient information to recreate it?
And I would say yes, because the build provenance contains an exact reference to the version of the repository.
So you can, for instance, see, okay, this is the, let's say it's a make file in there.
Then you can look at the make file and see what steps we're being made to build it.
And then you can try to reproduce it based on that if that's a question.
So if that's a clear, you can have that more access in there.
This other external image that they can use, get that build process.
Like this is not a reproducible bit.
Like the, it's not actually running.
I could still do another thing.
Oh, yeah.
So this, like I'll just make sure that you cannot be guaranteed to reproduce the same word as that.
I just did another thing.
Okay, yeah.
Oh, yeah, yeah, yeah, yeah.
We are not making any guarantees at all that it's being reproducible because I mean,
for instance, if it's a C project, the order of the object files may be, you know, based on the,
I know it's in the file system.
So we are not making any guarantees, but if the project is built to be reproducible,
that could give you the link to the make file that was used to build this.
But, yeah, otherwise we don't make any guarantees at all about reproducible builds.
Just a little more.
It's a very, I heard that you mentioned them to get them to get up now.
Why it's a way to collect and expose the signatures at a,
upon places, that's correct.
So yeah, they are available via the public API for the repository.
So that's how you can clear for them.
I mean, you mentioned about the private things of C store.
I mean, like, others that work out there is a private key store then in the HSM one.
No, it's the same model.
Like, it's still using a formal keys.
It's just that we are hosting the infrastructure,
instead of the public good version.
Otherwise, they are equally the same.
All the actions are exactly the same.
So when we are building or when we are creating the provenance,
we basically look on the repository visibility.
If it's a public repository, we use public six store otherwise,
we're using hours.
But otherwise, they are technically more or less the same.
Yep.
Let's go.
Yeah.
Let's go.
Yeah.
For Docker images in specifics.
Yeah.
So the question was if other repositories for Docker are supported
and the question is, yes, I don't have the full list in my head,
but I think virtually every container register out there.
We are supporting.
And when we are uploading the build-out station,
we are probing for compatibility with the reverse APIs.
If you support the reverse API, we rely on that.
Otherwise, we use, it's called like a tag hack that seeks to invent it to upload.
A signature next container that is in a registry.
So yeah, I would say probably everything out there,
at least that I'm aware of should support this.
Yep.
Packages.
Yeah.
So we did the work for NPM.
Pipi is using sort of their own version of build provenance.
Homebrew uses it.
And I think, I mean, may even are doing something similar with
sixth door.
They're not using build provenance, but they are relying on
sixth door signatures.
Ruby is working at it.
So those are.
But yeah, I think it's also important to understand the difference
between a sixth door signature and a build provenance.
Because a build provenance is, you know, met that data around it.
Whereas sixth door is just signing your package without the extra context.
So there, yeah, a lot of ecosystems are looking at
sixth door.
And we're, of course, hoping that they will start to use
salsa provenance as well.
Because I think that gives you more information when you're doing
a policy evaluation.
I'm actually working on a programming and the links are right now.
Oh, nice.
Super happy to hear.
Thanks.
Thank you.
We made it on time.
We get to do a big thing for it.
Yeah, but if we had a driver's system, do you use the same thing
with them?
Yeah.
We're using the same technology for a driver.
Yeah.
But of course, we have different people running it.
Yeah.
But the technology is exactly the same.
I know.
Yeah.
Thank you.
Yeah.
I just have a small question.
And is the timestamp utility of data publicly available?
Sorry.
It's the timestamp authority.
So I'm working in William's team.
Yeah.
And we developed as a signed timestamp.
Yeah.
For sixth door, we don't test it against data.
Yeah.
The fourth is public available.
Yeah.
But it's not officially announced as public available.
Yeah.
So you can do it today.
I thought from us, it's going to be available.
Yeah.
But just at least for all tests.
Yeah.
Wait a minute.
What about stability of all the wrong system?
We promise that this is like a blockchain.
Yeah.
We change it tomorrow.
Yeah.
It will be difficult to verify.
Yes.
So we are, I mean, it's a large topic in a short month of time.
But we are public.
Yeah.
We are public.