Welcome, I'm Ciara Carey, and this is Cloudsmith's webinar, and all things supply chain security and artifact management. Cloudsmith is the only cloud native universal artifact management platform for securely developing and distributing your software. So today's topic is on how to securely consume open source, and we'll be joined today by Adrian Moat from Chainguard.

And we also, we want to hear your questions. So please post them in your channels, no matter where you're listening. And I'll try to get through them. I'm, I'm terrible at multitasking, but I'll, I'll make a really good effort. So when we talk

open sources, it's like 85 percent of your code contains open source. So your software supply chain includes all your steps involved in deploying your code to production, your closed source software, your in house software, your dependencies, which are likely to be open source, where you host and consume your open source from, those public repositories.[00:01:00]

And where it gets deployed to production, some machines, some cloud somewhere. And there's plenty of risks in your supply chain. The attack surface is quite large. And so we should be worried about supply chain attacks, and because they've grown exponentially over the last few years. These software supply chain attacks can target Any of the steps involved in your software supply chain, you can have compromised repositories where people are sourcing their open source packages from, you can have compromised dependencies of those packages, you can have malicious packages or typosquatted packages, and it can also be compromised how the packages are built or distributed.

And there's also, over the last few years, there's been an increased regulatory scrutiny emerging on organizations, they, they have to prove they know what's in their software supply chain. It all started kind of with that White House executive order. [00:02:00] Like, whenever we talk about supply chain, we always talk about this White House executive order.

But also the EU's Cyber Resilience Act and previously the NIS2 directive, the UK's NIS regulations. So all of these require customers organizations have a better understanding of what their, what is in their software supply chain, the ingredients of your software supply chain. So how do organizations reduce their risk in their open source and secure their open source, securely consume open source?

Well, I suppose it's a, it's a big problem. You need people, you need a culture, you need policies, you need processes. And today we're going to talk about some of them. So let's bring Adrian on stage. Hey Adrian, how are you?

Hi there. I'm very good. Thank you for inviting me.

Yeah, delighted to have you. I actually met Adrian last week at KubeCon, which was on, like, had a great time there.

How did you get on?

Yeah, it was great. It's a great conference. I think it was 12, 000 people or so. So it was yeah, that's

insane. Yeah. [00:03:00] Yeah. And you had a talk. You were like on the, the massive stage, the keynote stage. I, I would have been Pretty terrified, but you were cool and calm.

I wasn't meant to be on the keynote stage.

I've just, I got moved room at the last minute. So that was, I wasn't

expecting. I wonder if they do that because like people were adding you to their schedules. They're like, we've got to get this guy on. Yeah. Okay. They knew the

room was going to be oversubscribed.

Oh, it wasn't like a mistake then. You were like, you were meant to be there.

So Adrian is a developer relations in Chainguard Chainguard is a company involved in securing the supply chain.

Do you want to Do you want to talk about that?

Sure. So Chainguard images are basically secure, minimal container images. Yeah, the main thing is they have much less known CVEs. So if we go and talk about, you know, scanning software, like I think you use Trivy inside Cloudsmith, but there's also stuff like Snyk and Grype and so on.

And if you [00:04:00] run that on your average container image, it tends to have. Quite a lot of results. And basically we just create a container images that aim to have zero results. They don't, we're not always perfect, but a lot of our images, if you scan them at a minute, you'll find this, there's zero known vulnerabilities.

Whereas other similar images may have considerably more.

Yeah. And and originally you had another product, but Chainguard images really became the focus of a chain

guard. Yeah, that's right. So, I mean, we always had Chainguard images to be fair. It possibly took us a little. bit longer to get that product to market because we had to first create an operating system called Wolfie.

Easy peasy. Yeah. Well, as you can see operating system Linux distribution called Wolfie. And we needed to do that for several reasons, but it was, it was kind of essential for us to be able to create our own minimal images and also to issue security advisories. So what you'll find is one of the reasons that we're able to have zero CVEs according to the scanners [00:05:00] is that say there's a A vulnerability that's a false positive you know, it's something that doesn't actually affect our images.

We can issue an advisory that basically says, hey, this is a false positive. The scanners picked it up and they don't flag on it in our images anymore.

And why would you consider that to be a false positive? Is it because it doesn't touch that bit of code or you're configured so that you

But yeah, so there's multiple reasons.

Because we supply the container image and it can be used in different ways, we're probably unlikely to say, you know, that bit of code is present, but it can't be reached. It's still kind of present, I guess. But if that bit of code isn't present, but it may be present in other versions of the software, then, yeah.

We could, for example, say that I think possibly the most common reason is, Oh, I shouldn't say that. It's a bunch of different reasons. But one of the more common reasons is say you have an upstream project. That's a, for example, a gold project, and there's [00:06:00] a vulnerability in it, but it's not in the code for the project itself.

It's actually in one of the projects dependencies. Well, that upstream project might not issue a new release. for that vulnerability because it's not in their code. So, you know, there's no new feature to release, for example, and they probably would have if it was significant enough, but for a lower vulnerability, the lower class of vulnerability, they may not.

So what we would do is we would actually upgrade that you know, the go mod file and and change the dependency and I will build and release a new version ourselves. And that's another case where we'd issue a security advisory, basically saying, Hey, we have bumped this so that vulnerability is no longer present.

Oh, cool.

And so you also include a lot of like provenance data into your images is that's a big part of your offering. What kind of stuff is that?

That's a good question. So, I mean, that comes back to where we started. I'm not sure I actually properly answered your first question. So [00:07:00] yeah, we did have another product, which was Enforce, but all our, and that was to do with like insurance security policies were met.

So it was very what's the word? It worked well with our images, but in the end, we felt that we want to focus on one product at the minute. So we're focused entirely on container images currently. Sorry, what was the question again? I skipped that.

It's about provenance, provenance, provenance.

And I suppose that's why you linked it to, Your policy manager. Exactly.

So like the policy manager could say, Hey, I only want to run images that I know where they came from that are signed by the person that created them, for example. And so all our images they have, they're all signed using the SIGstore project and you can verify the signatures using tools like Cosign.

And basically what that will prove is that the image you're looking at was the same image that we built. So nobody's tampered with it or changed things in it, for example. Either like, you know, in the registry or when it was transported.

Has the [00:08:00] industry coalesced around Cosign? Because I, I hear stuff about notary as well.

And sometimes we're, we're always wondering what horse to back in Cloudsmith. We do support Cosign, but we're like, Oh, should we also do notary? Should we do this? It's, it's Is it still in flux?

You're asking all the difficult questions. I'm sorry, I had to start. No, no, you're okay. It's, so I'm a docker captain and notary is largely used by.

Docker. Well, it was used for Docker. They now moved to OpenPubKey. So it gets even more complex. Yeah. Oh, we need another. There is Microsoft and AWS, I believe are using notary. Honestly, like, Chainguard are very involved in SIGstore. So I'm a bit biased on that, that count. And I would I'm I would definitely be looking at SIGstore first.

One of the things I like most is that the keyless signing, which I think is also possible with OpenPubKey and a slightly different mechanism. Okay. But keyless signing is really nice. So basically when you sign your image, you don't [00:09:00] have to create this, you know, traditionally what you would do is create a public private key pair.

And you'd have to keep your private key. Completely secure. And if anybody, if that was ever leaked, then people could sign the images and pretend to be you. And you'd have a very, very bad day or bad months probably. So what we have in SIGstore is keyless signing and that's really nice. There are options to use traditional signing as well, but if you have keyless signing it's really nice for smaller projects.

So I can, I don't have to have this long lived private key. What will happen is when I sign my artifact, it'll ask me to log into an open ID provider like Google or so on. And it'll use that to basically bootstrap the trust, if you like. And it'll create a temporary private key based on that. And it will store the It also that the fact that this happened also gets stored in a, what's the word?

Oh, Rekor, yeah, [00:10:00] exactly. Which is a timestamp of towards the, I can't remember the technical name. Sorry, you caught me, I wasn't expecting the Sigstore. But yeah, I really like Sigstore. That's what I know most about. But, It's probably worth keeping an eye on Notary and, and OpenPubKey as well. I'm definitely not going to say they're, they're bad projects or anything.

I know Docker with a new different format who I'm, but I think Sigstore has really in the open source world, that's, what's really being embraced. It's like being used by most of the, the well known open source packages.

Honestly, what I would really like to see happen is more people verify signatures.

regardless of like where they're from and who created them. I'm not sure that happens as much as it should. Yeah, signing for

signing's sake probably, it doesn't really get you anywhere unless you have some sort of verification in your pipeline or something like

that. Precisely, there's no point in signing things if nobody checks the signature.

And that's where, you know, things like Enforce come in, but also there's, [00:11:00] you know, there's other projects like OPA, OPA, Kyverno and so on. And those can be used to check signatures. I guess I'm sure Cloudsmith, there's something there as well.

Well, yes, we we sign everything that's pushed to Cloudsmith.

Right. So people can verify in our packages at the, in our policy manager at the moment. Can't remember if we verify who has signed it, but that if it's not in our product at the moment, it's definitely on our roadmap. It's, it's the kind of thing a policy manager should

have. And on that topic, there's also other attestations you can add to images.

And one of those that's quite common is, or common for our images, is the SBOM, or software bill of materials. So all our images also come with a software bill of materials that fully describes All the software and image and the versions which I think probably touches on the points.

You're making an intro about regulation.

Yes. Yeah. And I think it is kind of honing images seem to [00:12:00] be the place where SBOMs will start off. But also you can host them on using cosine, right? So it's kind of like, that's always where to put your SBOM and how to connect it to the actual package. Your images is still a problem for other ecosystems.

So with Cosign, it's really nice. It's quite simple to upload an attestation and also there's a Cosign copy command, which takes care of copying your signatures and other attestations along with the image so you can copy it securely between registries without losing that provenance details.

Cool. And so the, the, the title of this is like how to securely consume open source.

And do you think like focusing on that ingestion? is really important for organizations where , before it gets into your supply chain, it's like it's, it's always a good time to put a lot of attention into what's coming into your supply chain.

Yeah, absolutely. So if we can take a step back, you touched on a lot [00:13:00] of this in your intro.

But, I was thinking about it prior to this, to our call, and there was a lot of different challenges like around consuming open source and ingestion. So like some open source projects become unmaintained. And unmaintained software is just going to to accumulate vulnerabilities, but also there's no one to go to.

To fix it, you can fork it, but that's a huge responsibility. Yes. And so what you end up having to do or the best solution for most people is to move to a different solution that is maintained. But then if you're talking about, you know, a large framework, that's a lot of work. So I think that's one of the biggest problems is like, how do you know if your software is maintained and is going to continue to be maintained?

And just on that, I'm sure it's an awful lot of work for Chainguard at the moment. To make sure all these vulnerabilities are fixed. Do you think in the future that Maybe AI could be used to, to help with this to like, at [00:14:00] least maybe, oh, there's this bug was found here. Maybe we can find that same bug in a similar place or maybe something around what what version.

It's fixed in that kind of thing.

Yeah. I mean, we're kind of looking at this internally already. It's yeah. So personally I see AI as a sort of tool that you can use to help guide things, but I don't really see it being let to go off and do its own thing too much. I think it generally is always going to need to be, to be guided or to help guide people if you like.

But I think the, you know, the suggestion you had there was, well, hang on, if you find. You can identify a pattern or AI can help you identify a pattern of types of bugs and you can find it in a whole bunch of other software. So I think that's definitely a one approach to prioritize.

Anyway, what to work on?

Yeah, well, I mean, that's another topic with the NVD. Problems at the [00:15:00] minute that we're seeing.

Oh gosh, yeah, that's another pothole to So, if you haven't heard So, the whole basis of vulnerability management is kind of based on this major vulnerability database, the NVD database. And since February, the organization that hosts it hasn't been You can submit a CVE but there's no score associated with it.

And this score is really important when you're trying to prioritize what vulnerabilities to fix. So it's like a huge problem. And I don't think we know why they haven't fixed it yet or when it's going to be solved. Is that kind of where we are? I

think so. I think another part of the problem is that the CPE, like the, the data for matching.

Like saying, okay, this vulnerability affects this software package from this version to this version. I think that's also not getting added for whatever reason. And there have been some reports on blogs and so on. And I'm sure I read something saying they're going to come out with a statement, [00:16:00] but I don't think a statement's ever happened.

My best understanding is that it's actually not a budget problem, but some problem in their underlying Software that sounded complex,

I really didn't think it was going to be a software problem. I thought it was going to be a, like a people problem or a budget problem.

I think it's like a out of date database or something like that.

I think there's some fundamental issues, but we'll see. We'll find out eventually, I guess.

Yeah, well, I suppose Eventually, it would be great if there was a global

database. Yeah, right. So NVD is national as in United States of America. Yeah, I think this is a,

this is a different webinar. This is a different, you

know, you're hitting on a very good point.

And we need a better solution in the future. That's going to take time and I don't know what it is.

Yeah, I mean, I'll try to, I'll try to move on. So I'm going to

We can talk about the other challenges. So that's kind of where I was [00:17:00] trying to go. So as well as like unmaintained software, one thing that happens a lot is people get stuck in old versions of software and they don't update.

And you'll see like sometimes, you know, the latest stable is one version, but like the more popular version is the version before that may not even be as maintained. And I think that's a big issue. Again, you can have the same problem. Like if it's a, if it's a large framework, it might be a lot of work to move from one version to another, but when you don't update and you don't move versions, that's when you tend to find your software gets more and more or less and less secure and more and more vulnerable.

And then it's

more and more difficult to update because you're likely to break something and then You need more downtime to deal

with it. Yeah, there's a whole lot of technical debt there. Typosquatting. You mentioned that one. That one's the typosquatting and repo jacking and attacks like that are becoming more and

repo jacking?

I don't know if I know this one. Well,

let me see if I get it right. I think [00:18:00] that's also like say a company gives up its rights to a repository and then because they no longer produce software, they no longer use that package manager, then somebody else comes along and steals that. So a bit like you know, when you can steal a domain name.

Domain? I'm not sure. Anyway, so the same sort of idea. Basically something that was once trusted, an organization or a repo is now untrustworthy and malicious. But how do you know that? And you know, similar with typosquatting, that's when you like, you know, you put you spelled the name of your package wrong and, you know, redis pi instead of pi redis or the other way around or whatever it is.

And you get something that looks right But it's actually malicious. Or it may not even be malicious at this point in time, but at some point in time the attacker pushes some code that makes it malicious and starts an attack. So that's another big one. One thing that I was thinking about recently and that's become really big [00:19:00] recently is it's like companies or projects changing license because that's a big source of problems for, for companies that are used in open source.

If the license suddenly changes, can they still use it? And so, yeah. We've seen like Terraform and Redis and Teleport recently all changed license. And some, in a lot of cases you're probably okay, but in some cases it's annoyingly vague. Like, are you a competitor to Terraform? I mean, I can't tell you.

Yeah, actually we have a policy manager. We extract all the licenses from your open source or from whatever code is pushed to Cloudsmith and you can have a policy against that. So you can say, I don't want GPL licenses or something like that in your build. But, but then you still, you need to find your new, then you have to replace your package.

So that's only the start of the problem.

Sorry, I've run away with your questions, can we

move on? So today I was like, look, over the last while I've been thinking like, what are the best [00:20:00] practices for securely consuming open source? And SLSA is a really big one that really focuses on your build, but there's another one that kind of which you can use hand in hand with SLSA called S2C2F and it's secure supply chain consumption framework.

I had to be that we actually had a webinar on it a few months ago, and we had Adrian. Diglio, we have all the webinar, and he is from Microsoft and it came from Microsoft and how they consume open source securely. And they donated this framework to OpenSSF. So I thought it was a good one to to concentrate on.

So I'm going to go through that today. There's like eight practices that organizations should use, and then there's four levels or incrementally get more and more secure. As the levels go on, so we have at level one, it really focuses that while the practices are ingestion, how you consume your open source inventory, what you're using updates so that you're.[00:21:00]

Hopefully automatically updating your vulnerabilities, at least using some dependable or something. Enforcement, how do you enforce the developers are doing, what you want them to do, auditing so that they're consuming open source from the proven ingestion method, you're scanning for vulnerabilities for malware and then eventually you get to the stage where you can rebuild on trusted infrastructure with the provenance data that can be verified.

And actually the, the highest level is like you can fix, you have the potential to fix an upstream, like actually fork it and fix it when necessary for a temporary fix, while a zero day vulnerability, maybe if this was on a critical system or something like that, this would not be, you know, day to day thing on any old project.

But cause I know forking has its you know, it's, it's not great to fork and then not bring it back to the upstream, but that was, that's the highest level for, I don't know, submarines or something. So level one, I'll just [00:22:00] talk about it cause I know we're actually running out of time. Level one is , basically, you know, where are you getting your open source from they're trying to encourage you to, to tie that down.

So you're always using package managers, which is a reproducible way to discover and to consume and update your open source. And also package managers and package formats have, have extra stuff and more and more stuff about provenance in them. Some package managers, you can actually include an SBOM.

You can include your you can sign with, with with package ecosystem specific stuff. So it's really, important to use package manager. Also, they want you to cache your, your open source somewhere like, like Cloudsmith, you can add an upstream and proxy and , cache it. They want you to scan for known vulnerabilities for licenses.

And they want you to have a good idea of your, to know your inventory of the software that you're using. So knowing what you're using is actually like a critical baseline. That [00:23:00] you, to establish where you are so you can detect and fix issues that can help you reduce that risk on your software supply chain.

And that inventory that's kind of associated with your SBOM, your, your, your software bill of materials. And the first level you could just do manual open source updates, but as the levels go on, they expect you to have automatic update capabilities in your, like, so it would automatically open a PR in your code base, something like that would dependabot.

The next level is to securely consume and have an improved mean time. What is the MTTR? What's that sound for again? Mean time to resolution or. So that's focusing on updating your vulnerabilities and fixing them and having that automatic update capability. The next level will be level three, so you have like, it's more proactive.

You [00:24:00] might have the potential to mirror your open source internally, to build it yourself , and to to create that provenance data that you can enforce and also verify. And they also expect you to. Enforce where your developers are consuming their open source from. So that's, we're talking about policy manager kind of capabilities there, but also we're talking about provenance data that you were talking about, those signatures, creating those signatures, but then also, Verifying them, the hard part, and then that level four is what I was talking about before, where you actually have the capability.

If a zero day vulnerability comes in, you have the capability to quickly fork it, fix it before the upstream. If, if the upstream is delayed and fixing it, that you would have that in house capability to, to fork. Now that is kind of on another level, I suppose, but it wouldn't be appropriate for [00:25:00] for most cases, but that's where this, this framework comes up.

And so Cloudsmith kind of nicely aligns with that because there's a lot of talk about, you know package managers, Cloudsmith supports all your package formats from your NPM to your PIP. Talking about caching your open source, and we have Upstreams where you can cache and proxy your open source.

And actually we can, we can now do that with Cloudsmith, with Chainguard. Which is kind of cool. You can, we also do, we scan everything that's pushed to Cloudsmith, including your open source. That's cached and proxied. And now we have a policy manager on top of that, so. Against your licenses, against your vulnerabilities.

Also a new thing is we have a policy manager for your deny rules. So if a log4J came in, you could say, Oh, I don't know what to do, but I'm just going to block it from anywhere in my software supply chain and might give you a little bit of time before you can update your packages. Yeah, so that's, [00:26:00] that's where we are.

The, we have your ingestion, your scanning, your are like another key thing is it provides that one place for you to, to have all your open source, to have all your closed source software in one place where it gives you that visibility to everything that's in your supply chain.

And it's like kind of that single place to for policy enforcement for scanning and to implement controls on your open source. So we have, we scan, we help you ingest, we help you scan, we enforce them with our policy manager and we also sign everything that's pushed to Cloudsmith. So then you can, you can extract that and verify it.

Yeah. So we, we do a lot of stuff to kind of help people to to align with that best practice of S2C2F to securely consume your open source. So, yeah. So does that kind of, does that, do those steps ring true to you?

Yeah, that makes a lot of sense to me. I have to say, I've not looked at that standard very much.

Oh, by the way, if there's some [00:27:00] background noise, it's raining, which you can hear quick. I

actually can't hear it. I can't hear it. It's the mic is working.

Good. What I would say is yeah. We do a lot of that internally ourselves. So like, you know, we're keeping our packages up to date. And if you're a customer, you buy our production images, we provide you for an SLA.

So we'll guarantee to fix the, you know, critical and high vulnerabilities within a given time period. I can't remember the exact period of the top of my head, but yeah, so we can help you do a lot of that work towards S2. C2F.

Yeah. When I think about Chainguard, I think it, it seems to align nicely with, with your vision.

Yeah. So I guess I should talk a little bit, but the vision, if that's okay. Please. Yeah. Yeah. So I think our tagline currently is the safe source for open source, which I, I really like because that gives you an idea of like not just what we do at the minute, but also, You know what we can do in the future or what we hope to do.

So we really want to be like part of the solution [00:28:00] alongside companies like Cloudsmith for helping companies to trust and safely use open source software. But at the minute, like, as we said already, we're hyper focused on Chainguard images, which is our low CVE. Minimal secure container images.

And yeah, we've got images for stuff like Java, Node, Python, all the sort of programming languages. And you can use those images to build your own software on top of but we also have application images. So things that Nginx and Redis, you know, databases like Postgres, MySQL that you can use out of the box and should be dropping replacements.

But our images tend to be much smaller than than Competitors images, and also much less CVEs, and that's what we really aim for. All our stuff comes with, with SBOM, so you should get a full list of all the software in the image, and those SBOMs, are created when we build our images.

That's meant to be the sweet time to build your response, isn't it? Like app build time.

Yeah. Cause you have all the information then, right? [00:29:00] A lot of SBOMs at a minute are created by sort of looking at the package manager, which works, but by the, by that point, you've already lost some of the information.

Of course. Yeah. And can I ask on do you expect developers to use Chainguard images to build? Or is it production environment ready? Who is the kind of type of person that, where is it deployed to?

Yeah, both, you're quite right. So, like, we have developer images. So, we have, like, you know, Java, Node, Python images.

And there's tutorials on how to use them on our website and so on. And, and, By default, if you download like so we have a developer tier of images that's completely free to use. And so if you download something like a python latest image, what you'll find is that's a minimal image. It's really meant for production usage.

So it won't have for instance, like a shell or package manager, but there's a latest dash dev variant. That you can use in development. And that does have things like a patch manager. Oh yeah, because

that's worse when you're working in development [00:30:00] and you don't have a shell. Like, oh, I'm going home. Yeah, it's the same

with ops.

Like, they want to be able to get variants that they can test out and investigate. Yeah.

Oh, cool. Okay. What are the nuts and bolts in , Finding all the vulnerabilities. Is it like just hard graft? Is that

So we don't do the part of finding vulnerabilities the same as as yourselves.

So like we mainly rely on scanners. So we use Grype internally quite a lot. That's the one from Anchor. It's free to use You can check that out and but Trivy is also a good solution And then there's commercial solutions like Snyk and docker scout, which

is Aqua as well. I think is another one

Yeah, there's even more.

But what I guess I should say is like some people ask us, or they don't believe us, like when we say we have Less CVEs than other people, and they think it's a trick. It's absolutely not a trick. There's like kind of a few things we do.

So the first one is our images are minimal. We follow what's sometimes called a distralist technique, where, you know, the only software in our containers is what's required to [00:31:00] run that software. So like, you know, in a Redis container, we have Redis, and Redis is dependencies and nothing else. And just by having less software, there's less software to have vulnerabilities.

So that's the first thing we do. But the other thing we do is we just keep things really aggressively up to date. Like when an upstream has a new release, we go and grab it immediately. So the median time from like an upstream project releasing something and us having an updated package. It's about four hours, and then the new container image will be the next day.

And that, again, you mentioned AI earlier, and we are trying to make use of AI to help us you know, keep up to date a little bit there. And the last thing, sometimes you still find there's one or two vulnerabilities left, and that's where security advisories and patching comes in. And we talked about that a little bit before, you know, one of the examples being if you have an upstream project and we want to bump its dependencies to, To address a vulnerability is quite a common case.

Or we might say, you know, that's a false positive and things like that.

Oh, cool. [00:32:00] And is there anything that's hard to find? If you use some of these scanners, they actually won't find like really obvious things like they won't know that node is on your images.

And why, why is that? Or is that true?

It can be true. It depends on the scanner and depends how it works. So it actually goes back to the SBOM thing. Remember I said a lot of the SBOMs are created. By looking at the package manager. So the way most scanners work is they'll create an SBOM or equivalent of an SBOM, and then they'll compare the SBOM to their databases.

So the problem is it's only going to be able to compare stuff in that SBOM. And if your SBOM is created from the package managers database, then you miss software that's been added by other methods. For example, it used to be the case like you wouldn't see vulnerabilities in Redis because the official Redis image from Docker Hub they downloaded and compiled that in the Docker file.

That's how it got in there. It didn't come from Alpine's package database. So [00:33:00] The, it was, it wasn't getting included in the SBO for the scanners. And so they wouldn't pick up vulnerabilities, for example. But all of our software is in the SBOM and therefore should be picked up by the scanners. Cool.

And do you also, I, I should say like I think in a lot of cases the scanners are now picking up binaries and Oh,

okay. How are they, I wonder how they're doing that. I suppose they're checking the file system or something. Exactly. Yeah. Yeah.

And I think with a Go binary, you can also figure out the dependencies and so on.

But, you know, it depends on the binary, how much information you can extract that way.

But OpenSSF have a software repository working group. And they go through how they're trying to up their game and their ecosystem. Yeah. So these are the public repositories where many people consume their open source from.

And so they're trying to introduce the, these SBOMs into the package manager themselves. I think like, I think Maven is ahead of the game, maybe Go. With, with actually included, which makes it [00:34:00] right. Okay. Yeah. Once you know where you can store your SBOM, obviously, Docker images, you can store them using cosine.

But wait, if you know where to store your SBOM, and it's like, besides the package itself, it makes things easier. A lot more usable. Yeah, sure. Yeah. And I've had your customers. Do they have are they using SBOMs in their pipeline to to verify what they're using or to what are they using it for?

Right? So this is a question that gets debated a lot on social media. Honestly, I don't personally see SBOMs being used that much. I think they're mainly, they're mainly in response to regulation at the minute. Yeah. I think this may be a little bit of a chicken and egg question, because until SBOMs cover everything, how useful are they?

Yeah. Vaccinations or something. Maybe. We'll see. So, and I said earlier that Cloudsmith now supports Chainguard as an upstream. So if you're using [00:35:00] Cloudsmith, set up your Docker images to point to Chainguard's endpoint and you can consume them that way, which is kind of a nice thing to have.

Bring everything into one place kind of thing. We're coming to the end of the show.. I hope we've, we've helped people understand the importance of. Securely consuming your open source. And we've introduced you to the best practices for consuming your open source securely.

Know what's in your software supply chain. When new open source is being brought in, that you're really interrogating it at that first point. And then also that you're using these S2C2F practices to to securely Consume your open source.

You're using a central place to consume everything, including your closed source, like an artifact management, like Cloudsmith. You're caching and you're proxying them from public repositories to protect yourself from certain types of attacks and from reliability issues that you're scanning and that you're applying [00:36:00] controls and you're.

Creating provenance and then also verifying it. So it's, it's a journey and you can make it easier with, by consuming these low vulnerability images from Chainguard and by using an artifact management system like Cloudsmith. I encourage you to explore Cloudsmith and Chainguard to enhance the security of how you consume open source in your organization.

So thanks, Adrian. It was lovely to, thanks so much for coming on the show and it was great to meet you last

week. Yeah, fantastic. Me, thanks for having me.

Yeah, no problem. And our next webinar is going to be with the financial times and we're going to go through how they responded to the circle CI breach of by moving away from those long live tokens that were that were breached in the circle CI issue.

And And that moving to open ID. Oh gosh. Open ID. What is it called? OPD ID. That's what I

meant to say earlier. I just said open ID actually.

Yeah, I was correcting you. So yeah. [00:37:00] Tune in for the next webinar. And again, thank you so much, Adrian. No, you're very welcome. Bye.