0:00 Introduction

0:00 Supply chain security is all the rage in 2022 moving into 2023. The reason being, there have been some pretty huge attacks on well known software that we all use every single day. Google introduced us to the Salsa framework for supply chain security and integrity validation back in 2021. However, most people just aren't aware of their coverage and compatibility and compliance with the framework. End to end security doesn't need to be hard. And today, I'm going to show you how to get started with Scribe security. Scribe security is a framework that you can use by hooking up a small CICD pipeline

0:40 probably with GitHub actions that gives you all the details that you need to know to know how compliant with the SASSA framework you are and how close you may be to that next level. Scryb security is free for many organizations. Free for one seat and up to 100 bills per month. So it's easy for organizations to get started and understand their compliance across however many products they have. If you want to give more people access to your results, then you will have to adopt one of their paid tiers. So go check out the pricing page for

1:14 more information. Everything I am doing on the video today is 100% under the free plan. And also this video is sponsored by Scribes Security. They sponsored my time to take a look at their framework and show people how to get started. So without further ado, let's dive in. So let's start with what I've scanned so far. When you sign up for Scribe Security, you will get the demo product which scans a Mongo Express server. We can see that the integrity is validated, and we'll get into that in a moment. We can see the scan date and time,

1:31 Exploring the Scribe UI

1:45 number of components, number of vulnerabilities, and salsa level and compliance, as well as the nest score. I've also forked a real open source project called Directus, which is a headless CMS that powers data frameworks with their Studio UI. I've forked this instead of using any of my own repositories just because it is a complete product that you can use today. A lot of the code that I have in my repository is for automation, platform, and even clustered, not something that I would specifically ship to an end user. So I wasn't getting the full value from the scans. So for this

2:23 demo, let's focus on Directus. When we click on it, we can see all of the versions. Every time you push to the main branch or cut a release with a tag, you can have the CICD workflows run against your software, giving you a new version. What I like about this, and I'm gonna show you before we even dive into any of the result, is that we can publish these results, giving access to our customers or our partners who maybe want assurances to our security compliance. When we click on a version, we get a nice overview

2:25 Directus Scan Overview

2:56 of all of the scans that Scrape Security has done against our repository and our build artifacts. And you can see that Directus is already Salsa level two compliant. Hey. For salsa level three, there are two tasks out of 12 that need to be completed. And for this NIST secure software development framework, we have nine pending tasks or controls that we need to bring under compliance. On the right hand side, we have the integrity validation. This shows us how many open source packages Directus is consuming under the hood. A whopping 1,071. Of course, this is a TypeScript project using

3:03 Salsa and NIST Compliance Details

3:35 NPM and Nodes. Of course, there's gonna be a lot of dependencies. We can also see the number of source files that were scanned. The directors project itself, almost 2,000 pieces of code. On the bottom, we have an overview of the vulnerabilities against the container image that was built for this project. Right now, we can see that there's one critical, 16 high, and then a 80 medium and 49 low. And again, we'll dive into that in just a moment. So let's take a look at our Salsa compliance. You can click on this compliance tab here, and we'll see the two

4:10 controls that have failed that would allow us to adopt Salsa level three or at least broadcast and publish that we are Salsa level three compliant. Control number one is source history verified. Assigned commits are not required on this branch, which is a critical control in Salsa level three. And also there are no branch protection rules stopping from force commits, changing the history on this branch. That just means that in theory, someone with the right level of access could modify the branch history losing the provenance that we need that proves the history is what it claims to be. Now besides the fields,

4:53 we can see all of the Salsa controls that were passed. Our build was defined as code using GitHub workflows. Providence cannot be falsified. Awesome. The build was executed by a build service here, GitHub actions. We have signatures. The environment is isolated. The providence is available, which we can click on and view, which we are viewing. And all of our code is in version control. We can then see the nest field controls below. We can see that we don't have automatic package scanning for license implications, the organization's domains, and a secure verified next to his name and so forth. Now it's

5:31 up to you as an organization and as a team to understand the level of compliance that you want for your software and you want to give assurances to your customers. So really take these controls as a gate. If you want to get to SANSA level three, start configuring the GitHub permissions that give you those assurances. What I like about some of these controls is that Scrape Security isn't just taking a look at my repository and and the artifact. It's actually taking a look at the GitHub settings like these two here. It understands that the branch protection rules are available, but they're just

6:05 not configured the way that we need. So that's pretty neat. Moving over to vulnerabilities, we actually get a no understanding of the packages being consumed by our software. And we can see the one critical, which was updated on January 24, which is for this CVE here, like so. So it's always great when things are doing security scanning, link you back to the source material. Tells you the database that it came from, the CVSS score, which we all know is how our mess again is there to give you more information and context to make the sessions yourself. We can see

6:09 Analyzing Vulnerabilities

6:39 the affected version of the package and now we have an understanding that maybe there is an update and we can go take a look at that to see if the CV has been rectified upstream. If you want to sort by any of these, you just click the headers much like we would expect with any UI like so. Next, we have a software bill of materials generated for our application, and we even can see if the integrity is validated across each of these dependencies. This uses an open source tool that we covered just recently on Rawkode Academy called GitGap.

6:57 Software Bill of Materials (SBOM)

7:14 If you're curious about that project and how it works, go click the link in the description after this video. So we can see which packages have their integrity validated when some are not covered. And to be honest, that is okay. It just means that they don't have all the same controls in place on their repository to protect the assurances that we need with the framework. You see the package manager used for all of these and given that this is a TypeScript project, of course, it's NPM all the way down. Then we can click on licenses. From here,

7:41 License Information

7:43 we can see all of the licenses, all of the dependencies to understand what the coverage is across them all. This is something that we often don't even think about as we'd NPM install new packages into our projects. Are we governed by any licenses that we didn't know? This is probably where your legal team may want to spend some time. If your application is not open sourced, you may have to make sure that you are adhering to the license and the rights given to you permitted by the upstream open source license available. Then we have our context. This just

8:14 Build Context

8:14 tells us the GET repository and everything else from the build system that we need to understand how all this information was generated. So how did we get all of this wonderful information about our repository and our container image? Let's pop open the GitHub action. I've given it a name called scrape security and have asked it to run on all pushes to the main branch. As with all GitHub actions, we check out the source code of the repository. And then we're using the scrape security GitHub actions themselves. Here, we're seeing use Scrape security action bomb. We give this an ID so that

8:22 Integrating with GitHub Actions

8:50 we can reference the output of it later, and we're telling it to scan the current working directory. You can generate the artifacts without uploading them to Scrape if you want, but you can enable the Scrape integration and provide a client ID and client secret. You can also provide a product key, which means that you can name what the product is in the Scrape UI. Now how do we get the client ID and the client secret? Well, from the Scrape page, click on integrations, where you will see the client ID here and a sophisticated version of the secret which

9:14 Getting Scribe API Keys

9:21 you can copy and make available to get hub actions. Next, we can scan the container image that is produced by our build system. Here again, we're using the action bomb action with the target set to a docker hub container image. This also works just fine with g h c r dot I o. Next, we ask it to upload the two outputs from our first two scans. Then we do a salsa statement verification or generation. We were just asking action bomb to run one more time. This time, we're asking for a format as a salsa statement and then we ask

9:57 for the provenance to be uploaded as an artifact on the build. So in under 55 lines of YAML, we can generate our bill of materials, scan our container images, upload all of our artifacts, to scribe, and get a UI that gives us all the information that we need to understand our Salsa compliance, the vulnerabilities within our container images, and even share them with our customers and partners. So go check out Scryb. As I said, for a single seat, 100 builds per month, you can get started for free. Enjoy.