Great. And to analyze your SBOM, Chris is going to talk about his, his tooling, and then I'll go into Cloudsmith integration with Sixth Door to let you host SBOMs. Then we'll finish up with a. Demo on making S buttons actionable and we'll have our fireside tap chat with our team and answer any questions you guys have.

So before we start, there's a few housekeeping things are we have a moderator today, Hillary. Thank you for all your work. And she's going to be monitoring all the chats. So we're streaming on four different platforms. If you're on, if you're on Twitter and YouTube. We can't, you can't actually use the chat or the poll functionality, but we will be watching for your tweets.

Same with LinkedIn, we're, if you chat in LinkedIn chat, Hilary's gonna be there looking for questions. So please stay to the end, and we're giving out three different prizes, it's like, What do we call it, Nick? The Cloudsmith prize pack, I think. That's right. So yeah, so you have to stay till the end.

And another thing is if you want to watch this later, this is going to be available on Cloudsmith. com forward slash blog before the end of the day. So let's get started. Oh, sorry. A few introductions. I'm Ciara Carey. I work in developer relations in Cloudsmith. I started there last year. Before that I was a software developer for over 10 years.

So I'll pass it on to Christopher.

Hey guys. My name's Christopher Phillips. I'm a senior software engineer at Anchor. And if you've ever interacted or done pull requests on SiftrGripe, you've probably seen me. On the issues or just helping you get along so can't wait to meet everyone and show off the tools

We'll go to Alison, VP of Product for Cloudsmith.

Yeah, sure.

i'm Alison. I am vp of product at Cloudsmith

And hi, I'm David Schmitt, staff engineer at Cloudsmith. I've been building out the the SBOM storage on our service. And so I'm here for that background.

Yeah, so a little bit about Cloudsmith. Cloudsmith is a cloud native, fully managed package management as a service. Our mission is to help organizations address the complexity of managing software artifacts at scale. So across many teams or in support of many customers by solving those problems for them, we can then deliver on our vision, which is helping organizations solve problems of trust by becoming that single source of truth for them.

So we can become that single source of truth for the assets, the data, the dependencies of their software assets all the way from source through to delivery. Organizations that use Cloudsmith reduce their infrastructure costs. They eliminate the overhead of management and maintenance that comes from having no solution or using other non cloud native solutions in the space.

They can empower the development team to focus on their core business and they can control and reduce software supply chain risk through that single source of truth.

So that's a little bit about Cloudsmith.

Cool. And then from the Anchor side I'll just talk about. Our open source. If you go to github. com slash anchor the organization, you can find sip and gripe, and we just want to build the shovels and tools that help kind of an SBOM powered supply chain universe come forward.

So that just means that taking your doctor images, taking your packages, your directories, your distros. Generating SBOMs in a format agnostic way, and then using gripe on the other side to scan it and provide you, you know, amazing and hopefully accurate vulnerability reports that can help you slowly shift left with your security posture and just, you know, your security journey as an organization

carrier. You're muted. just as a heads up.

Can you hear me now? Sorry about that. So we're going to have our first poll. We'd love to hear if your organization is actively trying to secure its software supply chain, that could be training, that could be introducing new security tooling, or trying that first stage of finding out all your dependencies.

So we'd like to hear yeah, yes, no, or not sure.

So, Alison, I don't know what you think. I know you've been talking to a lot of customers about this. Yeah, I'm

gonna take a bet and say that A is not going to be the number one answer here, but we will

see. Hmm,

that's great. I'll give it a few minutes.

It's such an emerging topic. It's like since the solar winds attack, it's really realized how, like, vulnerable people's software supply chain is, and how there's been a lack of monitoring in that area. So it's it'll be interesting to see what people say Yeah, we're

we're fortunate. We have some early adopters of software supply chain using Cloudsmith today, so we're able to see some of the Concerns and solutions that they're looking at to try to become more secure across their software supply chain.

Okay,

will we move on? I know there's not many answers there, but let's just keep going. Maybe it's because they're using those different streaming methods to watch this. But if you put your If you put a question into Twitter or LinkedIn chat, we'll be listening out for that as well. Okay, I'm going to start with explaining what the software supply chain is.

So it's basically everything that goes into building your software. It's your code, it's your dependencies, their dependencies. It's your, the tooling you use, your plugins, your package manager, your CICD tooling and your package repository. So it's everything. And a software supply chain attack kind of targets anything along that along as you're building the software.

So any point in time it can try to attack, try to get into your system to change the software. They generally do this by developer account takeover can happen, maybe, and then get into your build system and or else tricking you to downloading malicious packages or targeting vulnerabilities in your third party dependencies.

So they attack surfaces. quite fast for this. And the, the, the first time it came into prominence was the solar winds attack in late 2020. It brought a ton of attention to supply chain attacks.

So a huge part of our software supply chain is open source software. I think it's like over 80 percent of of people's software contains open source and that's because it's like it's free to use there's so much innovation when you think of kubernetes of docker of nginx linux it's like without it development will be painfully slow.

It's a positive source of good in the world, and maintainers volunteer their expertise and time, and I really appreciate them. And most people consume open source software using these public repositories, so Maven Central, or PyPy, or Crates, or NPM, NPM and DockerHub. Yeah, so that's where people get their open source software from generally.

And a massive part of securing your software to supply chain has to be securing your open source of what you're consuming and being happy that you trust us. So I don't want people to think that proprietary software is less secure. It's not less secure, but it's attackers can maximize their impact and reach by targeting vulnerabilities in the in open source.

The kind of attacks that are specific to open source are like, say, targeting critical vulnerabilities in your that are in your open source. So you might have heard of recently log4shell, which was a 10 out of 10. remote code execution vulnerability in a popular Java package called log4j. And the problem with these critical vulnerabilities is like, they're actually patched pretty quickly, usually, once they're found.

But it's the long tail, the amount of time it takes to fully upgrade and patch everybody that's using that software. And we're not just talking about direct dependencies. It might be in your software because it's a transient dependency, a dependency of a dependency. There was a study done in 2020 about a a vulnerability called Harplead in OpenSSL.

Which took place in 2014 and in 2020, that was still exploitable and attackers were still used scanning for this vulnerability because it was it was a great attack vector and That's so that even though the vulnerability was patched straight away in 2014 It was still exploitable in 2020. So another type of attack and it's kind of related or a vulnerability, let's say, or threat is abandoned open source software.

So you're, somebody creates software, pushes it up, people consume it, but for whatever reason, The maintainer doesn't update it or maintain it, they've things happen in people's lives, you know, and these vulnerabilities, these new vulnerabilities as they come along are not being patched, not being worked on, but they're still in people's code base.

So that's sort of connected to that critical vulnerability issue. There are types of attacks on public repositories where you can source your open source, like dependency confusion attacks, or typo squatting attacks, where they kind of try to trick you to installing a malicious package. So these are the types of attacks, or threats, to open source software that you've got to think about.

So since the, the solar winds attack, there's been a huge response starting with the executive order from Biden, where it's a, they wanted to improve the cyber security of your software supply chain. And in it he mandated that any software that the federal government purchases will have to have an SBOM by a certain date.

I think it's around now that they're updating contracts. I'm not, I heard it was like last year, so I heard somewhere that was like around May time, so I'm saying, I'm going to say it right now. So, and another big response is that the White House brought in all the stakeholders. for, from open source software.

So the consumers of the open source software and big tech companies, of course, the open source representatives. And they brought them in, they came up with this big 10 point plan. There was 150 million attached to it or something like that. And one of the 10 points is SBOMs everywhere. So they want to.

Promote the use of SBOMs and invest in training and tooling. So SBOMs are important. Sorry, I've been talking about SBOMs, but I haven't really explained them. So, that's, that's what I'm going to do now. Don't worry, don't worry. I'Ve got my slide up here. Okay, so Software Bill of Materials and SBOM.

It's basically a list of all the components that are in your software product. It's a great way to, if you have this list, you can use that to see if you're vulnerable to these new threats that have come out. The minimum elements to an SBOM includes your dependencies, their dependencies, the supplier name, the component name, the identifiers.

It's quite, quite a short list. And then there's optional things to add to that, like licensing information and other stuff like that. Even vulnerability information, which is a bit People aren't sure if you should attach funnable loose to your SBOM, but anyway. So the two machine readable formats for SBOMs are SBDX and CycloneDX.

And they're both great. SBDX is an ISO standard. CycloneDX came from OWASP from a dependency track project. I don't know, Chris, if you have an opinion on which is better. buT they're both pretty good.

Yeah, from our side, we just want to be format agnostic. Like when it comes to generating lists of packages, whether it be SPDX, CycleMDX, or even like a more kind of data rich JSON format that has all the metadata possible, you just want to provide the most source of truth with regards to packages and to images and to the software being consumed.

So we'll let the format wars, you know, happen on the mailing lists and the forums

where they belong. I don't know. People seem to be, most of the tooling seems to be trying to generate both. That seems to be, which is great. Because I think SBDX is more licensing stuff and CycloneDX is more vulnerability stuff, but I don't, like, that's, that's sort of very high level, I'm not really too sure.

They're both good, don't worry. So, SBOMs at their core answer the question, What is in my software?

So, another poll. We've got some of the answers there to the previous poll. So, a lot of people say that securing your software is critical to your software. So, that's, that's great to have. And hardly anybody says not important or I haven't heard of SBOMs before today. There was one person that said they haven't heard of SBOMs, so.

So much learning. And okay. So the next poll, the new poll is for my organization. SBOMs are critical and nice to have, not important, or I haven't heard of SBOMs before today. Oh, sorry. That was, that was this one. Yeah, I know. So

for the previous one, we had 30 answers and 87 percent say that securing their software supply chain is important and that they're actively trying to do that today.

Oh, thank you all. Maybe for the next part I'll let you answer because I'm not very good at multitasking. Yeah,

I know. Yeah, we already have some folks coming in on this one too. Yeah. Half of the people who've answered say that SBOMs are critical for the organization. So that's really great to

hear. Yeah, that's great to hear because sometimes it's where it feels like very early in the process.

And you're not sure if you're like you're working on the right feature, but it feels right. So I feel like it's going to be everywhere soon. So I'll move on. People can still answer that when I move on to the next slide. Right. Okay.

Okay. Now let's talk about tooling to support your SBOM. So the tooling will need to generate your SBOM, host your SBOM and analyze it. So Cloudsmith can help, SIGstore, and of course, Anchor's open source tooling, GRIPE and SIFT. So I'm going to let Chris talk about GRIPE and SIFT later on, and I'll just talk about a little bit about.

hosting.

So SIGstore is an open SSF project, which really tried to promote the use of like signing packages, especially for open source packages to make that process easier to sign things, to verify them and just to use them. So signing in the past is like, it, it can be difficult for people to, especially the key management part of it.

To do that in a secure way can be difficult. I'm going to go through a demo later on today, showing cosine six door because Kitesmith recently integrated with that tooling. And David has worked on this. So to to attach SBOM to your container image, and you can also attach attestations and that's where your SBOM goes.

So I will move on. I am going to pass this over now to Chris. There you

go. Cool. Hi, everyone. So again, my name is Chris Phillips and we provide some of the I guess, base level tools in an open source way to help secure your supply chain. So, I'm going to post the two in chat right now. Those are the GitHub links to SIFT.

And to gripe and we can kind of move forward and show you what both of these are. So the first one is we talked about making SBOMs actionable, but for you to actually have an actionable SBOM you need to have one. So that's where SIFT comes in. We can generate SBOMs from multiple sources, whether they be, you know, OCI image formats, the Docker image format itself, file system archives, you name it, we can do it.

And like I said before, we're format agnostic, so it doesn't really matter. to us if you want Cyclone DX, or if you want SPDX. We also offer our own format, which we can kind of show off but that can be converted back and forth to be more standard and kind of out there formats that people are consuming day to day.

We also do Linux distribution identification and then through our tools, you can create the SciDesk format of stations. That everybody's been kind of talking about as far as how do I actually trust this document now that I have it. On the other side of things, we have GRIPE. And GRIPE is the, you know, title of this talk.

Making your SBOM actually actionable. We can take that huge, large JSON document or SPDX we can generate a list of vulnerabilities. For your container for your file system again detecting most if not all major operating system packages If you see one that we don't have patches welcome pr is welcome.

We want as much people contributing to this as possible but this is kind of how we get the ball rolling. So to kind of show that off i'm going to share my screen Let's do this real fast and I want to share This screen right here. All right. Everybody see my screen? Thumbs up. Yes. Verification.

We're good. Okay. So one of the best parts about SIFT is that we can install it super easily. If you just go to the top of our SIFT repo, you can see a quick curl command. We also offer it through brew, but we know system administrators, people who are writing, you know, scripts and want to get into the tooling curl is out there.

You can download it. And then if I just do which SIFT from that. Great. I have SIFT installed. Let's see what it looks like to actually generate in this box. So if I do time and I do SIFT node latest, what we're going to do is we're going to take the base image for node latest that's up on Docker and we're going to request it.

We're going to parse all of the packages on there. We're going to build out the file system. We're going to go through and dig into all the node modules, licenses that are available, every single piece of metadata that you could think. That could possibly exist about a package on node colon latest. We want to find it, whether it be through NPM, whether it be through its actual distro that gets based, that gets built from if they're not building from distro lists yet.

If it exists within there, we want to find it and we want to show as much truth as possible about that image. So here we go. We're cataloging the packages. We have zero right now. And hopefully, at the end of the day, we're going to see, boom! This is the list of packages. And now you can see, 42. 18 seconds.

So, if you think about all of the time it takes day to day to analyze, to build out the entire picture of an image, that is a ton of compute time. What if you already had that generated? as a CyclinDX, a JSON output, or an SPDX output that actually represents your entire package. And to show you why this is important and why SBOMs are kind of the future to make an action on this I'm going to do a quick demo.

So I'm going to do the same thing. I'm going to generate that list of packages and I'm going to scan it for vulnerabilities. So if I do time, and I do g r y p e, and I do node latest, this is going to do exactly what we just did, but except it's going to Spit out all of the vulnerabilities that are associated with that SBOM.

So we're going to do that and we're going to let it sit and then I'm going to do on this side. I'm going to do, right,

that's time, right. And instead of this, we're going to do test. json. So now I'm going to use the JSON that we outputted, which is the SBOM itself. And we're going to scan that instead of parsing this image each time we want to do the vulnerability scan. So let's just see how this looks. Insert Jeopardy, do, do, do.

We're still parsing over here. 17 seconds to actually do the vulnerability scan against node latest. But if we generate this SBOM, again, still waiting, still parsing, catalog 614 packages, processed 1000 vulnerabilities against it, and still waiting for the output, probably some, there we go. Oh, 54 seconds.

So almost three to four times the compute time it would take to generate and rescan the image. We want SBOMs to become this kind of base, like truth. Of what represent what's representative within software within packages within docker images within any kind of directory And we can hopefully take that base truth of what assembles it and use it as our new like modicum of data for processes Like vulnerability scanning or auditing or license auditing, etc and hopefully you can see now like if you're spending so much time in your cloud provider to do this process here on the left over and over and over again you can save almost, you know Three times to four times X the time to just moving to SBOMs to actually scan and do your analysis from there So with that I'm going to stop sharing my screen I guess one of the admins can bring back up the materials and we can move forward With how we can take these building blocks and put them onto a cool platform like Cloud Smith Oh, I think I can

do this.

Oh my God. It worked. Ah, yeah. Wasn't so bad. That was great. And I can confirm using SIFT and GRIPE was really crazy easy. The only thing I didn't like doing, or nothing to do with SIFT and GRIPE was like that, you know, the attestation using jQuery to get the S1 back out. I don't like that.

Neither does the rest of the entire ecosystem right now.

We're trying to find better ways to store those attestations.

I promise. Oh, okay. Oh no, you, no, you didn't go. SIFT and GRIPE. Yeah, great. So, so now I'm going to show you a demo on how to make SBOMs actionable with the SIFT and GUI tooling, as well as Cloudsmith and Sixth Door. I'm also going to be using the Cloudsmith CLI.

So I will share my screen. Okay. I'm going to put this over here. So I'm going to be using the command line, but you can see all this in I've a workflow in GitHub actions, if you'd like to see this. In real life. So if you want to try it out yourself. Okay, I'm going to share my screen. Yes, I want to share.

Okay.

Okay. So I've actually already

pushed an image to a CloudSpot repository. So you can see this one here. It's an image I prepared earlier, just to save a little bit of time, like a minute. I just couldn't handle it, the silence. And just to show you CloudSpot repositories, you can actually host all the different types of formats.

Let's see how many, 28 different types of formats all in the same repository. So these are multi format repositories. Just to let you know. And, okay, so now I'm going to start this. That image, that image there is,

I'm just going to push it again. It's the same image, but just to show you the process.

Okay, great. And now I'm going to use cosine tooling to sign the image. So I'm going to generate a new key.

Lovely. Okay. And we can verify this using... I didn't generate a new key there. Okay, sorry. I'm going to generate a key. Yeah, I removed those keys.

Yes.

Okay, I've overwritten my whole key and I've got to re sign it. I'm sure this will be fine.

So now it's going to push the signature to Cloudsmith.

Oh, and that's because I've re signed it. There's two signatures, but don't worry about that. That's my, my issue. So now I am going to create, I'm going to verify that signature. So using my Public key,

and it should say Kira Carey signs this image.

Now I'm going to generate my SBOM.

Okay, so you can see I'm using SIFT tooling here. I'm generating the SBOM for my image there, and I want it to be outputted in SBDX format, and then that's going to be outputted to this file here.

It's going to find all the dependencies in my image, and then when that's finished, I'm going to add this to, I'm going to use cosine to add this SBAM as an attestation to my image, and then it'll push it up there. And I can store my SBAM alongside my image, which is great.

So this is the code for the attestation part of it, I'll just put in my password.

So it's co-sign test, say the type and then the store. The S bum in the predicate. Use your key, your cosign key here, and you just tell it what image you're talking about. So the benefit of using an attestation to attach the S bum to what it means that you can prove that this person. Attach this SBOM, and this is becoming more important to prove the provenance of your software, these attestation statements, and they're in toto.

So let's go back to the repository, and you can see this attestation attached to our container image. So you can see it there, yeah. And then because we've we've assigned attestation, we can verify it using our public key. So I'm gonna verify it, and then just. Send the output to file same kind of it's similar cosine verify to the verify signature except for it's cosine verify attestation.

You still use your public key and you point it to the image and you tell it what type of attestation it is. Okay, so now we have our attestation. What we want to do is we want to. We want to if we're going to be continuously analyzing this, like, so you have your image up. on Cloudsmith and you're, it's deployed or whatever.

And you want to monitor this like using some continuous security. Maybe you're monitoring it nightly. You're checking every night if there are new vulnerabilities attached to this. And then you can make decisions based on that. You could say if it's above a certain level of vulnerability that I am going to stop this image being deployed.

Okay, so I'm extracting my SBOM back out from the image that's stored in Cloudsmith. And I've stored it in this, in this SBOM format here. SBOM file. So now that I have my SBOM, I'm going to say what I was talking about just a minute ago. I'm going to use GRIPE the AgCorp, and so it's tooling to find out if there's any critical bugs critical vulnerabilities.

So, and if there's any critical vulnerabilities, I'm going to fail this. And you can use this in a workflow and The one that I posted up in the chat that, that that has a nightly workflow that will fail on a critical vulnerability.

Great. And luckily I have a vulnerability, so we can test this out. And now I'm going to use the Cloudsmith CLI to just get the identity of that image. And then I'm going to use a new new feature called quarantining. David was involved in working on as well as SBOMs. So, and this will quarantine the image.

You won't be able to download it or deploy it to infrastructure. And you can see how this can be used in a workflow to just stop a vulnerable image being deployed. Okay, so before I show you... I'll show you that it's not quarantined and then what it looks like when it is quarantined. So we have our image here and we have, we can use this quarantine function from the UI as well.

So this is basically using the CLI to quarantine it.

And now, yeah. So here this this little icon here lets you know that this is now quarantined and that you can't download it or deploy it. So using the API this won't work either. So, yeah. That's our demo and I'll just kind of walk you through the workflows on GitHub. And I've actually worked this from Dan Lurien's code, formerly from Anchor.

And there's two workflows. One workflow, anytime there's a change to the code, it will build the image sign it using co sign generate an SBOM, attach that as an attestation. It actually also uses GRIPE to attach and attaches that vulnerability. Report as an attestation and how that could be useful is that you can say when this image was built There was no vulnerabilities of a certain level that might be useful to some organizations So we have that there, and then we also, now that we have our image along, that's stored alongside the SBOM, we have a nightly workflow that will check that SBOM for new vulnerabilities and quarantine them if they're above a certain level.

So I'll let you peruse that yourself I will stop sharing. Okay, great. I'll bring back those slides. And yes, so one more poll, why not for your, so this one is, do you think that SBOMs help secure your supply chain? So, hopefully this isn't too shocking. We've demonstrated that they're useful. You know. And based on the responses

to the other polls, it seems like we should...

Yeah, we're with our people.

Great, so and we'll talk about that later on. We'll just have our little far side chat now. So, I'm now going to talk to the gang. Alison, David, Christopher, if you want to unmute. I just want to ask you guys about SBOMs and supply chain security. So I'll start with Alison. Why are SBOMs important to Cloudsmith?

Yeah, so we

talked a little bit at the start about the mission and vision of Cloudsmith, and we really think that as a package management solution, we can add a lot of value for our customers by becoming that single source of truth for all data associated with the with your software supply chain. So not just the artifacts, but the dependencies and the data that go along with them.

And we see SBOMs as one of those critical pieces. And it makes sense to be able to store that alongside the packages and the, and the artifacts from your software supply chain. So for us, it was really important to introduce support to be able to host those SBOMs and. When we were thinking about what our first pass at the feature could look like, it was really important for us to understand where the community was headed.

And so there was a lot of development leveraging Cosign and, and leveraging SBOM specifically around OCI artifacts. So that was that was where we picked for our starting point for being able to host SBOMs.

Yeah, that seems like the nicest. I know it's an emerging field, but that's of the emerging stuff.

That seems like the nicest workflow working with the container image. You can do the whole workflow. It's still a bit up in the air about how you should, what's the best practice to host? Just packages, non container images. So, but David on from that, I know when we were first thinking about Aspums, I think we were thinking about.

generating, are the SBOMs ourselves. Can you work us through why we didn't do that and why we might have thought about it?

Yeah, the idea was on the table at first but diving into the implementation and, and how it's currently being used it became clear that that's not where, where Kiosmos is going to be able to, to provide its value, right?

Like I, I think it's, it became clear in looking how, how SBOMs get created that the way to go is to integrate the build or the SBOM generation into your build process. Like Chris was showing off. It even scanning a Docker image takes quite a while. Right. And we want to do that once and then use cosine to.

Attach that cryptographically verified information to the image. And then, based on that, we can

we

can make the, the other later scans much faster. And, and that's where Cloudsmith can help in hosting that SBOM next to your packages or your Docker images. And we can leave the gnarly bits to other

people.

Yeah, and I have a question here. How are the attestations stored? I think they're are there metadata on the docket image itself? I believe it's stored in it in a blob layer, but maybe you guys want to talk about this. I'll leave it to Christopher and David to answer that.

I, I wrote the integration, so I, I can easily take that if you, if you

want.

It's a nice softball one for you there

then. Yeah, yeah.

Actually, inside the OCI registry, it looks like another docker image. There are subtle differences between what a docker image and an OCI image is. But that's probably just for people like myself who are working on implementation. But in the end, it's just another docker image that just has a file instead of a file system inside it.

Right. And... In Cloudsmith, as you showed, Kira we're, we're just showing that it exists and you can kick into and look at the details. But really I, I think the, the co science UI workflow either for, for you as a user or then in, in CI when you're. Building the image or in your cluster when you're deploying it and checking those at the stations.

I think that's that's much more Much smoother than Than anything else that we could provide from the hosting

side.

Yeah. Oh and Christopher. There's a question here about just Does it list the third party dependencies? This is always a tricky one I'm sure sometimes it does and sometimes it doesn't.

I'm not, I'm actually not sure. So you, you can tell me.

Yeah, we try our best when it comes to just grabbing as much metadata as possible about things that are unpublished or kind of proprietary internal software that you're scanning. If it's more one of the ecosystems that we say we support, obviously we'll go, if you have some kind of code that you're installing, whether it's through the RPMDB or you have like a custom go binary installed in your package.

We'll detect that, we'll find that static binary for the, for the go side. We'll break it down and use the debug. buildinfo to find as much information that got installed into it via the compiler. For other more sophisticated ecosystems, static analysis, we're still working on, but for Java, for Python, for NPM, for even for Rust, we have some new support that's gone in for that.

So To say, to answer your question, yeah, there's some nuance where we're not doing the detection. We're getting better every day, but for the ecosystems that we say we support on the README, thumbs up. You should get your proprietary internal code also detected in packages

listed there. Cool. And I, I, I saw that like, there's going to be Docker have done something with buildkit to let you generate it at build time is what will that add to the SCRUM generated?

Yeah, what we're

like, what we really want is a world where again, if you think of like the attestation being included kind of as a sibling to the Docker image, you want that also from the build kit from the get go from the base image and SBOM to just be provided so that we say, Hey, I built this image and you don't have to do the analysis, right?

You can just trust that we at Anchor put our SBOM along with this build kit, and then you can just rip that out of the image when you pull it down. Now, obviously just like with everything in trust and software, if we mess up a couple of times ago, Oh, I don't trust those like anchor guys or those Google guys anymore.

I'm going to make sure that, you know, what they say in their SBOM is the same thing as the image analyzed. And then you can kind of get. Really sophisticated dips of if people are actually saying, you know, our bill of materials is what is in our software so you can go back to them like to a vendor and say, Hey, within the within your image, you included this as long as part of the build kit initiative, but we actually analyzed the image and we found XXXYZ.

That's not part of that. And so that kind of transparency and openness going forward just helps, you know, hopefully software move into a more secure place where you say, Hey, you might have had a supply chain attack. Because you say your SBOM is this, but the image that you distributed to us had two more packages that doesn't jive with that manifest you

provided.

Oh, cool. So it's nearly like you could nearly audit the SBOM using. Yeah, that's cool. And I just want to is there a. Security professionals have to deal with a lot of vulnerabilities and sometimes it's hard to prioritize that. Is there a way to help with that process? I'm kind of, this is a leading question, I'm basically talking about DeX.

Yeah, we want we definitely have, we've offered DeX support on the Cyclone DX side as kind of like an integrated part where vendors bring kind of a VEX document with their SBOM, you can plug those together. And for people who are on the call and they're not like super familiar with VEX the metaphor I like to use is that if an SBOM turns all the light switches on and builds that huge dashboard of all the things you kind of have to care about, compiled with a vulnerability report, VEX takes that and uses all the context of No, that one doesn't matter.

We're in a private security group. No, that one doesn't matter. No network attack vectors work to that. No, that one doesn't matter. Like, we have our own custom, like, built image inside. That's that package that we've signed off on and no, it's not vulnerable. Like, you can make a security officer or a security analyst's life easier by just turning off a bunch of those warning lights with effects.

So, hopefully we can reduce the surface area that humans have to actually integrate

with. Yeah, it's because humans, it's hard to get a, it's security professionals, those, those are, that's tough. Our job,

our job would be impossible if we couldn't automate some of the things we automate now. It's a, it's a, it's an object impossible

task, basically.

Yeah, and so I'll end with one question, just wondering where do you think the issues lie with SBOMs and yeah, and where do you think the future of SBOM is? So it's a big question.

I think, I think the biggest. Issue right now is kind of what we're discussing on this call, which is like making SBOMs actionable It's like already people are being told.

Hey, you need SBOMs. Hey, you need this thing You you have to include this with your buildpack But people just don't know like what the next step forward is And then the community just like with all open source is throwing a bunch of stuff on top of it They say hey, you need to attest your SBOMs.

Hey, you need to sign them. Hey, you need to store them here Hey, you need to keep like if you keep stacking the jenga blocks taller and taller It gets to the point where, you know, security analysts and researchers are going to go, ah, I've been fine forever. I'll just, and they throw their hands up and walk away.

So the, the, the problem is, is mostly like a messaging thing, but as soon as you like wrap your head around the idea that your organization is paying for compute time for analyzing these things every single day, there is a format that just simplifies everything. And if we get that to be the most accurate source of data and of truth, and we can, you know, compare that back to an analysis of a recent image.

You have this kind of square one to build from and go forward. And once the community like zips on that, then there's going to be no more of these working group fights of like, well, why do we need this? What format's the best? Why do we include VEX or not include VEX? Like there's just all this churn because it's such a new technology.

So absolutely it's emerging. I suppose it's only when people start using it and poking holes in it, that we'll the most, the best practice workflow. So oh, I just saw your cat in the background.

She made it up. That is a chihuahua. Oh, sorry. Majestic animal. Small and

afraid of it. Okay, so that was really great.

I, I, we actually answered a lot of the questions on the fireside chat. Oh, we have one more here. Appreciate if you guys can address the below queries. Developers can pull pre complied binaries or raw code into their codebases. In that case, how can we ensure S bond records all requires dependencies?

So I suppose this is about building stuff without a package manager really, isn't it? And how can you, I suppose it is more difficult to detect that. But what do you guys think of it?

I mean, I can answer from the Anchor side where. Like what we want to do is we want to provide integrations where if we don't have the kind of cataloging support for that, users can kind of bring things that they say, Hey, we see that like, you know, you can't discover this like pre compiled binary for whatever reason, right?

This just doesn't exist or a good example is, let's say in the go tooling for debug that build, they don't have a way to inject what the major like BCS tag is for that module because there's no standard. Everyone is just injecting it in different variables, different ways. So if we can provide interfaces for users to bring in like hits or bring in like addendums to SBOMs so they can like build them out themselves.

Then for those small edge cases, you can then kind of build out where the gaps are within that docket. That would be like kind of one bridge going forward while we work on the detection side of getting, making sure every single little thing is covered within the software ecosystem. Yeah.

And I, I'm sure there are some things that, that will always be easier to just.

Provide instead of detect, right? i've seen for example, gradle from from the java ecosystem around maven has has already a SBOM generator that you can build directly into your build process of your entire java project And that has much, much richer information available that, that you would ever get from from scanning afterwards because it can add information like where does, where was it downloaded from?

Were there any additional attestations from there? And, and so I think as we see SBOM usage mature in the community, we'll, we'll also continue to see workflows where SBOMs from various sources get integrated into, into one bigger output. And, and I'm, I'm sure Angkor will, will happily also. Integrate that information that wants it's available, right?

Yeah, that's like, that's kind of the path forward because we're really, really happy with where we are on the job detection side of being able to not just like decode your base package, but also jars within jars within jars. So that, like, just to use the. The non du jour of the security, like world cycle, sorry, log4j, if you had it deep nested within like five or six jars, we can rip out that metadata information and the more that the more context we get from the Maven ecosystem and from their build tools, the richer that information that we rip out is going to be in the future.

So the more tooling that we can integrate with the better

brilliant. And so the second part of that question, our second question is how can we achieve SBOM generation? With every new release of components, like, so I suppose, is this like, it's going to be because there's so many releases or anyway over to you.

I would just, I suppose you use like the CI CD workflows is, is how I would suggest, but maybe there's more to that question that I'm not understanding. Yeah,

I, I would have also read it like going back to your demo like the commands you showed in, in, in the shell, but wrap it up in, in your build process.

And as you upload the image or as you build the image create the SBOM for the image using for example, SIFT and then upload it to a repository like Cloudsmith where you can have them hosted together and, and available. For anyone consuming it and if you are not building your artifacts in, in in a shielded CI.

System, then a lot of the guarantees that an SBOM can give you go out the window anyways, because if, if I'm building something on my local dev workstation that has been exploited, all bets are off, right? So I,

yeah. So, and, oh, and somebody posted the Cyclone DX Maven plug. Oh, that was to help answer the previous question.

So great. So, I think, I think we might end there. So I hope we need to Oh, sorry! I was about to not answer the prize!

It's for everybody's still here.

No yeah, so the, so Hillary let me know that the four folks who are gonna get a Cloudsmith prize pack are Mike Garvin, Sean Drexler, Eleanor Shalnutt and Alex Rybik. So you need to Hillary will be reaching out to you four with information about how you can collect your prizes.

So thank you so much for staying till the end.

Yeah, thanks everybody especially Christopher for being our special guest star. And I hope people have learned more about SBOMs and how they can help you secure your supply chain. So that's it. That's all. Bye bye. Cheers.