 Thanks so much, Candice, for the warm welcome. Hello, everyone. Good afternoon, good morning, good evening, wherever you are in the world. I'm Adilagari, a solution architect manager over here at CloudSmith, and I'm joined by some lovely folks and welcome to our webinar entitled. So we know we have to secure the software supply chain, but where do we start? Now, this is very much a carry forward from our last webinar we did in partnership with the Linux Foundation, which was everything you wanted to know about securing the software supply chain, but didn't know where to ask. That was from March 10th, and it's available, of course, on the Linux Foundation YouTube site, as well as the CloudSmith YouTube, of course, as well. So this is the next step, sort of we know we have to secure it. Now, how do we actually go about the practical first steps to do so? So thank you so much for joining me. I'll walk through the agenda here real quick. We'll do speaker introductions up front and let everybody know who we are and what we do. We'll talk a little bit about our organizations and what we'll do as well. Then we'll touch on a quick summary from last time, just to carry forward into that. And again, it's not homework, it's not required reading. You don't have to go back to the old one. You can if you want. We'll summarize some of those points here quickly and touch on some of what got us here and why we are actually tackling these hard issues for everyone. And in addition to that, then we talk now about what's next, right? What progress has been made in this space since our last discussion in March, the wonderful open source projects, six-door cosine, and GitSign, some of the stuff coming out of the six-door project and some of the steps that have been taken there, some of the stuff we've taken in those organizations and that we can recommend that you may want to take as an organization in this process. And then we'll also, time permitting, also touch on where there are still gaps in this process. Now, of course, it's still early days in some ways that they say for securing the software supply chain, but we've been saying that for a year or so now already. So I think I feel like taking some steps is good, but it's good to identify where there are still gaps and where there's room for growth as well. And then if, time permitting, of course, we'll have a Q&A at the end as well. So please feel free to drop questions in the Q&A section if you want to. Again, we're happy to take on anything that you guys think of that you folks in the community would like to ask in terms of securing the software supply chain. So with that, without further ado, let's hop in. I'll talk about myself real quick first. So I'm an assisted man and I'm passionate about automation. My name's Bill Ligari. I'm active in the PowerShell and DevOps automation communities for quite a few years now. I'm a speaker and author and blah, blah, blah, blah. I don't need to add to that introduction. So let's move on to Luke over to you. Oh yeah, and thank you for having me. It's really good to be here. So evidently, Luke Hines, I work at Red Hat in the CTO office and a leader security team. And we're focused on what we term emerging technologies. So most of our work, we're very lucky we get to work upstream and create interesting new projects. Some fail and some succeed. Had a lot of failures and the odd one that's got some traction. And outside of that, one of the folks that started SIG Store, a project that's gathered for amount of momentum recently, but I also do various other things. So on a Kubernetes security response team, so I managed the Hacker One bug bounty program that we have there. There's a group of us that manage vulnerabilities in Kubernetes. More so on the technical advisory council of the OpenSSF. So I was one of the early OpenSSF folks. That's the open source security foundation. It's part of the Linux foundation. And various other things as well, confidential computing, there's a confidential computing consortium that I'm involved with on the board member there. So I keep very busy in the open source world. I'm really lucky to be in the position that I get to work on open source most of my days. So, yeah. It's a very unique space to be in, to be able to work in open source for your day job, Luke. And I will say Red Hat is one of those organizations that supported this from the beginning. So we appreciate you. Yeah, very much, yeah. Awesome, over to you, Luke. Yes, okay. It's very hard to follow, Luke, but I'll try. So my name is Lee Skillan. I'm the co-founder of CTU here at Kulatspeth, which alerted a little bit more of later on. I'm incredibly passionate about security, the open source ecosystem. And in fact, security has always been one of those things that I think has touched every point of my life as a developer. Maybe I'm lucky in that way. But anyway, I think it's influenced, I think the company that we're trying to build at Kulatspeth and certainly whenever we started out, we set out to make artifact management easy to use and hard to misuse. And the hard to misuse aspect was to make it as simple as possible, as simple as possible to configure basically pipelines and delivery without introducing security issues. So that's me. Awesome, Lee, thank you. Over to you, Dan. Thanks, Adele. So hi, everyone. Yes, I'm Dan McKinney. I'm a technical account manager at CloudSmith. You can probably see by my Twitter handle, I was formerly developer relations at CloudSmith. So I spent a lot of time talking to CloudSmith users and customers, both open source users and commercial customers. And I hear them ask a lot about how do they secure their software supply chain? It's a topic that comes up increasingly and there's barely a conversation goes by with our users and customers where we don't discuss this. So I'm here to give a bit of an insight from the user and the customer side. From the front lines, Dan. From the front lines, Adele, absolutely. And I don't want Dan to sell himself short. So he wears a lot of hats around here at CloudSmith and one of them is our resident DJ as well. Yes, that's true. I also write our documentation, I should say. I'm formerly a technical writer, so I write the CloudSmith documentation and tutorial videos as well. Generally, I try to help our users. Awesome, but we're lucky. Dan, I'll just say that the customers love Dan so much they wanted to keep him as close as possible. That's right. That's why I became a technical account manager. That's correct. Thank you, Lee. Many messages from our customers start with, hi, Dan. Yeah, they do. True story. True story. Awesome, thanks so much, everyone, for joining me. I'm lucky to have such folks that we'll be working with. Okay, so quickly, let's just touch on about CloudSmith a little bit about us and what we do. We'll spend a lot of your time here. We want to focus on a lot of the open source projects out in this space as well. So Dan, do you want to lead us off with a little bit? Yes, certainly. So I mean, Lee sort of touched on this already. I'll ask again for more input in a moment. But CloudSmith is a fully managed cloud native sort of package management as a service. So we offer universal repositories, hosted repositories for binaries and artifacts. We support 28 package formats and multi-format repositories, keep them all in one place. We have global points of presence, 410 plus. And a big part of what we do is we integrate with all the tooling that you already use. And we'll talk about this later, especially with the sort of emerging software supply chain tooling as well. So ease of use is a huge part of what we say because if you make it easy to use by default, people are more likely to use it from the get go. So ease of use is a big thing. That also extends through to the tooling and software supply chain as well. So that's what CloudSmith is, fully managed package management as a service. We're also big supporters of open source, of course. We host and we provide free hosting for open source projects. And we host some fairly big open source projects, things like RabbitMQ and Caddy, the web server as well, among others. So big supporters of open source projects and that's the kind of services that we offer them. So Lee, would you like to add in what I have field to mention? Probably the only thing I would say is that CloudSmith was designed for the get go to be a natural fit for the ecosystem. So basically we're not a platform. It's definitely an ecosystem product. It integrates well, plays well with other products, certainly for the cloud-based ecosystem and the clueless in the name. In fact, a lot of people ask us if we have on-premises solutions and the answer is no, because then we would have to change the name. But yes, and I think is what we call in terms of what we're trying to support. So it's a tool for your tool set that helps you to help manage that entire pipeline of artifact production right through to production. Awesome. Thank you both. Let's hop over and get an introduction on the Red Hat CTO office and stick store from Luke. Yeah, sure. So to tie these two together, Red Hat has really been focused on supply chain security for quite a good number of years now, much before it was called supply chain security because of obviously being a Linux distributor, having a package system, which was very a high target for attacks, with the likes of REL, as REL runs, I think most of the NASDAQ and various stock exchanges all run on REL now. And so certainly the big verticals, military, public sector, telco. So we've been used to being a target for a while and so we've always looked at build security. And so I've been taking an interest in this. I've been working on some, another project, which was moved into the CNCF, a project called Keyline, and was tasked with looking at how can we improve the provenance of what we're bringing into Red Hat, supply chain security, and is that something that could be leveraged for Red Hat customers as well, typically us being a Kubernetes shop. So I started to look at this area and I had this idea that we could really benefit from some sort of Oracle of truth, some credible store of provenance and then thinking about how would that provenance be captured and we could then leverage that internally for our own sort of improving the view of what we're ingesting upstream from open source projects. So I started to work around, I think this was kind of pretty much just as we were going into lockdown. So 2020 sort of March time and originally played around with blockchain. So I tried a few different blockchain platforms that are out there and then realized really that the whole aspect of a token, which is very susceptible to prices going up and down. It just wasn't the right platform. I mean, you could have like a private blockchain, but then it wasn't a truly decentralized platform as such. So I just couldn't really get a good fit into the blockchain. So I heard about transparency logs and how they've been leveraged for certificate transparency and so forth. So I started to work on a prototype there and that was originally RECOR. And RECOR was really around having an immutable observable transparent source of what's happening in the supply chain. So we then had that other folks started to get involved. Kind of a typical open source story from here. I built something, kind of had it, wanted to take it in a certain direction, but started to share it with other people, get some consensus from others as to is this useful. And then other people started to collaborate. So we had Dan Lawrence come on. He was at Google at the time. Bob Callaway, the other one in the original free as well. He was working in Red Hat at the time. He's at Google now. So I started to get involved. And about that time I realized really, if this was going to be widely utilized, it had to be in the public domain. It had to be vendor neutral. And it had to be like for the public good. So the open source projects would start to leverage the technology. Because the more that would leverage the technology, the better fingerprint we would have, the better scope that picture we would have, what's happening in the open source community. So I won't kind of go into the full history. I'll save it a little bit for later. There's another question that's pertinent to that. But that's really how these two connect, you know, six stores originally, something that we in fish has been of used to Red Hat. I'm not really seeing it much out of that context. And then obviously we realized that this could be something that could be much bigger and much more widely used. So I managed to speak to our CTO into signing the project over to the next foundation. And it became an LF project and now it's an open business project. Awesome. Thanks so much for that background. It really helps to frame our discussion. So as we lead into this now, I just want to touch on so quick summary from last time. And what we'll do now is I'm going to go ahead and take the slides off because I want this to very much be a fireside chat and open discussion. So let's keep us up on the screen. And we'll touch on a little bit of conversations from last time, just to recap everyone, get everyone up to speed on what we discussed in March, right? With Dan Lawrence. Of course, from Google and stick store and fame as we've talked about with with chain guard as well. So we touched on last time why, why soft securing the software supply chain was so important now. Some of the, you know, vulnerabilities that came out over time, some of the hacks, the solar wind hack, dependency, confusion attacks. And, you know, the executive order with the nation's cyber security. So talking a lot about how software bill of materials and as bomb has, has sort of risen in prominence. In terms of a way to, you know, have a first step to securing the software supply chain, having proving provenance and showing how you need to actually not only be able to show what's included inside of a container image, but also be able to prove that that is actually what's in there. And so, you know, we're going to have to sign it and test it in that process too. Then we touched on why this is such a hard problem for organizations to solve. And we can even discuss that a little bit again now, but, but I think part of this is, you know, certain organizations in the private sector, well, you know, started moving away from open source software, which we believe was the wrong move. And a lot of us in the open source community do because, you know, 90% of the stuff we develop. Probably pretty good is, is, you know, based on open source projects and really those, I mean, the argument that Dan Lawrence made last time was that, you know, it's actually a lot more of a secure development practice to use open source projects because they have been vetted. They have been developed out in the open. And, you know, the code isn't abstract or obscured away in any way so that you have that, you know, ability to see exactly what you're implementing. In addition to that, you know, obviously the disparate tooling. And I think we can all speak to this a little bit, but in the space of trying to secure a software supply chain, you know, trying to make this easy and accessible, simple and frictionless has been a challenge. Right. Because there's a lot of, there's a lot of layers to it. You know, being having a look as you talked about an immutable infrastructure to be able to verify things and to like, so changes, you know, are not like stuff is not easily changeable and then manipulatable by dev in some ways, right? You want to be able to prove things out and you want to, you don't want necessarily, you don't want, you want secure development practices, essentially, and you want them easy, right? And sometimes historically, you know, the public keys, private keys, a lot of the other stuff in that process has been a little bit, you know, every dev has something running on their machine, but it's not really easy to scale that or to maintain that or to secure that, right? So that's specifically touching on why it was a hard problem and talking about some of that. We also touched on, you know, what does secure software supply chain look like now? Some of the projects that are coming up, we talked about the salsa framework specifically, and of course the six-door project, which you're one of the co-founders of Luke. And so also from our perspective with CloudSmith, some of the stuff that we committed to with, in that space as well in terms of being able to allow users on our platform to prove providence in an open source manner as well, right? And so kind of the next logical step from that, and I'm moving the slide deck virtually in my head here is, you know, what's being done in this space now and where are we at, right? An update sort of thing. So since March, one of the things that I'm, I'm proud to say that we've done on our end is made that available for everybody. So on our platform, and as many vendors come onto this now, we are supporting those open source projects in that if you are using a tool like Cosine to sign your container images, as well as sign and test your S-bombs, we allowed you to host that alongside your OCI Docker container images. So we made a commitment to that, and that is being delivered now, right, Dan? Yeah, yeah, you know, absolutely. Thanks, Adil. Yeah, no, that is something that we have delivered. And I mean, this is a topic that comes up, and I said this at the start increasingly. And I mean, it used to be, and I'm old enough to remember without giving away my age, but it used to be that it was primarily larger enterprises in specific industries that were heavily regulated or had, you know, really strict compliance requirements. So health care, automotive, those kind of things. They were the types of users, especially in CloudSmith that I spoke to that were most concerned about, about software supply chain security. But what I'm saying now is that even smaller companies, even smaller groups, you know, 10 person startups, they're starting to ask those questions as well, which is why we brought support for Cosine, support for, as you said, being able to use in total attestations for S-bombs. We rolled that into the product, and we, you know, we talked a little bit about this beforehand, but we believe that you need to, you know, sort of democratize this stuff. So it needs to be available to the smallest users on CloudSmith right up to our enterprise users. So we don't put it into the enterprise plans. It's sort of very bad karma to sort of make those, you know, chargeable enterprise features, because it was a good, good phrase, actually, that look used beforehand. And I'm just going to blatantly steal it, which was that the tide lifts all boats. So by bringing these features to CloudSmith, but at every user, so right away from the smallest to the biggest, we started to see more adoption of them. Now, of course, we brought them because people were asking. So, you know, we're driven by what we hear in the community, and this is something that we just kept hearing over and over. I've been with CloudSmith for a few years now, and as I say, there was always this sort of discussion, and Luke mentioned that Red had been looking at this for a long time. I've heard this, but I'm just hearing it more and more and more and more. And now every time I join a call with a new user of CloudSmith that wants to get on boarded with the product, and of course that's my job to help users utilize the product, it comes up on every single call. Now it comes up on every single discussion. So that was really what drove our development roadmap in this direction was listening to the customers, and that's what the community and the customers are telling us. So, yes, it's all there in the product now. It isn't in a walled garden, it isn't fenced off, and it's following that sort of CloudSmith ethos. It's easy to use. We'll talk about this later. I'd like to mention Salsa and things like that. If you make it easy, then people will integrate it quicker. Look, we've always been able to sign packages. We've always been able to take steps like that, but it was never easy. You could sign packages with GPG keys and RSA keys and things like this for a long time, but because it was not terribly difficult, but it added some friction to your workflow, and when friction appears, people will scoot around it and take the path of least resistance. So those security principles need to be on that path of least resistance in order for people to just sort of adopt them en masse. So, yeah, absolutely. That's what's changed from March. I mean, I was on that webinar with Dan Lorenz from Chain Guard, and I said all that kind of stuff then as well, and it is nice to be able to come back now and actually stand over some of those changes that we have made since then. Talk is cheap, as you say, and development time is not. So it's great that we've been able to bring that out, and it's been well received, right from our smallest users, right up to the biggest enterprises. And also touching on the same point then, I know Lee brought this up earlier was the fact that I think recently attending open-source summit and stuff, there's a lot of pretty much every talk is talking about software supply chains, right? That was a big point. Yeah, I think there was a lot of topics that were focused. Obviously, it's very topical at the minute, software supply chain and SMVogue, and this is a great thing, right? So it's probably something that we've been familiar with for a long time, but just in terms of like global mind share of like how important it is, events like that are really about pushing the boundaries in terms of like understanding and awareness for people. However, one of the things I did notice is that the vendors were there, Clousmith was a vendor there, Red Hat was a vendor there, and a result are amazing companies that are developing within the SQL system software supply chain and things related to it. But whenever we're talking to quite a few of the attendees that are sort of asking about what they're doing, in terms of their personal lives in terms of contributor students for the ecosystem, or more importantly, what they're doing at the places that they work, I think it's still, my observation was that it was still very nascent in terms of like the actual usage out there. So I think what was the result is that not only are we not in the ecosystem doing enough in terms of like, all the amazing advances we're talking about here, like six-door transparency, attestation, adoption of S-forms, things like that, but even some of the lower-handed fruit of the check, do you have processes to make sure that the software that you've downloaded is the software that you intended to download or integrate, or what does your processes look like in terms of like ensuring that actually the dependencies that you bring in that you're building your product with, some of your critical product, it's the IP for your company that you're selling, your lifeblood is that, but how much do you think about the risk that we're adopting whenever you're adopting third-party dependencies? It's still very, very naive, I think. I think there's a lot of work to be done just in terms of building awareness. The thing is that the people realize that there's processes and realize that security is important, but it seems like the ecosystem hasn't arrived to the point where we've made it as frictionless as possible to adopt into companies. If we can even just further a little bit by this conversation in terms of awareness and show the path in terms of the tooling that can be utilized, but also just the simple things that people can do, then we've at least furthered a little bit and that's just necessary. We just have to keep on trying. I think that's probably a fantastic segue into talking to Luke here, and I'll offer it in terms of like, does he think there's additional stuff to share? I'm very interested myself to hear some of the insights. Luke, especially like in the difference, maybe this will be a topic for later in the call, but the difference between the old school way as far as we check some signature generation that would be relied upon the company's own pipeline to something where we arrive at the public transparency chain and just sort of the difference between the two of those, because it's not just about the company itself, we're talking about supply chains and the supply chain is the connect between producers out there and consumers, and sometimes the consumers are also producing software for all their parts, and it just continues so long as it's worth, so it's a much wider problem than just our private use. Yeah, yeah. So yeah, you framed that well. Now, in a lot of ways, so if we look at the former model, where somebody would have a long-term private key, typically most of the time, you might get a few fringe security geek developers that will have a private key, you know, and they will lock it onto a UB key, but they're a very small minority, okay. Then the other uses you have is your big corporates and enterprises where they can afford a HSM, which is locked in a room somewhere and you need to sign a clipboard to get the key and go in, and it's all very strict operating environment around access to that, okay. And then you've got the rest of the world, kind of the 97%, they just don't know what to do. Do you see what I mean? They're like, I could generate a private key, do I keep it on my home drive or do you know what CHmod77, I guess that will do, you know? Yeah. What happens if I lose my laptop or what happens if somebody steals, you know, what if I want to use it on different machines? Should I put it on a USB key? Then I can move it around and, you know, so just, it's a minefield for users, you know, for that majority, if you see what I mean. And a lot of this was a problem with the tooling, okay. And so for SIGSTOR this became our sort of call to vision here, okay, what we seek to replicate. So we look back to about approximately 2014, okay, and prior years, the amount of websites that were leveraging HTTPS, so secure socket layer connections was very low, it was around 30%, okay. And I believe the reason for that is because it was a real painful UX, okay. So what you had to do is let's say, for example, I deploy a WordPress site somewhere on some hosting provider, okay, and I think, right, I need to, you know, have HTTPS on fairly sort of security conscious a bit. I'm a bit of a developer, I like hacking with things. So first of all, I have to work out what open SSL commands to run, okay, you know, Google around, what do I run, okay. Then I need to get a certificate from somebody, so I need to sign up to somebody, some CA provider. They want money, so I need a credit card, okay, so that whoosh, there's a big majority of open source developers immediately gone, because some of them are still living at home, do you see what I mean, all that, you know. And then you need to go through this kind of thing, approving who you are, so I don't know, scan your passport or they'll give you a TXT record that you put on your C name or some, you know, and then they would ping you, and eventually that would all be okay. And then they'd email you a zip bundle with some certificates in and then you'd spend the rest of the day going, how the hell do I get this to working in Jinx? So you'd just be copying certificates around and restarting it, getting very impatient, CH mod 777 everything, you know, just get the thing working and then you get it working and then a year later it would expire and you go through the whole thing again, okay. So that was the kind of the experience really. And then what happened was, Let's Encrypt came along and they said, let's make it free, okay. No matter who you are, you get it for free, okay. No special preferred treatment for anybody and we'll give you a tool which will automate the whole thing for you. In fact, it'll even set it up so that at the end it'll spit out a comp file that you can just drop into in Jinx, restart your server, you're good to go, you're protected, okay. And then from 2014, for the next few years, Warsh, the graph went right up to 80 or percent, okay. Now at the same time what happened was the browsers started to kind of circle the wagons around HTTP. So they made it so that when you go to a HTTP site, it kind of feels a bit, am I going to catch something here? Do you see what I mean? I mean, if you went to a HTTP site and you said register for an account, you're like, no, you're kidding. Do you know what I mean? I'm not doing that. You just, you know, and the whole experience is danger. Do you see what I mean? So they managed to shift the paradigm. So now the kind of the, you know, its majority TLS everywhere almost, do you see what I mean? The expectation is TLS should be everywhere. No matter if you've got a small little website because you like collecting hobby toy cars or you're a big e-commerce site, it's easy to automate this and to get free certificates. So right now the software supply chain, maybe not right now, but you know going back a couple of years, it was 2014 HTTP. So package managers were putting in stuff untrusted. There's no provenance chain, container images flying around everywhere unsigned, okay. And the general predominant model was unsigned unverified, no source of provenance, no non-repudiation, all of these guarantees that you should have were not there. Okay. So the kind of the call to action for SIGSTOR was to be, and I've said this so many times, to be to software sign in what lets encrypt towards the HTTPS. Yeah. So basically try to have this free service that's available to everybody. So it could be that little 12 year old dude that builds an MPM package that's really popular to a huge fine that's generating their own stuff that they want ingested by the open source ecosystem. So the idea was that it had to be widely available to all. Okay. And then we could hopefully shift the paradigm where if you pull in untrusted software, it feels a bit icky. It feels a bit dangerous. It's socially unacceptable, essentially. Yes. And that was the kind of, that was the goal of SIGSTOR. And like I said, I mean it's working out pretty well because we got a lot of very large open source communities that are adopting SIGSTOR now and starting to leverage SIGSTOR. So, you know, but that was the good sort of focus that we had to really drive forward. Yeah. Yeah, it's an amazing background. And I think it's not, it's no coincidence whatever I'm asked about SIGSTOR, you know, by other people in the community or perhaps people are less familiar. It's the exact analogy that I utilize in terms of the way I see SIGSTOR as the comparison of that script. But it's also one of the things you said is essentially the emphasis of trying to optimize for secure by default. You know, so making that really, really easy that you don't need to think about it. Like don't make me think it ever comes to security. You should think about, but at least if you start from the principles of it's secure by default, then you're already a fantastic foundational state. Let's encrypt another analogy was that, okay, and the browser shipped as well. And this is relinked to the way we think things are going in general with ecosystem of software and software pipelines that at some point it will have to be secure by default. And if you're not doing these things, you're not going to be the outlier. You have some secured artifacts you haven't thought about province. You're not doing signatures in the test station. And you're going to be an outlier of somebody who people will not want to do business with. So we're not there yet, but that's the way that it will become. So the browser's right there. You're going to be the consumers of software. We'll expect you to show that you're paying particular attention to diligence to the process and making it secure by default for the software as well. And that would be a fantastic golden age if we're able to arrive there. And yeah, I think it's a fantastic analogy. Yeah. We will very much live or die on the UX. It has to be simple and serious. I'm a developer. And I have an incredibly short amount of patience with anything that gets in my way. You know, my wife will hear me and she'll go, what is it now? It's just like, you know, I'm kind of, you know, I'm using language that I wouldn't use on a public. And as I've got, I'm very intolerant towards disrupting me working. Do you see what I mean? So, so you're so right this Lee, this has to be seamless. The UX is really is central to this being a success in this area. Sorry to just reflect that, but we had a lot of this with SC Linux when we were trying to get that off the ground at Red Hat. Right. Cause developers just disable it. Yeah. Right. I disabled it. Someone else's problem. You see what I mean? And so there was so much put in to try and make SC Linux more user friendly like these. Did you ever see the cartoon books that came out? The ping-wing and the dog from each other's food and all sorts of tools to generate policies. And, you know, cause you do, you, if the developer, if it in any way impedes them or they feel it impedes them and there's too much of a time cost for them to adopt that technology, it's you're, you're, you're paddling up the wrong way. Really. Yeah. That whole secure by default thing is very, very, very true rings true in this space and, and making it easy, you know, and making it accessible so that people will be able to enable it by default too. So I think another couple of points to highlight in this space with what, what progress has been made. I mean, especially with six store all these projects, I think, you know, the, the ability to sign a test, different formats of packages. I think one of the big ones, of course, that would lead the space was Docker images and OCI container images in this space. That was early to this game sort of thing. And, and that's kind of what, what, you know, a lot of platforms, including ourselves are supporting. But I think that recently we should call out the fact that, you know, there's been a lot of movement in a lot of different package managers and formats. So, so NPM recently with their RFC that came out to adopt six store as, as, as a project and a standard for them, you know, rust as well. I think you, you mentioned the key line project stuff, but, but also get sign is a really important project that I've been watching closely to wait for, to get the GitHub verified badge eventually, which is, which is, which would be great to be able to have keyless signing right up your commits. That's great. So any, any of those you want to highlight, Luke, you can feel free. Yeah, I mean, one thing that comes to mind, I think what we've done right. And I don't want to appear arrogant here because I've done so much wrong in my career. Looking back, what, what has gone right. I think in a lot of ways we, we didn't wait for talking about six store and I should pivot to other technologies really, but we didn't wait for a specification. We didn't wait for, you know, we just started to build. Okay. And then discover from there. It's right. It's right. Okay. Refine, refine, refine. And that then got us in the position that we had all these tools together and these language frameworks, but when somebody came along that needed to solve the issue, we had something that they could use. Okay. And then at the same time, I mean, to, to call out other projects is a brilliant work that's been going on at Salsa, you know, around the, the kind of much needed definition of, of a kind of a roadmap to reach in an optimal, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, it's not an adequate roadmap to reach in an optimal secure bill of environment. The, you should have. And there's also many tools coming up around, generating s bombs as well, starting to do that. And I think it's, it's, it's an interesting junction at the moment because there's two years has I've been a frenzy of innovation, some incredible tall oral its built in and companies such as massaging these into a form that somebody can use, a customer can use. And the interesting thing is we're now at the juncture where, to touch upon where you said earlier, where people are asking, how do we approach this? Where do we begin? And we now have this juncture where public sectors are starting to mandate that these things should be in place. Okay, so now there's a real large, heavy weight leaning on enterprises to implement this. Okay, and I think that's where we now have to sort of go to that next level of being the educators, really, and helping them to understand how to do that. Interestingly, and at the same time, we still have a lot of work to do as well. I think in a lot of ways, I see a sort of a logical progression here. With SIGSTOR, we started to sign things. Okay, and with S-BOM, we started to generate S-BOMs. Okay, there's still a lot to do around the verification of these things. Okay, and then education around the S-BOM, as well as where should it be stored. Okay, and what is the perception around an S-BOM? Because I think one of the dangers is that a lot of enterprises are going to think it has an S-BOM that's secure, which is not the case at all. Do you see what I mean? Or a software project might not have an S-BOM, but it might be very secure. It might be coded very well. It might have a very low attack surface. So there's an S-BOM will never be atomic, because your use of software is very varied. You see, I could be using a piece of software, but it might be using a single function, you know, 5% of the code base that's within that library or that framework. But you know, this is not to say there's been some incredibly good efforts to address these sorts of things like there's VEX that's coming up. You can understand your exact exposure. And there's some smart people grappling with these problems, you know, including yourselves and other people that you know around the community. And it's just a very interesting time because we've now got that, you know, governments are saying mandatory, you know, you need to, you're not going to be able to use anything unless it has one of these. And at the same time, we're still kind of working on these. Yeah. And I think that's an important point. Thanks Luke for highlighting there. It's because I think part of the next slide that I had there was around what does this look like in practice for the open source and for enterprise, right? And I think a couple of the points you touched on are really good. Like for sort of an intro one-on-one basics to coming into this, you know, talking about securing your software supply chain, you have your Aspon, your software bill of materials. Now, of course, there's a lot of talk around whether this is something that you're going to generate at build time when you build your actual artifact, or is it something where, you know, you're using tools like SCA software component analysis to actually generate this after the fact, right? Now, the good news is there is tooling in both ways to do that, right? There is ways to generate your Aspon at build time that are out there, open source project. Even if you don't have one already, let's say you're using a container image, you can use a great tool like SIFT, like Encore SIFT to call another open source project that will actually take your image and generate an Aspon for you, listing out a lot of the components in that package. And once you've generated that, you can generate those Aspons software bill of materials in two large formats as the ones we've seen out there. You know, of course, SPDX is one, and Cyclone DX being the other. And so a lot of folks getting started, that's where they start as they start generating a software bill of materials. Now, of course, with projects like Six Door and Cosign, what you can do then is you can start signing your container artifact, your image itself. You can start signing or attesting your individual Aspons and hosting those alongside, you know, your artifacts on a tool like Cloudsmit, right? You can now not only are you showing that, hey, this is actually what's contained in this image, but you're actually attesting to the fact that yes, I am who I say I am. And I'm also verifying that this is the image. And here's how you can show, here's how you can actually pull that down. And the next step I see a lot in CICD now is with CI Pipelines is folks generating the Aspom and doing attesting in total assetization was step one. And I think the step two part of this is important is now when users are pulling down or consumers are pulling down these facts, are they actually using the verify tool? But I think it's prudent to start signing and producing, definitely, you know, even though the verification part is still kicking the tires, they're working out the best approach. There's absolutely no reason to not start signing and generating now. So you build that historic picture, you know, you've got that historical context. It's a good habit to get into, definitely, no need to wait until everything is perfect and let perfect be the enemy of good. We can, there's lots of good that we can do right away. Yeah. Yeah, so start the generation, start generating your Aspom, start signing now, and then eventually, when everybody comes in to verification, that will be there. The additional periods that you mentioned real quick that I do want to highlight for your users out there listening is VEX, right? The vulnerability, exploitability, I think it's exchange VX effects course. Yeah, I never remember either. But it's around this principle. I think I know Dan Lawrence from Chandler talks about this a lot, where the idea is, hey, it's great because, you know, I mean, a lot of this, too, you know, we had the NIST database and the other things like this, like NVD, sorry, and like other frameworks that tell you when there's a CVE present or something, but is it actually exploitable? Are you even using it in your code? So I think being able to understand these CVEs and other things and to be able to score that system in some way to say, hey, this is actually fine. You know, this image is actually fine. It's also really, really important to tie the ecosystem together. So looks highlight and the fact that standards are important because they enable cointegration with different tools. You know, so for example, with VX or with SPDX, it's more than just one vendor, more than just one solution. We have CI systems and CD systems and there's a lot of source of information that we need to be able to tie together into a separate place because only then do you have a holistic view and everything you've got in terms of the pipeline. You know, and I hope that the dream is at some point is like, okay, we've got a lot of systems that are cooperating at some point in the future utilizing the standards to be able to do that because this machine is talking to machines and we want to highlight the value of that in some way to the users via the FSTation and the fact that they've actually got this holistic view into the software pipeline that they've built, including all the way back to every single dependency that's built in the software that you've built. And a sort of, probably a selfish angle from my perspective, obviously, just talking about Claude Smith is that, you know, we were built as a sort of abstraction layer for the ecosystem in terms of artifact management. You know, so we think about things in terms of how can we integrate with different types of products in the ecosystem for services or tools, but offer that in a nice abstract way, regardless of the artifact format. And that's still a work in progress because, you know, it's not neat and tidy. It's a monkey business is often how people describe it to me. But, you know, I think that we can only do what we're doing based on open service ecosystem and standards as we talked about. So it is incredibly important. And then Leah, I think as you called out, just sorry, Luke, real quick was the idea that this is Lou mentioned as well was the UX, you know, the user experience in the UI. That's something we focus on a lot over here, right, is the ability to be like, hey, make this accessible for everyone, make it actually built into the UI so they can see it, you know, make it easy to generate, but make it also easy to host alongside and make it easy to verify, you know, once you have those pieces in place, you know, then you'll see a lot more adoption with users saying, hey, I actually have this button or toggle I can turn on. This is reasonably easy to do as a developer. I don't have to generate public private keys that I'll lose somewhere. You know, those pieces are really important. Go ahead, Luke. Yeah, I was just going to say, so that paper trail that Liam was describing, what keeps CISOs awake at night is what is the exact exposure to any given risk when it comes to be. A good example is a log for J hits. They want to know where am I exposed, you know, what is the paper trail, and what are the high-profile targets, which ones are more exposed, and that's where some sort of expressive framework such as VEX can really come into its own, then you can actually ascertain your your exact exposure. I think someone was not going to name names, if there's some external was asking about this recently, relative to S-bomb and why it was important. And although there's a lot of work to do, I think the analogy that I had brought up related to what you're speaking about, Luke, is that you're eating food, you want to know, maybe you've got certain types of intolerance, you want to know what goes into the food, perhaps you care more than you want to know where that food was growing, where it comes from, what country the region was, and that's not always easy to get with food, but at least there's some there's some standards in order to help with that. Software is exactly the same in terms of the S-bomb is really describing about what the makeup of that was, you know, and the relationship between what went into it and something like VEX is, well, what is the impact of what went into that software. So if VEX is describing the vulnerabilities as their pertinent to something like log for J, and the S-bomb is showing you that that is part of your pipeline somewhere, you should be worried and you should be looking at remediation and thinking about how to prevent this or fix things, but only with those we have visibility. You know, and I think this came apparent whenever I asked another C2 at some point in my recent past, do you know what software is going into the products that you're building, what your teams are utilizing? And the response was, I feel like I really should though, but I don't. And I think that at that point I realized that, you know, there's still a lot of work to be done in the ecosystem. So going back to the bare minimum of things that people should be doing, you should be thinking about the dependencies that are going to software. We should be generating S-bombs. You should be generating signatures and doing the bare minimum low hanging fruit of just like checks on verification, actually checking that the products that you're building are what is perceived and consumed. And yes, building up a paper trail for something where we can actually be utilizing it on over time, you know, as the ecosystem evolves. So, Lee, I'm going to take your analogy one step further. Sorry, Dan, I'll let you speak a second. But I want to add to this because I love this idea of the, you know, sort of the ingredients on the side of the box, right? So I liken it and sort of to take the next step with that. I liken sort of your S-bomb as that sort of ingredients list. And then when people talk about vulnerability, exploitability with Vex, let's say, I think of Vex is sort of, you know, the ingredients on the side say sugar. So you freak out initially saying, oh, there's sugar in here. But Vex will say, no, this is actually not high fructose corn syrup. This is just fructose, you know, something straight from fruit. And so that's sort of that piece of mind that you have to say, okay, this isn't exploitable, you know, this isn't panic because I know we've all run, you know, different tools, something like even Grape will give you that output from Encore to total call out. Sort of against an S-bomb, they'll be able to generate what vulnerabilities exist. For a lot of that stuff, I mean, we've all seen it, there's just like initial panic. You just see the long list of stuff that's vulnerable and you're like, oh, man, here we go. Again, I have to go through this whole process to check everything. But it's important to sort of like separate that signal of noise, right? In terms of, go ahead, then you were going to say. No, it was just really to follow up what both Luke and Lee had said that, you know, especially with Log4J, I mean, I do work in the trenches in the frontline and the support channels lit up that day. Everybody was suddenly concerned. How do we determine our exposure? We need that visibility. They wanted that visibility on exactly where they had deployed this. And I think it's easy to get caught up as well on doing things, you know, absolutely perfectly and getting to that maximum state. If you look at Salsa, if you look at Salsa level four, where you need, you know, hermetic reproducible builds and things, that's quite a target to hit for a lot of people. It can be very off-putting. But the key is to do something, right? Salsa level one is not off-putting. It's just an automated documented build process, right? With provenance for your artifacts. And that is a great improvement. Anybody that was there is in a much better position when Log4J hit than anybody that's not on the path at all. So it's not about looking at, like I say, level four on the Salsa framework and thinking, oh my goodness, there's so much work to do to get there and how do we achieve that? Just start somewhere. As Lee said, yes, you know, check, check some sign packages, have an automated build process. You don't need to go to the full extent to actually reap a lot of benefit, a huge amount of benefit. And it really outweighs the effort that you have to put in just to do a little bit. So I did want to just say that. That's definitely what I'm hearing. I think to enlarge upon that, I mean, you might have this sort of Fort Citadel build system completely reproducible, every single artifact, every single line, there's provenance for that. And a developer gets their account compromised, their Gmail account. And a lot of the time is how attacks happen. Attacks, a lot of the time, they aren't these complex buffer overflows against a piece of hardware. And it's very simple things. It's very simple low hanging fruit where attackers get in. And that's what they target. They look for the simple things. And so there is so much that you can do with just make sure your developers have 2FA switched on. That's the key one. I can tell you have a couple of really big companies that have been that the exploit has actually started around a compromise around single sign on to that effect of a developer's account has been compromised. They then used it to a backdoor code to a code repository and they've accessed a Jira for closing tickets and all sorts of stuff just from a developer account compromise. So there is so much that you can do. And I think one of the things that we spoke about, we were just chatting before the webinar is your CI environment. A lot of the time, I mean, we live in this time where developers have a lot of freedom to express themselves. And this particularly plays out in CI. It's a wonderful world of marketplaces and plugins and scripts shared everywhere that you can run to do all these automate everything. Do you see what I mean? And I think we kind of enjoy that. There's some sort of validation that we get from changing and tinkering the things and making things automated. But a lot of the times, the security can really take a backseat in that process. Do you see what I mean? So there is so much that you can do just to really take a step back and look at your CI and think, where exactly are we pulling things from? Do we really need that? Do we really need that bot that's going to say, hey, new contributor? Is it really important? Who's this coming from? Start to look at stuff like that, really, because that is part of your production chain. Whatever you're producing there, whatever's been ingested there, is going to be part of your production workload. And we never used to treat production systems that way. We were very minded around hardening, running scans to make sure services that you don't need are switched off. All the permissions would be locked down. All nobody accounts would be closed. You'd really harden a system. Do you see what I mean? And we have quite a disparity now where the CI environment, you can be a bit, hey, you know, writing little string kits and scripts to do different things. And you just one click button and you put in something from a marketplace and then you've got this new funky thing in your CI. And so there's so much that you can do there as well. They're really based to develop with production in mind and making that secure by default. Mantra continue is very important. Making it easy and accessible for developers to do that is the key. Salsa also captured this quite sustainably as well. And Dan sort of mentioned this. We should quickly mention Salsa is, yeah, I just want to mention that supply chain levels for software artifacts. So you can check them out at salsa.dev. We do want to call it out. It's one of the frameworks out there that are really helping sort of advance the awareness of why supply chain is important, but also what you can do as a company and obviously close with as part of what we do. There's some alignment there in terms of like we will help get you to a certain point for it. And then obviously there's things that you need to do to build upon that. What I was going to say is that Salsa sustainably captured an aspect of just because the ecosystem is built upon level zero artifacts is and they don't really do a lot. It doesn't mean that you can achieve some level of compliance with due diligence of your own. So it says something like a level four artifact produced might have been built upon a sea of level zero artifacts, but you have to start somewhere. So I think the process is in your company, it starts with the companies here to utilize them product. Well, that's from adopting tilling like six store and really, really important things in the ecosystem or by utilizing something like close with as a central source of traces for artifacts within organizations. So it's pretty important to start kind of together with the relevant tilling. Yeah, no. So I just want to do a quick time check. I know we're low on time here. We may go a couple of minutes over just for folks if they want to. But yeah, talking about some of the stuff we should call out some of the projects in the space that we've talked about here. Before I do, I know our folks over in a class that have been busy in the Q&A as well, Kira from DevRel, Kira, Kerry, who recently did talks on a lot of open source software supply chain stuff. She has a lot of great content out there. So I'm going to quickly shout out to her because I think she's got some articles on our blog and she recently did a webinar on actionable S-bomb content, right? Being able to actually do stuff with it and analyze it and take a look at it, not just generate it. So I think feel free to check out the Cloudsmith blog for some of her content. She's also done a webinar on that and she's recently done talks as well. So we'll include link later. I think Candace is including some links after and as well, I mean, just wanted to call out, you know, links foundation, Cloud Native Community Computing Foundation. I mean, a lot of the folks behind efforts like Salsa.dev and, you know, like supporting projects like Six Store and Cosine, I think it's really important. So that's been really great. And, you know, obviously feel free to check out cloudsmith.com. We support open source repositories, secure by default. We let you generate your S-bomb alongside there as well. So I think the one question I will highlight here real quick from Alessandro is there was a mention here. He said, Hi, all is the S-bomb signing paradigm, the only way to solve this problem. So I'll just quickly preface this by saying I don't think it's the only way, but in terms of, you know, formats and open source standards, I do feel like that's the leading thing right now, which the community is again circling the wagons around like focusing on. So I do feel like it's important to focus on centralized efforts that everybody can use that are accessible, that are not locked behind enterprise platforms and stuff. So go ahead, anyone? I think, well, what I will say about it is it's not the technique of S-bomb and signing in itself. It's the reason why you're doing it. So S-bomb's visibility, right, to be able to understand what went into the software and why. And then the sign inside of things is the verification to say, can I prove that the state that I've been running with is true? You know, so certainly S-bombs and sign alone are not just the answer, but they're definitely a big part of what's necessary. Look, have you got anything in terms of like, initial capabilities, I think? No, I would agree with you there. It's what it gives us, you know, it's the datasets that it'll provide for us to then be able to make decisions. But there's one part of this, you know, there are lots of other controls and technologies. Yeah, what I would say, sorry, the other thing I would say obviously is pick your tool wisely. And, you know, I think in terms of utilization of things like this organization, that's really, really important from the trying to think about it from a uniformity way, you know, so you really don't want to have outliers in your organization that some people do sign in this way, some people use sign in that way, or some people don't do it, or some people store their artifacts one place and then other teams in another. The more that you can leverage doing the same things across the organization, well, one, it's more efficient. And two, you've got a sort of common language internally, utilizing the same tooling. So whether it's a store or a different solution, it sort of doesn't matter. The outcome is that you're generating these bombs, you've got visibility on what you've got, but you've also got some way of verifying the assets you're building. And you've got to secure a place to store and distribute those from. That's the selfish angle of right that we're talking about. But regardless of what the solution is, you need to take those boxes and you need to be thinking about it, I think, and in terms of your process, holistically, from development, as Alex said earlier, right through your production. That's the key to making sure that, hey, this is secure, more secure than perhaps what we started with, secure by default. And I think that's along the lines of, I mean, also just to touch on the S-bomb piece of it. I mean, remember that that's just a format, like S-bomb is just a principle, right? Software bill of materials, there are different formats for S-bombs. There's SPDX and Cyclone DX. And there's many, like Lisa, there's a lot of tooling around this to use these different formats and coming up in different package formats as well, ways to generate the different S-bomb types. So I think it's the principles you have to hold on to more. And I mean, the tooling is there and, you know, choose wisely, so to speak, but definitely it's the idea of, you know, like getting from into the mindset of securing by default for sure. So I think a great way to summarize this whole talk is Kira has posted a question in the chat as well specifically towards Luke. She said, Luke, are there any easy tips for securing your software? So I think that's a great way to end this. So is there one easy trick? I think what you mentioned before in terms of start simple, right? I'm just trying to stick to the easy bit. Easy tips to secure your software. So I'm assuming if it's, you know, they're saying your software, they're talking about software that they write. If it's open, okay, then it's going to have more eyes on it, certainly. So that's, I would say that's, that's probably a bit of a sneaky get out one. Generally, like, invite people to review your code, you know, leverage peer review. That's a very good security control, which is easy and free. It's the best way, right? Keep it open. Also work with people here really into security and involved in the process, right? Actually, this is, this has come up a couple of times, like, you know, in the conversation and I've heard Linus's law, I think mentioned several times, and it still holds treated to until today. And it's essentially given up eyeballs, all bugs are shallow. And I sort of think there is an evolution to that. You know, it's, it's fantastic. And it's a great proponent of the open source ecosystem to say, well, the more people there are to look at things, then the less likely that there are issues. And that's the reason why open source works really well. You know, and I think that applies internally as well, which is basically what Nick is saying. I just sort of have a jokie extension of that on my head, which was something the long lines have given enough s bombs and all exploits are shallow, right? You know, so, you know, it was going into it, but the point is, is just I think, you know, yeah. And something else that quickly comes to mind is the open SSF go to the open SSF org. They've got best practices for developers. They've got lots of nice guides there that can help you out secure somewhere. Yeah. So thanks so much, everyone, for your time. I'm going to wrap this up by saying thank you to my colleagues, Luke Hines, Lee Skilin, and Dan McKinney for joining us today. I'm Adele Ligari from Cloudsmith. And thanks so much, everyone, for your time. I'm going to throw it back to Candice now. I hope that this was productive and helpful in furthering this discussion. Thanks. Over to you, Candice. Thank you. Thank you so much, Lee, Adele, Dan, and Luke, for your time today. And thank you, everyone, for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day.