0:00 Introduction

0:00 Hello and welcome back to the Rawkode Academy. You may remember recently we did a video on Scribe Security. They offer a platform that allows you to collect evidence, visualize that evidence and understand the supply chain of your software. What we didn't cover in that video is that Scribes Security's platform also has a command line application called Valint. And we're gonna take a look at using Valint today to collect that evidence and store it. Not only that, we're gonna take a look at enforcing policies to make sure that your software and supply chain are up to scratch. So let's take

0:39 What is Valint and Why Use It?

0:39 a quick look at the scribe security documentation for Valant. Okay. Here we have the documentation. As I said, Valant is a command line application. Why is this interesting? Well, it means you can run everything you're about to see locally just as I am running it locally on my machine. Not only that, because it's just a command line application, you can run it in your CICD pipeline. You want to run Valant and GitHub actions? Go for it. Valant can even be run as an admission controller within a Kubernetes cluster, allowing you to enforce policies that verify

1:15 your supply chain at runtime and production. So how do we get started? Well, the documentation has two ways to get access to Valant. Number one, curl and pipe to your shell. You can grab it from get.scrapesecurity.com/install.sh, where if you put that through a shell, you will get your Valant in your local directory. Or you can pull the Valiant container image from their JFrog instance, which is scrapesecurity.jfrog.i0/scrape-docker-public-local/ valiant latest. Of course, all of this will be in the documentation and we will make links to it in the show notes below. So you don't have to listen to me

1:21 Getting Started with Valint

1:57 read out slashes, dashes, and all sorts in between. However, get yourself access to Valent and you can follow along with this tutorial. So as I said, Valent allows you to collect evidence to help you build out supply chain security posture. That evidence can come from Python or from PyPI as we can see on the support table here. It also comes from NPM, from Go, from Docker, from Red Hat, Java, Debian, and so forth. Hopefully, that covers a good portion of the landscape of the runtimes and programming languages that you're using and the operating systems or technologies

2:05 Evidence Collection Capabilities

2:32 you use to deploy. As far as evidence goes, course, we have access to nest, segstore, CVEs, etcetera. And the really cool thing about what we're gonna show with Valiant today, I think you don't need to push that evidence to scribe security, although you should with that very generous feature we covered in the previous video. But you can actually store that evidence inside of an OCI artifact itself, and we'll be doing that on today's tutorial. And again, because it's a command line application and there are GitHub actions available, you can run this on GitHub actions as

3:03 part of your CICD process. Okay. So why don't we generate a bill of materials for a container image? What do I mean by that? Well, we want to start collecting some evidence. We want to pull down an image, understand how it's built, and generate that bill of materials. And we can do that with Valiant. So step one is obviously just make sure you've downloaded and have access to the Valiant command line. Once you do, you have access to the Valiant BOM command. We can type help on that. There's a whole bunch of options to help you start

3:05 Generating a Container Image BOM

3:34 collecting all of your evidence. So let's do Valiant BOM. Now you get to choose the output format that you wish to store it. I'm gonna do a test Salsa, although we'll cover more options in just a moment. Lastly, provide a container image that you want to collect and store the evidence for. For me, let's do Alpine latest. This pulls on the image and then will give you a prompt to ensure that you're happy to publish the evidence to the transparency log. Let's hit yes and this will ask me to log in with Segstor. And done. Alright. So let's go through this

4:07 Attesting Evidence with Sigstore

4:13 in just a little bit more detail. First, we have said that we want to generate billing materials for Alpine latest. We see here that Valint will actually pull down the image from the remote registry. In this case, that is Docker Hub. We can also see that it collects some context, which is type local. And that's just because I'm running the command line application locally on my own machine. Valiant has knowledge and awareness of other contexts such as GitHub, GitLab, and so forth. And we'll see a list of them in a moment when we head back to the documentation.

4:43 Then you'll see we get a little bit of a pop up asking us to confirm that we're happy for some information to be stored in the transparency log. So why did this happen? Because we did an dash o, a test salsa, the default attestation is with Sigstore. If we run v a l n dash dash help and scroll up to here, you'll see that dash dash test default supports x five zero nine, Segstor GitHub or Segstor with Segstor being the default. That just means that our information will be published to the public transparency log and signed with Segstor.

5:17 Verifying Evidence and Policies

5:17 Once that's all done, we're now in a position where we can actually take a look and verify the information that we generated and that verification step includes any policies that we define. So let's run v lint verify and we set the input format, which will be the same as the output format we used earlier. We can then say that we want to verify the bill of materials with Alpine latest image. As you can see, this pulled this down from the public record and we have a cache stored in our local directory and it also verifies the certificate authority

5:53 that signed this information. As you can see, we already have a policy called Rawkode only applied which passed and we'll take a look at that in just a moment too. Let's talk about that environment context. When I ran it on my local machine, the context was local. Why? Well, because I ran the command of my own personal machine. However, when you're generating your bill of materials, it's more likely that this will run-in an automated environment such as your CICD pipeline. As you can see here from this list, that Valence supports and understands various contexts. It's likely you're probably using GitHub actions as

6:03 Understanding Environment Context

6:30 that's where a lot of open source and even proprietary software development happens these days. Of course, GitLab, Azure, Bitbucket, and so forth are all very popular options and also provide their own CICD environments. When you build your build materials, you want to suck up as much information from that environment as possible, like the branch name, the repository name, the committers, the tags, and so forth. And if we scroll down, you'll actually see that as part of this environmental awareness, Valid collects the URL, the branch, the commit, the tag, even the workflow names and the actors and the build number. So collecting this

7:07 information just means that you can build policies to ensure that your production cluster only ever runs workloads where you can prove through evidence collection that the build happened on your CICD system and signed with the keys that you expect. So now let's talk about that policy. So we can definite well, you should definitely have a policy that ensures your proprietary software only runs if it was built in your CICD pipeline. However, you can get started with policies much, much easier. And say this directory, I have a valent dot yaml. And say this, I have an

7:26 Policy Enforcement Explained

7:43 attestation cocosign policy. This just means a cosign policy where I have Rawkode only. And we already seen this name run when I ran the valent verify. We have the enabled true flag just to make sure this policy is enforced or checked when we run a valent verify. And then we can add one or more modules to run as part of the policy. Here, I have a module named Rawkode module where the type is to verify the artifact. We enable this and what we're seeing is this artifact must be signed, must be in the format a test salsa and the signer

8:18 identity must be one of these people and in my case, I'm using myself, which is david@rawkode.academy. So let's change this policy and break it. Let's say I use rawcode.com and now we run valent verify dash I test salsa alpine latest. Again, this is going to check the evidence creation within the public record, pull it down to my machine, and then our policy runs against the collected evidence. As you can see here, the signature for this evidence was not me, at least was not david@rockode.com. This time, it goes, hey, actually, this is signed by david@rockode.academy. So you can see how powerful this would

8:28 Policy Demo: Breaking and Failing a Check

9:07 be if your CICD system is configured to say in something. You don't want another workload not saying about identity running in your cluster. So let's understand evidence collection in a little bit more detail by diving in to the output itself. Let's run valent BOM again with the attest salsa output format. This time, we're gonna set the output directory to be evidence and again we'll run this against the Halpine latest. This is gonna make sure we have the latest version of the image, collect all the evidence, ask me to sign it once more, which we can do here and then it

9:17 Detailed Look at Collected Evidence

9:46 will store all of the evidence that collected into the evidence directory. As you can see here, we have a cache dot JSON and if we just cap this and throw it through j q, we can see that local context and the information that I collected. This is the information that you can use to build and enforce your policies. And if you do this in GitHub, the context will contain all that extra information such as the branch, the URL, the tags, and so forth. But locally, we have access to my host name on my machine, the user that built it, the time,

10:24 the inputs and then the subject context all there and available for you to introspect. So so far, we've worked with container images, publishing the evidence to the public record, and storing information and cache locally. But what if we wanna keep that somewhere that is a bit more transparent and visible to our organization, our clients, our customers, and so forth. So let's do a valid BOM test salsa. Only this time, we'll scan a git repository. Mongoexpressmongoexpress.git. Now, I've already run this then the cache is already available locally, so we got a cache hit and it doesn't need to do

10:31 Storing Evidence in OCI Artifacts

11:05 it again. Sweet. However, that cache still lives on my local machine. So let's push it and store it inside of an OCIR effect. So this time we'll run Valiant Bomb, a test alpha, and we're going to scan my GHCR Rawkode clustered v two image and enable the OCI store. And make sure you spell Salsa correctly. So much like all the other commands, this is pulling down an image, collecting the evidence. However, this time, it's going to store the evidence remotely on the OCI registry next to where the container image actually lives. And that's done. You trust me. Right?

11:55 Let's head over to GHCR where we can click on packages, clustered, and here we go. My v two image was built a year ago. However, less than a minute ago, we published our attestation to the OCI registry. This can now be pulled, inspected, and verified again by my team, my organization, my suppliers, my customers, and so forth. Awesome. So one last thing. So far, all we've really covered is salsa attestation, which gives us confidence or a record of where things were built, how they were built, and when they were built. But Valens supports all of those run times and languages that

12:22 Scanning a Git Repository

12:35 we covered on the graph at the start. So let's take a look building a bill of materials for a Go project, And let's keep this topical. I'm in a directory and taking a look at Blue Sky Go SDK or program called Indigo. From here, we can run valent BOM where we specify that we want to run this against the current working directory. This has already been run, so it was pretty fast and we can see that the analysis has already been completed. And the output has been stored and the generic valent cache. Let's run this one more

13:05 time. And just to make things a bit easier for ourselves, we'll set the output directory to BOM. Now we can go inside the BOM directory where we see we have our cache dot JSON much like we had with the Salsa association. We can cat this and pipe it through j q, but we also have this other fail, which is the complete bill of materials. Now when you do a test salsa, this is a encrypted payload. However, without a test salsa, we have all of the information and the bill of materials available. Let's do this one more time, but put

13:13 Examining the Software Bill of Materials

13:39 it through a pager. Here, I can see that the default output format is CycloneDX. We can see the components involved as part of this bill of materials, including the GET repository and so forth. However, what's really cool is when we scroll down, we get into all the dependencies because Valen understands Go, understands Python, understands Node and NPM. We get a complete bill of materials including all their dependencies, the versions, and where they came from as part of our bill of materials. So there you have it. Valant is a pretty sweet command line application that you can run locally

14:12 Conclusion

14:17 in CI or even as a mission controller with Kubernetes. It allows you to build attestation for Salsa and Cyclone and a build of materials in various formats, looking into various runtimes programming languages and even context such as local, GitHub, GitLab and so forth. So go check it out. Improve your supply chain posture today. Go have some fun.