Hey, thanks for coming to my session on making software billing materials, or sboms, actionable. I'm Ciara Carey. I work in developer relations in cloudsmith cloud native artifact repository. Prior to that I worked as a software engineer for over ten years. But it was only since working with artifact repositories, because they deal with your built artifacts, they deal with your signing keys, and they integrate with public repositories. And they have a good idea about how artifacts are built using metadata that I really understood the software supply chain. So today let's talk about that software supply chain. Let's talk about the threats to your software supply chain. Let's talk about sboms, your software bill of materials, as a way to mitigate against those threats. Let's talk about the practicalities of an sboms, how to generate, host and analyze an sboms, and let's make them actionable. Let's go through a workflow and we'll finish off with the future of sboms. So your software supply chain contains all the steps that go into developing, deploying your software, including your source code, your scripts, environmental variables, ides plugins, your build tools like your CI CD, your artifact repository, your package managers, and a big part of it is your third party dependencies. They can be proprietary, but they're very likely to be open source. And here we have that lovely XKcD image which really highlights open source software, how important it is and kind of how neglected it is at the same time, open source is really incredibly positive. Without projects like Kubernetes, Debian, Nginx, Apache, I could go on forever. Technological innovation would be painfully slow. I don't think anybody wants to redo Kubernetes again. And that's why wherever there's software, there's open source software. I think a conservative estimate is that over 80% of software contains open source. So mess apart of securing your software supply chain means securing your open source software. So let's talk about these threats in open source software. So the different kind of attacks on open source software can target how you consume your open source software through these public repositories, like Maven Central for your Java PyPi, for your Python NPM registry for your node. And some of the targets include dependency confusion attacks where attackers can guess or gain information about your private repositories. Find out those package names, try to push them to public repos, and using the mechanism of updating, they hope that they'll bring in the malware, repo malware packages into your code base and the type of attack is type of squatting attacks were they hope that developers bill make a typo when they're on their dependency list, maybe in their requirements text file or something, and they've posted up a similar sounding package and they hope that you bring that in. They want to trick you into bringing in malware into your code base. But the most common source of attack are critical security vulnerabilities in open source like Logforshaw, which was a critical vulnerability found in December of last year in log for J, a really popular Java package. Another attack was harpled. This was from 2014 and this vulnerabilities was in OpenSSL and they both had a huge impact. So let's talk a little bit more about critical vulnerabilities in open source. In a report by Paolo Alto's incident responders in July of this year, they analyzed over 600 incidents over the past year and they found that vulnerabilities in software were the suspected initial access vector in 31% of cases, second only to phishing. And log for shell was the most popular open source vulnerability to be used. When you consider this was in July of last year. Log for Shell was only publicized in December prior to that, and it became like the number one attack vector for open source. That's crazy. And other research from 2020 found that in 2020 the harp lead vulnerabilities was still exploitable even though a patch was released in 2014. That kind of shows us that these vulnerabilities in open source have a very long tail. Well, why is that? Well, sometimes you're using an open source package which has been abandoned, and that package, all those dependencies of that package use obviously aren't being updated. And that's how these unpatched open source packages get pulled into your system. But probably more likely patching. Maybe it isn't a priority for your organization. Or another very likely thing is that you don't realize that you're vulnerable. You're using a dependency of a dependency, and that dependency is vulnerable and you're actually still exploitable even though it's a few steps away. So developers need a tool to help them identify all the components in their software to keep them up to date with their vulnerabilities. I want to highlight a software supply chain attacks that really highlighted this issue to the industry. It was the solar winds attack in, I think it was December 2020, and it was a big attack on the software supply chain and it brought a lot of government agencies, big tech companies at risk. And after that solar winds attack, the Biden administration published an executive order to improve the cybersecurity of the software supply chain. And in that executive order, they outlined how they realized how important open source software was to your software supply chain. And instead of saying, let's pull out all that unsafe open source, they recognized that was going too far. That open source is really positive, but they wanted to have ways to make it more secure. And in that executive order, they mandated that organizations selling to the US federal government will be required to provide SBoms software bill of materials. They instructed the NTIA to come up with a minimum elements of the sboms. And since then, there's been the log for shell critical vulnerability. And after that, the White House brought in all the stakeholders, or many stakeholders, from open source and from big tech, and they came up with this ten point mobility plan. There was 150,000,000 that big tech put behind it. And one of the ten points was sboms everywhere. They wanted to improve the tooling and the training around s bombs. Outside the US, the EU have published a cyber resilience act in September. And in that was the first mention of sboms. It'll be a few years before that's consulted on and enacted. So I've spent all this time talking about software supply chain. I've even mentioned sboms, but I haven't really explained them. So your software bill of materials, or your SBOm lists all the components contained in a software product that includes your dependencies and the dependencies dependencies. Also the version number, the component name and the supplier name. So an sboms in a standard readable format is really important. This is what drives innovation, what drives automation, even. And you can use this to trigger security alerts. And luckily, the sboms, we have two great standards, SPDX and Cyclone DX. They're both great. SPDX leans more into licensing and Cyclone DX leans more into vulnerabilities management. So sboms, at their core, answers the question, what is in my software? And that's really powerful. When a new vulnerabilities comes out, you can use your sboms to see if you have that vulnerability in your code base. So now let's talk about the practicalities of the sboms. How do you generate an S bump, host it and analyze it for vulnerabilities? So let's start at generating an sboms. So there's loads of great open source tooling to generate an sboms. And let's go through the different stages of the software lifecycle that you can actually generate your sboms. So you can generate your sboms at your source code level, so this is really great. It's really shift lefty very early in the software process where you can create your sboms, and the problems with it though is that it tends to be a bit inaccurate, especially around version numbers, and it mightn't give you the transitive dependencies. So this is the dependencies, dependencies kind of information. Another time to generate it is that build time. Now this is the time that's recommended by the NTIA, and there's some tooling around it like cyclimds, SPDX, but there's not an awful lot of tooling around this. The different systems need to come up with new tooling for this. Another time to generate an SBoms is on the built artifact itself. This might be needed because you might know the specific source code that this legacy artifact came from. It might be the only time that you can generate your S bomb, but it tends to be a bit less accurate. Another time to generate your S bomb and it has really nice workflows around it, is a container image, so generated from a container image, and some of the lovely open source tooling around this includes anchor sift and aqueous trivia tools. They can both generate an s bump from a container image. And the positives around that are it can be really accurate, some of the negatives are it can be a bit slower, it's a little bit later in the software development lifecycle. And also if you build stuff outside of package managers, it's not as accurate. And then the last area I'll highlight is generating an sboms at runtime. For example, using this jbomb tool which can generate a runtime s bomb for Java projects. The benefit of generating it at runtime is that some of the other ways of you emerging sboms will list all the components in your software which is actually what you want. But the problem is apparently only like less than 10% of that is actually exploitable. So for security professionals, you want to know what the most exploitable 10% is. That's were these runtime software sboms generators come in, they'll tell you what software is actually running and even like what SaaS tools are running, what ports are open and closed. And that will give you a better idea of what is exploitable because it won't list software that's not running on your system. What bill be great is take the best bits of all the different stages of emerging sboms and create a mega sboms generator. So super accurate, but then also give you an idea of what's the most exploitable but that's not a thing yet. So now let's talk about how to host your sboms so container images can use six door tooling to host their sboms. Six Door is an openssF project that aims to make it easy for developers to sign, verify and protect their open source. And Sigstor's co sign projects allows you to sign images and attach sboms and attestations to container images and they can be signed as well. Cloudsmith we integrate with cosign, so you can do all that stuff using cloudsmith. The best way to host your non OCI artifacts so just your random packages. The best practice is not fully understood yet. You can use databases, sure you can use dependency tracking or tooling. You can use artifact repositories stored as a raw file, but the best practice around that it's not fully understood. I've heard some talk about piggybacking on the OCI container and OCI artifacts, the way they do it. I'm not sure exactly sure how that would happen, but let's wait and see. So let's talk about sboms and the primary use case of vulnerability management. So let's look into a bit of terminology or varying vulnerability management again. So what is a CVE? A CVE is common vulnerability explosures and it's basically an id about a vulnerability, so that you know that you're talking about the same thing with somebody else in the industry. Another thing is a vulnerability needs a scoring system. You need to know how exploitable, how dangerous is this vulnerability? And I'll talk about two scoring systems here. The CVSS is a well known one. It's the most popular one and has scoring system from one to ten, one being the least exploitable and ten being most severe. And if you log for shell, for example, that was given a ten out of ten in the CVSS score. That's because it was easily exploitable. It was like the remote code execution was the vulnerability, which is the worst thing that can happen. And it also was very common, so it got a really high score. Another scoring system is epss and that has some predictability in it, predictions on how likely it is that this vulnerabilities will be exploited. So you have your scoring systems, you have your id, and then you need like a database in order to connect them all. And the most popular database is the national vulnerability database. And that bill store all the vulnerabilities with the CV. But of course there's vulnerabilities outside of that realm. And the big ones are the security advisories. So different ecosystems will have their own security advisories like Rust has one Pipi GitHub and they tend to be earlier in the process. So before you get a CVE, it might be published to one of these security advisories. And I want to mention as well another standard connect to vulnerabilities management. So this is a new standard and it's a companion piece to the sboms. It's by the same people, the NTIA, and it's vulnerability exploitability exchange or VEX, and it tries to help. When were talking about false positives, apparently 90% of vulnerabilities are like not exploitable and that could be because the software has been patched. The compiler doesn't load the artifact affected code or some protections exist in your software to counteract this vulnerability. And so you might have a software bill of materials in sboms and you only really want to look at the top 10%. You want to be able to order by the worst to the least impactful. And VEX can be really helpful here, but it's not really been used in the wild yet. Although the standard is there, I don't think there's really good workflows around it yet. So it's very early stages, but it's good to keep it in the back burner. So how can an sboms help with vulnerability management? The primary use case of sboms is to analyze them for vulnerabilities and to see if any components can be an attack vector for your software products. Sboms are especially powerful when critical new vulnerabilities like logj for shell are discovered and organizations want to know if and where they are affected. And a good way to do this is continuously scanning your sboms is a really efficient way to check for new vulnerabilities in released software. So let's go into a few workflows and the workflow I'm going actually just one workflow. The workflow I'm going to highlight is around container images. It's the most mature workflow around sboms and vulnerabilities management. So I'm going to use some open source tooling. Sift and gripe. Both encore sift can be used to generate an sboms from a container image. Gripe can be used to analyze an sboms and it can also analyze container images or file systems. But here we're going to use it to analyze an sboms. I'm going to store the s bomb in my cloudsmith container registry using cosign tooling and then I'm going to finish off with an action when we find a vulnerability higher than a certain level. I want to quarantine my image, and I can do that with Cloudsmith. So I'm going to play a video now of this demo. So here we are in cloudsmith. This is a repository, and you can see that there's nothing there. Loads of different types of packages can go into the same repo as their multiformat. So let's push a docker image to our cloudsmith repository. It's a ruby image that I'm pushing. And if we go back to the repo, we should see this image being synced up there. And you can see docker image is just being pushed to cloudsmith. So that's number one. I've pushed a container image. The next thing I want to do is to create a six door key pair to sign the image. So I generate a private password for the private key. And now I have a cosign public and private key. Now I'm going to sign the image, and that's being to be pushed to my container image in a layer, that signature. If we go in here into our docker image, we can see that the signature has been added to a layer in that container image. So the next thing I want to do is to generate an sboms using the sift open source and core tooling. So you can see here sift docker image name output in SPDX. And we'll just wait for it here to complete. Loaded the image, parasing the image. And now this is going to be attached to a layer in that oCI image. Looks good. Let's check back in the cloudsmith registry. So here, let's have a look at that s bomb this SPDX sboms. There you go. This is the SPDX standard. And you can see it contains a debian package. So now let's push this sboms to our container image using cosign. And it's going to be signed as well. Let's go back to our. There we go. I put in my password. Let's go back to cloudsmith. We refresh the page. We should see the sboms in a layer in this container image. And now we can actually verify that signed image. So using the public key. And that will verify that it's been signed by me. Yeah. Signatures were verified against the specified public key. Cool. So let's extract that payload from the container image. And here we use this. We extract it out there using jquery. And now we have extracted the signed sboms from our container image. And now let's generate all the vulnerabilities using open source tooling. Gripe. Brilliant. So we've created a vulnerability JSON file, and we can actually also push that to our container image in another layer as well. We can find that as well as an attestation. So the next thing we want to do in our workflow is to actually quarantine that image. If there's a vulnerability above a certain level. And you can see here we are checking to see if gripe fails, then we're going to fail and we're going to quarantine that image. Were just getting the slug there. And we're going to quarantine that image programmatically. Cloudsmith quarantine add. And that's using the cloudsmith Cli. And so that means I can't deploy that image to infrastructure or download it. So there I've showed you a workflow of how to push an image to cloudsmith. Generate the s bomb using open source tooling, push that s bomb and host it on cloudsmith's container registry using cosign. Grab that sboms extract, get the sboms payload from it, check if there's vulnerabilities using gripe open source tooling. And if the vulnerabilities are above a certain level, I want you to do something actionable. And were the actionable thing that we've done is to quarantine the image. So now let's talk about future work. So sboms tooling allows you to, when a new vulnerabilities comes on board, that you can use your sboms to find out if you're vulnerable, if your co base is vulnerable. And it's great to have workflows around sboms, but really, that's where a lot of the future work needs to concentrate on more tooling, better workflows, so that you can practically bring this into your CI CD and to use it as a developer, as a security person, in the development team, as a vendor, and as an end user. But you can generate your sboms now using tooling. And I expect that this tooling is only going to get better. These workflows are only going to get better. So yeah, generate your sboms of try to make vulnerabilities management in open source security software a little bit easier and yeah, do that. Okay. Thanks for listening to my session. Talk to you.