So today we're going to talk about your software supply chain, the threats to your software supply chain, and SBOM does the response to secure your supply chain, or, or, or use the key components in that. And then we're just going to practically talk about how to generate it, to host it, to analyse it, and how to make it actionable, and we'll have a few, like a workflow and a demo.

So I actually have a video, because I was too scared to do a live demo. But, uh, you can pretend. It's a real console. So, um, um, I hope by the end of this you've heard about SBOMs. Uh, you've figured out that they're really important to, uh, It's really important to know a lot is in your software. And that you can use this to drive vulnerability management.

So here's an image from the Salsa website. And it's, um... Um, a framework for a software, uh, building secure software. Um, so yours, it shows your software supply chain. So your software supply chain are all the elements that go into building your software. All your tools, your CICD, your, your package manager, your artifacts repository, your source code.

And a huge part of it is your dependencies, which can be in house, but they're really likely to be open source dependencies. So that image is like, I went to the open source summer in Dublin. I think I saw five talks that had the same image. So I'm pretty basic, but what can you do? Uh, so open source software, it's like wherever there's software, there's open source.

I keep on seeing that number go up and up where like 90 percent of software contains open source. And it's a huge amount of software. It's really positive, like Kubernetes, Debian, Nginx. Um, innovation will be painfully slow without open source software. I don't want to do Kubernetes again, I don't think anybody wants to, wants to do that.

So, um, but it's not more, it's not less secure than NX software, but it's just a, a great move for attackers to attack multiple, um, multiple systems using the same vulnerability.

And if you want to secure your software, you have to secure your open source software. So the main threats in open source software is, um, attackers can target how you consume that software through public repositories like, uh, Maven, Central, PyPI, NPM, by hosting maybe malware and tricking you into installing it using type of spotting, which is like when you're using Ignis Sync when you're writing your requirements file, or dependency confusion, which is kind of using the mechanism for consuming software, where like, they figure out what's in your private repo, the names of the packages, push it to a public repo, and hope that somehow it's brought into your code base.

But the main source of the, uh, threats is probably critical vulnerabilities in open source. So something like log4shelf in the log4j package. And heartbeat as well, as well. So let's talk about the critical vulnerabilities Um, there was a research report by the Incident Responders in Palo Alto that was published in July, which shows that, um, the, the initial attack vector for, they looked at over 600 incidents, and the initial attack vector for, uh, over 30 percent of cases was critical to undergoing and using software.

But second only to phishing. And Log4Shell was like a really popular, it was the most popular open source critical vulnerability to use as an initial attack vector. And this was published in July and that was only out since December. So that was a bad one. So, um, and another report from 2020 showed that Heartbleed was still being used as a, um, it's still being scanned for, uh, to, to hack into systems.

In 2020, even though it was patched in 2014. So critical vulnerabilities have a really long tail and any vulnerabilities in open source software, especially problems, will have an effect for years and years. So log for shell will probably still be an issue in like five years time. Or maybe more. And the reason for that is that sometimes it's, um, patching isn't a priority for organizations.

Sometimes you're using abandoned open source software that's not been updated. Or a lot of the times you don't even know what you're using. So like a dependency of a dependency of a dependency, but it still can be used as an attack vector. At the end of 2020 I think, um, that really highlighted software supply chain attacks.

Um, basically they had a product, some networking product, and the state actor got in to their build pipeline, and it, the software was, uh, used by government agencies, critical infrastructure, loads of big organizations, and it was a, it was a huge threat to, and it kind of brought the issue up to like government level.

And the response to that was, I thought it was pretty aggressive by the U. S. government. They published, they signed this executive order on cyber security. Last year, and in it, they described, whoever wrote it, like, really understood how software was written. They understood that open source is really important.

And instead of saying, we need to pull out all the open source, and not use open source anymore, they said, no, we need to know what's in our software, and then we can secure it. And one of their mechanisms that they, um, highlighted for doing this was SBOMs, so software building materials, and they mandated that Um, software, um, sold to federal agencies will have to include an SBOMs.

And that's coming in about now. I think there's something in the Senate about it. Um, as well as that, after Log4Shell, the, um, critical vulnerability in Log4J, The White House brought in, you know, so this is like in January, they brought in representatives, representatives from open source, from the Linux Foundation, OpenSSL, and, uh, big tech companies that consume a lot of open source software, from critical infrastructure as well, and they brought them all in, took all the stakeholders in, and they came up with this plan, and they had a lot of money behind And, um, they, they were like this 10 point mobilization plan, which is pretty tech, basically, not the best one, but that, um, part of it, one of the steps was S bonds everywhere.

Uh, funding and initiatives to try, to drive adoption, improve tooling and training around, um, using S bonds. And two weeks ago, the European Union published their first draft for, uh, The Cyber Resilience Act. So it will be a few years before this actually comes into effect. But in it they mention SBOMs and how they expect SBOMs from suppliers to create the infrastructure.

So finally I'm talking about SBOMs. Like I haven't explained it yet. So the talk is like, uh, the new standard It's a software of non materials, but it's actually one of the new standards. I lied to you all. It's been around for ages. So, um, even the concept has been around for years. And, like, decades. In manufacturing, in food production.

So you get your box of corn flakes, you see the ingredient listed at the back of it. So a S BOM, a Software Built Materials, is a list of components of what is in the software. The version number, the naming, and the dependencies. And um, there's standards to support this. And standards are really important because they drive automation.

So there's two standards, both ISOs, SBDX and Cyclone DX. They're both great. Their, um, SBDX is slightly more licensing focused. Um, so it's going to be X because it's under a loss, but it's more

like S BOM will do is answer that question of what is in my software?

So, um, now we're going to go on to like the practical stage of what you actually, now we have a standard, how do you actually generate the S BOM? How do you host it? And analyze the S BOM for vulnerabilities.

So there's different stages of the software life cycle that you can actually generate the S BOM. You can generate it at source, you can generate it on the build artifact, you can generate on a container image, from at runtime, or at build time. And there's lots of tools, lots of open source tooling, but it's still an emerging space.

So the software composition analysis tools that work on source code or built artifacts can be really useful. If you have legacy code and you don't actually have the source, you're not entirely sure how it connects back to the source code, you can only work on the built artifact. So those tools are great.

Also the ones that work on the source code, The positives around working on source code is that longitudin is, um, uh, integrates nicely with CICD. It's really early in the software life cycle, so you can catch things earlier, that shift lefty. Um, I'll put the, and it can produce a, um, S BOM and accurate enough information.

that will be useful in your, to understand your software supply chain. Some of the negatives around, um, generating a source is that it can be, uh, less accurate than other stages. Uh, the reasons for that might include, um, test packages that are not actually in your deployed artifact. It might, um, it might not have this transient dependency.

So these are dependencies of dependencies. Or it might package managers and code installed outside of that is, uh, like kind of invisible, or it might not be able to figure out what dependency, what version of dependency you're using. Like if you say something like, um, in your configuration file, you might have something that I, I'll use any version greater than six.

But if your defendants, if you're creating your SBOMs. It's impossible for the, uh, the generator to know the exact, um, versions in the final deployed product. There's ways to improve their accuracy, like using NOC files and stuff like this, but generally it's thought to be a bit less accurate than other stages.

You can also generate your best BOM, um, On your build container images and some of the tooling around it is really nice. I'm actually involved with workflows around using container images are really nice. Um, anchors, toing the little l there. It's open source and um, uh, trivia as well has a open source generator and these can work.

They have knowledge of the layers in your o contain. They know where files are, and they, uh, work with package managers as well to develop this, uh, to generate your S1. So some of the positives are that, like, the workflows are really nice, they're in, uh, container images. Um, it can slot into your CICD really nicely.

Um, it can be really accurate. And some of the negatives are that it can, it can be a bit slow, it's a bit later on in your software. life cycle. It's the build artifact. It can also give you a lot of thoughts positives, Maybe the software on your container image that has nothing to do with the deployed, like it's not running on a deployed, uh, image and that has implications with vulnerability management where you're trying to prioritize vulnerabilities.

Um, so and also it works better if you build, if you build stuff using a package manager because... It knows where those, those files are.

Another way to build it is at build time. So this NTIA, it's the standard agency the US actually recommends doing that. So, that's great. There's not as much tuning around this. That's the biggest faulters. And also there's an issue with false positives as well where you might, they might list. The amount of, um, they might list packages that are not actually relevant in their running, um, running software.

Another time to generate them is at runtime. So, um, the positives around the runtime generators are that you are actually You want to, um, get a list of components that are actually running and you should prioritize these packages because they're exploitable. Um, because they're actually on your running system.

They'll also have information about what services are used, like if any ports are closed. That kind of thing can be really helpful for, um, security professionals trying Jbomb is an open source tool that will generate a one time one for java, javacosts, and there's a lot of proprietary tooling around container images and generating sbombs.

And maybe not sbombs, but like giving you information about this is what's, what's running on your, um, on your container or deployed container, or some of the negatives around it. It's very late in the stage. I mean, it's already running. So, uh, the positives are, it's really important information and really helps prioritize your vulnerabilities.

So generating your S1 at all the different stages, all the benefits. And it'd be cool to generate them all at all the different stages and merge them all together. And that workflow is still really early, but that would be ideal. Like, if you knew everything that was on your product, everything that was actually the most exploitable, that would be a really powerful, um, bit of information to have.

So, we know how to generate them, let's host our SBOMs. So the nicest way to, uh, the nicest ecosystem to host them in is Um, and it's, it's OCI artifacts because there's, um, there's tooling around, kind of like people are, are, uh, you can host your SBOMs alongside your container image using six door tooling, and so on.

You can even sign in and attach it to your image, and it's hosted alongside it in your, your commit in a different layer.

So, let's see. But hosting on OCI artifacts is, um, is, is not really defined yet. Like what's the best practice. So you can host them in a database in like a file store. You can host them on an archive repository. Like in CloudSmith, you might host them as a raw file format. We still have to connect that to your actual build artifact.

So it's not as nice a flow. There's one tool, Dependency Tracker, under OWASP, which will host all your, your SBOMs for you and has a, it's like the best, um, open, like, it's the best tuning for, for this problem. It can host all your SBOMs and do vulnerability management. So, that could be, uh, One way you can do it.

But we're kind of waiting for best practices around this, like, maybe package managers might decide to include an SBOM as part of their, uh, as part of their package or something like that. We're, we're still, we're still waiting.

So let's talk now about, we've talked about generating your S bond, where to store it, talk about what to do with it. So one of the main things that, um, one of the main use cases for S bonds is to, uh, drive vulnerability management. So you might want to say, um, am I vulnerable to that for sure? That would be a classic question.

Um, how do you do that?

So before we go on, we'll talk a bit about vulnerabilities. So, um, a vulnerability is a flaw in your software that an attacker can use to exploit, um, and can get into your system or your customer systems. So, um, some of the terminology around here include CVEs, which is Common Vulnerability and Exposures, I think.

And it's basically an ID that you can communicate about a vulnerability, so you're talking about the same thing. It doesn't have much information beyond that. Another thing that's important to vulnerabilities is the score, the severity score. So that's for a CVSS content. It'll tell you, uh, give you a score out of 10, or how severe a vulnerability is.

Like Lock for Shell was 10 out of 10. It's because of how common it was, how easily exploitable it was, and the end result was a remote code execution. There's another scoring system, um, EPSS, Exploring Prediction, which will give you more information on the likely college that this vulnerability will be exploited, which can help again with vulnerability prioritization.

So now we have an ID, we have a scoring system, we have to store them somewhere, and that's where vulnerability databases come in. One of the main ones is the NVD, the National Vulnerability Database, and that lists all the vulnerabilities. Um, of all the CVEs. So, but there's vulnerabilities outside of that.

Like, um, uh, like ecosystems will figure out there's a vulnerability before it gets a CVE. And then it won't be in the national vulnerability database. And usually these are in the security advisory databases. And each ecosystem will have its own one. So maybe ROST will have one. Uh, GitHub, NPM, they'll all have their own database.

Another thing that's important to vulnerability VEX,

Vulnerability Exploitability Exchange. So, apparently, like, over 90 percent of vulnerabilities in your open source vulnerabilities are not exploitable. And you want to concentrate on that 10%. I heard somewhere else only 3%, that was in the report. So you want to know the heavy hitters. This VEX standard is a companion piece to the SBOM.

and then VEX will tell you if you're not exploitable. So it'll say, um, Oh, I'm not exploitable. Although I have that component in my software, I'm not exploitable. And so these two together make, make it a more powerful and useful tool for security professionals to prioritise their vulnerabilities. So you might be vulnerable because you've patched your software, because you've configured it.

to close those ports, to not use something, or to, there's lots of reasons that you're not vulnerable. And this is a great way to, uh, communicate that. But, it, this is only a few months old, I think, so, there's, there's hardly any to deliver this. But dependency track is, to me, dependency track is always, like, early in, um, in all, especially anything to do with vulnerability uh, is able to understand this is that.

Um, and then finally, we have the SBOMs, uh, which is the tooling for analyzing SBOMs. So how can SBOMs help with vulnerability management? So, um, let's talk about the tooling and the workflows around that.

So you need tools. Do you have your SBOMs? And the components. What you want is, um, A tool to work on an SBOMs that can consume an SBOMs and then output all the vulnerabilities on their, their severity score. So there's different tools to help with that. Dependency tracker, a great tool for vulnerability management.

GRIPE is um, a tool, open source tool from, dependency tracker is open source as well. GRIPE is a open source tool from Ranker, which would tell you the vulnerabilities in an SBOMs in the standardised form. Um, six to record here because it will, it will actually allow you to host your vulnerability report in an attestation, you can attach that to the container image.

So it can be used as part of a workflow, maybe build your software, maybe build your container image, and you can attach this vulnerability report to your, uh, to your Docker image and say at the time it was built, there was no severe vulnerabilities. I always say severe in a book, because I was like, surely it should be like a higher standard than that.

But um, yeah.

So let's run through a few workflows to make, um, S1s actionable. Uh, this is a terrible diagram. But okay, so you build your container image, you push it to your container registry. It's like McKinsmith or whatever container registry you use. Um, and then you generate your, your SBOMs, you can attach it to your, your image.

And then you can, um, you can, instead of attaching it to your image, you can push it to dependency track. And dependency track will have, um, all the different vulnerability databases that can track, um, your, if you're vulnerable to any of the components. Any of the components listed in SBOMs will check if you're vulnerable to them.

And then you can set policies as well to say, oh, if I'm, if there's any vulnerability above high, then you can alert these people. And there's like, they have webhooks or integrations in Slack and stuff like that, where it will alert people. So that would be one workflow where, um, it'll continuously analyze the S form and then alert the relevant people.

So another workflow, and I'm going to do a demo of this. Oh, demo, that's video. It's all live. Um, so, I'm going to create my container image, push it to CloudSmith, um, create my S BOM using the sys. open source. tooling, uh, attach it to that image using the sys. org. Then, um, set up a continuous security workflow where like it'll, um, it will use Scribe to, um, monitor that SBOMs and see if there's any vulnerabilities above a certain level, and if it's above critical, it'll quarantine the image.

And quarantining is a cliché feature, but it could, instead of quarantining, I could do it via alerting. I don't quite, okay, so this is the image, this is the video, so, and I'll just talk through it. So this is CloudSmith. Um, you can host, um, all these different packages in the same repo. Um, there's nothing, there's nothing in the repo.

So we're going to push a Docker image to our, our, um, CloudSmith repo.

So great, we pushed it there. Um, let's see if it's posted on transcripts.

There it is, syncing. Um, while it's syncing, I'm going to generate a, uh, a public private key using cosign, which is 6 or 2.

And I can use it to sign the SBOMs.

So cosign generated there. I have present my password and I'm overriding the existing key. Now I'm gonna sign, do docker image using co-sign, sign using my, uh, private key and then point to that image. Now when I go back in, you should see the sign signature.

And there she is there. So let's go back and the next thing we're gonna do is to generate a mask button.

And we're going to generate them using SIFT, that open source tool. So SIFT, Docker image, and output it in a SPDX format. Oh, and just to mention, I did generate a public private key using Cosign, but they have an experimental feature to actually generate it using your email, so then you don't need to worry about storing your public private key anymore.

It's just, it's just really annoying. So, um, and that's experimental at the moment, but it looks like that'll, that'll happen soon. It'll just begin the, um, the normal features. So now I have generated my S it's

496 packages in that image. And,

go! There you go, it's finished.

So, SIFT can also generate the Excite 20X or machine readable. So this is the SDDX and this is what it looks like. Telling you versioning information, unpackaging information, and we'll just look for a few deadlier packages that are in it, just to show you. A few deadlier packages that are versioning. And now, so we're generating our SBOM, we want to attach it to, um, our image, but we just don't want to just attach it.

We want to attach it as a signed attestation, because adding a signature to it, uh, brings a lot more trust to it. So, cosign attach, um, SPDX as a, and then we're attaching the SBOM to the primary signature.

And I'm assigned it using my private key. And so now when I go back, I should see a new attestation. There she is there. Great stuff. So, I can't remember what I did today. I think I, um, extracted it. Oh yes, I can verify that I'm assigned using my private key. Constant verify. And then use the public key to verify that.

And we should say, good job.

Yep, signatures were verified. So let's extract that SBOM from our image. And then when we extract it, we can, um, check it for vulnerabilities. So extracting it is a bit like that, I don't like the, the code, like, um, you have to use jQuery and stuff like that. It's okay. So let's, um, check it for vulnerabilities using graph, which is the for Microsoft.

So yes, vulnerabilities scanned, um, 1, it

to fail on critical. So, uh, it has, it has failed on critical. And, um, because there was vulnerabilities above that severity threshold. So now that the severity is above that threshold, I want to quarantine that image. And that means that image can't be, uh, deployed or downloaded. Which means you can put a stop to it.

It's, it's, there's still, it could be out in the wild, but at least you're, you're not making the problem worse. Um, so I'm going to use the text of CLI, which is a wrapper around your API. And here you might also introduce some alerting as well. So you might message the owners of the, um, of the packages.

So you can quarantine it through the UI, or, um, I think like, just to drive automation, you should be using more, of, like, CLM. So I just quarantined it there, and it can't be downloaded. So, That kind of shows a, a, a workflow that, um, you could use to, to generate your SVOP and then do something actionable, maybe.

So I actually have a GitHub, in my GitHub, um, account, I have a, a GitHub action where, like, I set up a workflow every night or something to check for vulnerabilities. So if anybody wants to look at that, you're, you're welcome to. I, uh, forked it from, uh, Guy Dahler in, from Ankara, who now is working at Chainguard.

So, and I just, uh, put in the extra stuff about quarantine and, um, music cases.

Next slide. Yeah, and

there's the, that's where my GitHub workflow is. But you can, you can see how it can be a useful tool. Next slide. That's not driving you down. It's just constantly checking. It's not, um, it's not interfering with your, um,

So, um, future work for SBOMs is probably already better too. For different, for different ecosystems. I like the workflow for container images. Maybe that could be a bit faster. Uh, better tuning around merging SBOMs generated at different stages and best practices around hosting your SBOMs, like, especially for non, uh, OCI container bridges.

So tuning, tuning, tuning is mostly where, uh, the future work will be. But like I said at the beginning, there's a lot of funding from that 10 point mobilization plan. Um, that hopefully will put a lot of activity into that area. So, um, SBOMs answer the question of like, what is in my software? And this will let you ask, like, am I vulnerable to the latest critical vulnerability?

So it's really, uh, a powerful tool for driving vulnerability management. It's not everything, but it's an important component to it. Um, so I know the tooling isn't like all there, but there is, you can generate an SBOMs. So, um, you should, you should try to generate an SBOMs as part of your build pipeline.

And, um, and then ask your suppliers for SBOMs as well. Uh, don't let perfect be the enemy of the good. SBOMs are relevant right now. You don't have to wait for the tooling to be like absolutely perfect or the workflows to be perfect. So that's it. Yeah. If there's any questions. Um,

that's all I got.