Transcript for "Learning Labs: Chainguard Libraries":
Thank you all again for joining us. Let's jump right into it. The recording will also be available for those of you that are going to be joining us a bit later. So we're going to talk about ChainGrad libraries, the why, what, and how for building your applications with open source libraries you can trust. The question, of course, is where you get those libraries from. My name is Manfred Moser. I do go mountain biking. At the moment, there's not as much snow, unfortunately, up in the hills there, so snowboarding is out of the question for now, at least in those hills. I'm in Victoria, BC, and I'm a dev file engineer, Chainguard, and open source hacker, author, and more. And you can probably meet me at the next conference if you go to Google Cloud Next or the Open Source Summit later this year. So what are we going to do today? We're going to talk about why you even care about where your open source libraries come from, why you need those libraries. And that automatically leads us to software supply chain attacks that seem to be constantly in the news and causing havoc all over the place. With more and more people also using AI tooling, it's also becoming more and more critical and more and more widespread to use open source software. So, it's critical to understand what you're putting yourself out for. We then talk about Chainguard libraries, where we build libraries from source and serve them to you, and why that solves a whole bunch of problems and how you can use it. And then I will do a whole bunch of demos about new features from Chainguard libraries, also some other features that we already had in the past, and show you how some example projects can be used, and how easy it is to get started with direct access, but then also how you can scale to a robust enterprise use as well. And of course, I'll also be available for questions anytime, but you can also save your questions for the end of the session, if that's what you prefer. So, let's talk about the software supply chain and should you be worried. In a nutshell, I'll leave the judgment to you after we talk about what the software supply chain even is. So there's multiple software supply chains, so to speak, because no software is really that trivial, that it just has a single supply chain where some components come from. Most software is built on other software from different ecosystems. So, you might have a web application that has a back end written in Go or in Java, and then like a front end in JavaScript maybe, especially in the browser, obviously, but you might also have a desktop application that's written in Java, and then the back end is in some Python parts for some AI and ML workload. So, most of the time, software is built on a whole bunch of components, but even your proprietary software they use wherever is basically impossible to create without open source. That's because all the underlying operating system Linux and then all the libraries to really get anything done is open source in the library ecosystems. The reason that's the case is because people want to collaborate and make the best version, and multiple people collaborating is always faster and better than a single person hacking something together that works for only their use case. The other important aspect is to consider is when you declare a dependency, say you are saying, oh, I need Node. Js for my front end and back end, and React from my front end of JavaScript application, you just declared one dependency like Node. Js or React, for example, but that doesn't actually mean you're only getting one dependency. Typically, that one dependency you actually proactively declare and understand then results in dozens or hundreds what's called transitive dependencies under the hood to also be pulled in. And your application is a composition of all of those. So, it's a composition of all of those raw materials that come through the software supply chain to you and make your application. But that software supply chain is a very fast moving network, right? Like, there's new releases from all these open source components all the time. They constantly update each other's dependencies. And they all come in as binaries to you with many, many actors working alongside each other to get those binaries to you. Like, you're not actually ingesting the open source project as open source. You're injecting them as binaries. So, let's see how this looks like especially here. This is a diagram that should look familiar, and I just saw in the chat there's maybe a question. No. Cool. So the software supply chain of artifacts here is depicted what's actually happening. You as a developer in your application and the company are on the right here. And in fact, myself also, and anyone else who does any software development also always sits on this right side. Even if they are a maintainer of an open source project like myself and others, you still have other components. So you're always sitting on the right side as a consumer of these open source projects and libraries, but sometimes you're also sitting as a maintainer on the other side. And you're also often then involved in everything in between. So a maintainer writes source code. These source codes are stored typically in GitHub, or other source code hosting systems using Git these days, used to also be in all sorts of other ones. But these days, it's pretty much Git only, which arguably is a good thing, because it's pretty secure and well managed. And then, however, the source code creates releases, and then the releases are built as binaries in a build system on GitHub Action or whatever, Jenkins, or there's lots of different ones in your various build tools, systems. They are built, tested, they pool in dependencies, and then they get to a distribution. The distributions are typically public repositories or registries, as they're called. So, there's the Python package index in the Python ecosystem, the NPM registry in the JavaScript, TypeScript ecosystem, Maven Central in the Java ecosystem. And there's many others of those, but those are like the big ones. And those binaries then get to you as developers. The problem with this complex supply chain is that what ends in your hands as a developer isn't just handed over straight from the maintainer, it goes through many hands through these different systems, and there's attacks of vectors available everywhere there. And also, other problem, of course, is you don't know who these maintainers are, right? Like there's lots of them, and you don't know them individually, but you trust the source code, really. That's what you're trusting. What's there, because multiple maintainers collaborate together, look over each other's shoulders, and get a source code committed to those repositories. So, the supply chain is where you potentially have issues. And if you see over the last years, there's lots of these issues that came up. And that's also where malware is often checked, because credentials to these distribution centers get stolen. So, let's look a bit on what kind of some of those attacks are that have been happening. So, there's a long history. I just went back to 2020, because that's like one of the big ones that was known. There were many more before, but we don't want to go digging out too long old stuff. So, let's talk about a few of them. The first one that comes to mind that was a really, really big attack was the SolarWindsSoundburst attack. So, Sunburst was a security issue in a SolarWinds component. SolarWinds was a software to distribute Windows software. It went very wide. It was an organized, long term Russian attack on U. S. Governments and large company systems, but it affected many, many, many, many people as a collateral damage and caused a whole bunch of damage. 2021 Log4Shell is probably the biggest one. It affected the Log4j library, which is a popular Java library. There was a remote code execution CVE. So that was not an attack by anyone specifically, it was just a vulnerability that was found. But the effect is the same, right? If you then ended up with this potential problem in your libraries and in your applications, in this case, was very, very widely spread. Log4j at that stage was probably the default logging framework. That's not necessarily the case anymore, but it's still very, very popular. And you were vulnerable to those remote code execution CVEs or common vulnerabilities and exposures alerts, and people had to have all hands on deck in case there was an attack. So this is different in a sense that the SolarWinds and SandBurst attack was an actual attack where lots of companies were affected, and government agencies were affected, and they had to clean up. And so it was a fire like check. On the other hand, Log4j was even more widespread, but not everyone was affected. People were just preventatively making sure they weren't exposed. So, they went through the same process, checking where those dependencies are and removing them. In twenty twenty two-twenty three, the PyTorch dependency confusion was another attack, a different approach, but another attack, this case PyTorch common Python library in the AIML kind of like ecosystem. Artolytics is in a similar ecosystem, but on the JavaScript side, it's a UI Sorry, a video processing ML model that was attacked, and there was an attack there that caused a lot of efforts. And in 2025, crazily saying last year, this is already like there was a wave of the sandworms, so to speak. Shaihulud will talk about that in a sec. And then now, recently, again, we just had this recent attack on the Trivia system with GitHub Actions and being involved, and then a whole lot of credentials being stolen, also spreading further in a second wave via the Light LLM component. There'll be actually a specific webinar in a while. This is still developing and I'll tell you more about that later. But so there's a long, long history of these attacks. If you look at the Shai Hulut attack, there were literally three different ones. There's Shai Halute, then Shai-one Halute, and then now the Sandbar mode recently. All of these attacks were in the JavaScript ecosystem, certain credentials from maintainers were stolen, similar to the also Chalk debug one earlier. Maintainers had the credentials to the NPM register stolen, artifacts were published into it. And in this case, the Shah Alud ones, they were what's called a worm. A worm is a long, long used term in the security ecosystem for a computer software that sort of self replicates, similar to the idea of like, when you chop an earthworm in half, then both sides are operational and can continue to live. Software that can replicate and then keep moving on and spreading further, even back in the day before the internet that happened over like floppy disks. This is what a worm was. And this Shai Halood worm did that via developer workstations and CICD systems. It damaged Git repositories, pushing messages out there, stealing the credentials from them, and then basically just moving across the ecosystem. Also, the last one, the server mode, even had some prompts injected as hidden prompts in the Claude and others AI, by coding kind of ecosystem configuration files, so that whenever someone used Cloud Code and had that injected, it would steal their secrets and scrill them away to later send them to the attacker. So, this system spread automatically, and obviously, Shaihalud is the name of a worm from the old science fiction books that recently were in movies and they're like wildly known. And they disappear and they come up elsewhere, just like these attacks. So it's a good name. Last one, just a few other ones to talk about, to give you an idea how different these attacks all are. So the XCutils was a long term social engineering approach where someone gained maintainership in an open source project over many, many years, which that's amazing, right? Like someone is helping an open source project many years, only to then after getting maintainership, turning around, exposing, like basically putting a vulnerability into a release, into an official release, and then shipping that for malware kind of purposes. And luckily, on the XeUTL system, it was called very quickly and did not result into any big problems. But this shows that just like the solar windsunburst attack, where a large organization of Russian hackers was doing a coordinate effort of technical hacking. This one was a social engineering effort. So there's different approaches. Another approach is what we saw in the deep sea ecosystem. Deep sea, remember a while ago, was all media craziness around the deepseq AI models out of China. And in that kind of like frenzy around or interest around deepseq, some hackers just took advantage by publishing libraries that pretended to be around DeepSeek by what's called typo and slob squatting, so they used the DeepSeek name with three Es instead of two each side of the deep and seek, and to get published libraries or malware into the npm registry with this wrong name. So, if someone would install them by just having a typo, they would get them malware. And that did actually happen to a couple of people. So this like typo and slop squatting issues do happen and also affect people. The chalk debug one was kind of what I mentioned earlier. It was another attack that happened just before the sandworm ones, so the Shaihalud ones. Similar thing happened. The NPM registry is still trying to tighten the ship, sends email out for people to remind them to change the password change the credentials and make sure they have two factor authentication done. However, hackers send similar looking emails out as well. And unfortunately, a maintainer of the ChalkDepark systems went through that on one of those spam and phishing emails, and that got his credentials stolen. The hackers then published chalk and debug and other packages into the NPM registry and then ended up causing issues there with malware spreading again. In this case, it wasn't a worm, but there were still multiple libraries infected, because specific maintainers were controlling a couple of very popular libraries that then got used. Last but not least, the DYDX hack that happened recently is also interesting, because this one was a coordinated attack on multiple ecosystems. So typically, as I mentioned, it's either the JavaScript ecosystem or the Python ecosystem or Java or like native binaries like XCutils. In this case, the DYDX attack, DYDX is a crypto exchange management and trading software and library that's fairly widely used, and they get attacked for all sorts of reasons all the time, because it's a rich target community. In this case, they had an attack where they stole credentials and then were able to publish to the NPM registry and the Python package index at the same time and had a coordinated effort of multiple malware packages in different ecosystems around DYDX, which is just showing again how elaborate all these attacks are coming together and how busy it is out there if you pay attention to what's going on in the ecosystem, and if you depend on that. And if you're doing any software development, you will be depending on it. So, there's this current trend that just continues, the struggle between the sort of like black hat hackers that want to attack you is getting bigger and stronger. At the same time, the defenses are also using more and more tools and getting more and more complex. So it's getting more There's more players, there are more targets, there are more tools, but also more issues. So it's basically pretty wild out there. So let's look at some of the trends what are also happening in those. So one trend is that the public registries, specifically where you get your binaries from, so Maven Central, Python package index, NPM registry, they are all kind of struggling and scrambling. They're all underfunded, understaffed, because no one wants to really run that. There's no business in serving binaries to large companies that don't pay to get those binaries, right? Like, do you remember when you last paid for your membership to Maven Central or something? No, you don't, because there isn't anything like that, right? And even more so, for you as an open source developer, that's fine, right? Like, you're just downloading a bit of binaries here and there, But if you have a large company with thousands of developers and BCCICD, you're causing significant cost to these repositories and registry operators, and that's not being refunded. So, there's significant cost being put into running these systems, but at the same time, there's not enough resources to keep those really secured. They're starting to do more trusted publishing, but you never know where this is going, right? Like the Python Software Foundation running PyPI, GitHubMicrosoft running the NPM registry, Sonatape running Maven Central, they all sort of like have a hard time and hopefully that can change in the future, but you never know what's going to happen. So these ecosystems and repositories might be struggling, they might fall apart, so you need to be prepared. On the other hand, what's also amazing is that the targets, as you saw earlier, they get more and more interesting, right? Like there's crypto mining, there is access stealing for corporate secrets, there's even just like you know, AI token theft in terms of like accounts and all sorts of stuff like that, but makes it more and more interesting for people to lead these attacks, not to mention political attacks and those kind of things. So there's lots of reason for people to get to those juicy targets. And then last but not least, and this is something we are definitely seeing more and more. In the past, there were like, you know, script generators and we had script kiddies attacking, this is much more powerful now, you can definitely see that AI is accelerating software development for everyone, and that includes the attackers. Obviously, Chainguard is doing a lot with AI development and accelerating our efforts, but hackers on the other side are doing the same. So this is something that's going to just get more and more common that you hear that AI attacks are doing that. And the recent trivy Light LLM attack is one example where AI tooling was definitely involved to make these effects more widespread and more impactful. So the attacks definitely intensify. There are over 500,000 new malware samples come up daily, which is kind of an insane number. New vulnerabilities get discovered daily. The time for an exploit to become available for unknown security is only forty four days now, and that's only going to get slower, get faster. It also means that what often happened, you know, in the CVE system, the threat level is like critical, high, and then medium and low. There will be more and more focus on not just exploiting those critical and high vulnerabilities, but with AI tooling, it'll probably become a common thing to like even target some of those other vulnerabilities. Not to mention, there's always going to be vulnerabilities that are not even discovered yet. So overall, here in 2024, there were 16,000,000,000 cybercrime losses. That's a big, big number. And you don't want to be one of those people losing some of your business to that kind of problems. And most importantly, also, you don't want to be in a situation where constantly have these incidents. There's kind of two sources to these incidents that happen at companies, right? Like, on the one hand, there is real attacks happening, like the ones I mentioned before. And then there's attacks that are not actually happening as attacks, but they are potential attacks. So when a new vulnerability is discovered, Log4j was a good example for that. It was a severity 10. So as much as a severity as is available in the scale, security issue, no one wanted to just wait until an exploit is there, right? Like people are just like, we need to fix this. In both cases, we have these fire drills, where you suddenly spend a week or multiple days at least just rotating all your secrets, checking all your libraries, checking all your access modes and everything. These cost a lot of money and the spread of these incidents is also getting further and further. In the past, it was common to have an attack, try to infiltrate a production system, get into production database, and that was it. Well, now the attacks want to get into your CICD chain. They want to get into your developer workstation, because that's where the secrets are for access to cloud environments, to other systems, maybe to like Salesforce or whatever. And that's the next thing. More and more people use tools like Cloud Code or other systems that have more and more of this access. And it's not just developers that use those tools, it's pretty much getting more and more across the companies where these tools are used in all sorts of stuff, like in in Cengage is a good example, right? Like our marketing team, our sales team, everyone is using some AI tooling to increase the efficiency of their flows, but there is a danger in that, right? Because they all, and we all become target of these attacks as well. And you don't want to get into that sort of scenario where you have to constantly participate in those fire drills. So one tool that help you avoid a lot of that, including pretty much all the attacks that I mentioned earlier on the supply chain, is Chainguard libraries. And that's what I want to talk more about. But before I do that, I'm going to check the chat for a second if there's any questions about any of those attacks. Yeah, Eric is just mentioning that Log4Shell was crazy. That came and had a big impact on Minecraft. That was also kind of funny. Minecraft is one of those systems that people underestimate how widely spread it used. It was also one of the tools that brought Maven Central to its knees at some stage, by the way, because Minecraft modders, like you can write your own Minecraft versions, and that's very, very common. And Minecraft had links to Scala libraries in Maven Central, when you build your Minecraft mod, you're building a Java application essentially, and it had links to Scala libraries, and those links were very big. And then when one of those Minecraft libraries had a misconfiguration, it caused the download of the Scala libraries from Maven Central so much so that it brought Maven Central into its knees for a few days. So, the impact on these attacks and the importance on these libraries and where they show up is crazy. It's like everywhere, literally, right? Like, just think about all the devices you have in your house, maybe you have a security camera with a home hub, a router. All of those libraries always come. They're always open source libraries, and they come from those reposters and registries. So, let's have a look and see what we can learn about Chainguard libraries. So, Chainguard libraries come out of the Chainguard agentic factory. So, you saw earlier we saw the maintainers and the source, and then this whole infrastructure around the public repositories and the build and all that kind of stuff. Well, we take all that public infrastructure away. We trust the maintainers to the work by collaborating and putting the valid source code into the source repositories. But beyond that, we take over and don't trust the ecosystem, not because we don't trust all these other people, but it's better to be safe than sorry, right? So, we want to understand the whole supply chain and provide you as our customer a solution where we can guarantee that what we give you is really only the open source libraries based off the source code that's valid by the maintainers and not some other random stuff that got shimmied into via credential theft and so on. So, the Chainguard factory runs all within our cloud ecosystem. It's using Driftless AF, a AI framework that we open sourced, and it builds the libraries from source, and then distributes them to you. And by just building from source and from source only, we're eliminating like over 98% of all the malware risk, because remember when I mentioned the attacks earlier, the malware is typically pushed into the public repositories and registries by credentials being stolen and then malware being injected into those libraries as a new version. Like say, for example, you have a library like Flask or whatever, and there's a version 1.2, A library is then just deployed to the Python packaging, which says Flask 1.3, and then all the tooling of the developers in your organization would automatically pick the 1.3 version up. Or that's because it's available in the registry, not because the source code changed. Such a component would not get into Tingent libraries, because obviously as a malware author, you're not going to go and publish the source code. That's against the whole idea of like hiding what you're doing. So that's not happening. And also, you wouldn't have access to the source code repository. GitHub is very secure, and it's very, very rare that open source project repositories get compromised, and then also successfully compromised so much, so that a new release is tracked with valid source code that has malware in it. Like, that has not happened at this stage yet. It might, hopefully not, but that's, at this stage, like that's way too complicated to get into, and I think that's also there's too many eyes on it, essentially. So, the malware is injected on the pipeline and we take over that distribution of the pipeline by having Chainguard factory build all the libraries from source and distributing it to you in a secure manner. And also we add more stuff. So what we do is we make sure that we build from source, we don't look at the binaries, which also means if there is no source code, there is no binary. We replace the public repositories, so we replace Python package index, NPM registry and Maven Central with compatible replacements that use the same APIs and access models, so they're used perfectly fine. You don't get any malware. You don't get any ghost releases. Your ghost release is a release that's newer than the official release and basically sneaks in. And then, in addition, you get SBOM information, so software bill of materials information, like what's in the library, what's also needed by that library. This is important to understand when you trace down, like, so these have these fire drills to understand where something comes from and what else is affected. So, the software bill of materials is useful for that, and it's also often necessary for compliance reasons. So, software bill of materials gets published for all libraries, which, by the way, is not something that commonly happens in the public repositories. This is painful to put together, and a lot of open source projects don't bother with that. And then, last but not least, we also supply provenance information. So, that is information that says who built it, from what Git repository, what SHA or tag, what infrastructure was used to build it, so what Kubernetes cluster we built it in Cengage Factory, and at what time, what was involved, and so on. And all that information, the provenance information is also supplied with our libraries. So what Chainguard libraries do we have? We have Chainguard libraries for Python. So we support the typical Python tools, typically those are like the original PIP, the more modern UV, and then also the kind of not so commonly used, but also well supported poetry. So all those are tested and work perfectly fine. And we provide all sorts of libraries. I'll show you later on Flask, NumPy, all those kind of things are all available. In addition, in the Chainguard libraries for Python, it's quite common that native binaries are embedded. That's something that happens in the Python ecosystem. That's just how the ecosystem evolved. It's always been close to the underlying C libraries like OpenSSL for security and so on. And in a lot of Python libraries, these get embedded and also contribute to security issues. Chainguard, when we rebuild those Python libraries, we also rebuild those underlying C native dependencies, and we also update and remediate any securities on it. So a Python library that we supply with these native dependencies also has security fixes from the embedded components. That's not even always obvious that that's even happening. And then last but not least, we also do CVE backports, so fixes look, CVE fixed backports in common libraries, and I'll show you all that as well. We then have Chainguard libraries for Java, which replaces the libraries from Maven Central, and the other build tools are the usual Apache Maven itself, and then also Ant, Gradle, Bazel, and the libraries are Spring Boot, Jackson, all these libraries that are commonly used, including also Log4j obviously, are available in Chainguard libraries for Java. And then the latest one is Chainguard libraries for JavaScript, which replaces the JavaScript and TypeScript kind of components out of the NPM registry. And we have tested and built out all working support for the common build tools there, which is a bit more widely spread and diverse. There's NPM, there's PNPM, the more modern one, there's Yarnberry, the modern version of Yarn, there's Yarn classic, there's also Bunn, which I haven't even had it on the slide here. All of those tools work perfectly fine with Tsingular libraries. On a JavaScript ecosystem, there's also pre and post install scripts often embedded in libraries. So before it is installed on your system, some script runs, we make sure that those don't carry any malware and eliminate them as well when they're not needed. So, we reduce a lot of those security issues. So, let's get rolling into some demos of these libraries that we now talked about. So, first of all, let's look at the Chainguard console. When you onboard into Chainguard libraries, you also get access to and I have to authenticate now. You get access to the Chainguard console here. You see the console here. I'm in the chain guard edu organization. I'm also in others, but I can typically only in one organization. And then on the left here, you see the ecosystems available that are available for you to let me go here for a second. So in this libraries here, we can now search what libraries are even available. So first of all, let's go to Java, and you see the Java ecosystem that's at the bottom right here. There's over 80,000 libraries available. That's just individual specific libraries and not, like, example, commons length three, for example, is a library from the Apache commons project. And you see here, this is one library, but it's actually like 18 different versions. So, if you go in here and you see, these are all the versions that are available from this common slang component. Right? Another one you can try here is, for example, org. Spring framework framework. So, for example, this is the group ID in the Java ecosystem for the Spring project and workspring framework, whatever. There's also all these components. And you see, like, some of them, a 112 different versions, 43 versions. This is the old Spring framework. You can also go I think the old coordinate from like very old Spring was just like this, and it finds those as well. But Spring itself here, for example, these are the newer versions, and then you can page through the different components like Spring Web, for example, here. Lots and lots of different components available. Now if you jump over to the JavaScript ecosystem, same thing. For example, we can look at something like Picocolors, a small library for listing libraries oh, like, listing colors. And that should bring the libraries here. And you see here there's something from a other author, Brillout, Brillout, but the official one is the Picocolors itself. And you see again different versions here. Go back here. We can look at something like Commander, another library that's commonly used. Again, search has to go through. You see here, there was before it said 200, so the JavaScript ecosystem is quite a lot bigger. There's over 200,000 libraries, and then there's more versions for each one of those libraries. And you see here, also command is a good example where different people created different versions and forks of Commander. The official one is this one. And then you see here there's like a whole lot of different versions and you can page through them easily as well. Now, last but not least, also interestingly, let's look at Python libraries. So, for example, we look at Flask, that's a common library in the Python ecosystem. And you see again, there's a bunch of different ones that are like versions of Flask or like components for Flask and supporting Flask, but the main Flask is this one. Also, what you can do here in Flask and like in all the other library versions, if you, for example, here have like 48 different versions and you know you're on something 2.1, for example, you can see these are the 2.1 something versions, and then the latest one is two point one point three. But also, and this is interesting, there is a remediated CVE version. So as I mentioned earlier, in Tinker libraries for Python, we show these remediated versions, and you can see here how you get full information about the CV that backpoiled. So we took a fix from an upstream latest release, backpoted it to the old version and made it available. So that's browsing, and then you can go to the CV or even go to the GitHub advisory and find more information. So super useful to go through here. So this is let's go back here. This is the library browsing. The other thing you can do is you can, in the console, also get your pull token. So once you have seen the libraries here, what you also can do is you can get access to the pull tokens. So you can go and get an access token by just creating an access token and giving it a name, whatever your token, and then you set it for what you want to have access to, Chinga, Java, Java libraries, or whatever. And you can also set it how long it will be valid for. Oops. Sorry. The other aspect on how to get the library as access token is, however, the chain CTL command. So there's a command. Let me make this big again. There's a chain CTL command that you can use to create an access token. And an access token is just a username that is essentially a long random string and a password that's an even longer random string. And if you run the command like I show here, change CTL auth pull token output and repository Java, you can get them as environment variables. So you see here export Chainguard. You could evaluate them, or you could store it in a file, and then you can use those to browse in the console or also on the web browser. So looking at the web browser, for example, if we go like, I have where's my editor? If I wanted to browse, for example, the Python package index, so I can go libraries.cgr.dev Python simple. And you see here, I'm already authenticated, so I got in. But if I weren't authenticated, I would have used the authentication tokens. I can also fire that up and show you my tokens. So I just have these tokens. I can't see it here. I ran this command, and then I put those into a dot env script, and that's the script that then run. So this can also come from a security secrets management application, but in my case, these are just test tokens, so it doesn't really matter. And they also expire. Right? So they're very, very long, but I can then, in my example project, source that, and those environment variables have the right access credentials. These are the same values I can use to log into here. And then, for example, let's go and search for AIO. So there's AIO HTTP, which is also a library that I wanted to show you earlier on the other side. But specifically, also this is interesting because you see here, AIO HTTP is one of those libraries that has a native dependency in it. So because it has a native dependency in it, we need to make different what's called Python wheels. So a Python wheel is an archive to use by a Python packaging tool to download a dependency and extract it. And you see here, these are for different Python versions and different c versions, like Python 3.9, for example, or 3.13, and different Linux distributions. So our archives are suitable for different Linux distributions, so that's why it says many Linux versus just Ubuntu or so. In case also specifically, of course, it works for our Chainguard OS Linux, so our containers, but it also works on other Linux distributions, provided they have the 2.28 or 2.39 GCC LIBS. So that's why there's different ones. And then also, you see here, there's the Arch and the x86 ones. So there are ones for AMD, sorry, ARM and x86 processors. So there's different packages. This only applies for ones that have native dependencies in it, like something like, I guess, like, if I look for, like, flask there's another one. So, Flask itself, I don't think has any native dependencies in it. So, yeah, you see here Flask is only available as a tarball or a wheel. And then you see here the wheel is just whatever Linux distribution, whatever, because it's just Python code. There's no native dependency in it, so there's less different files available. But you can see that this is the browsing in the browser directly. And this is following what's called the simple index here for the package index from Cengage libraries. There's also a separate index called Python remediated, and that contains the CVE fix ones. So you see here, you can browse which ones are available. Arguably, these days, you can now just browse here as well, and you can see them and search them and that kind of stuff, which is in Python. Another thing I want to show you is the same thing for Maven. So if I go have to go into a separate index because I have to sign in in the Java context. And you see this is the demo of, like, how you sign in. Now I would go over here to my editor. If I get it. Where are you gonna go? Get my token. Paste that in. Get my password. Paste that in. And don't worry. This is fine. It is a very, very long token. And you see here now if I go do a search for, say, org, like, again, I we wanna look at the common slang. Again, Apache. The group ID is org Apache and then comments. Right? That's the group ID. And now the project is comments lang three. So that's the artifact ID. And then now we have the version. So let's look at three nineteen. This is the typical Maven repository format. So you see it includes the Maven metadata. Like, this file just says what's what are the versions that are available and what's the latest one. And then specifically for three nineteen, you also see how many files are actually available. Like, Maven repository format includes, obviously, the POM itself, so the .POM file, which is here, and all the checksums, but the .POM file is the file that contains all the metadata. So, if I look at here, you see lots of metadata, including also what all the dependencies are for testing and so on. Right? Like, this is the Maven POM file. And then the important one that you need as application developer is the char file. So there's the JAR. This is the larger file like you see here. It's like oops. 69 kilobyte. And then that's the POM. But then also additional files that we publish as Chainguard libraries, there's the salsa attestation. So this is the SPDX. Oh, sorry. This is the salsa. This is kind of, like, not readable, but this is our attestation, the software bill of materials essentially. And then the SPDX is the provenance information. So if you look at that, that's the SPDX format. Also not very readable. If you, like, formatted nicely, it'll you can find out more. But specifically, it should say yeah, here. The tool and the creator is Chainguard. So you can see here that this binary was built by Chainguard and the SPDX providence information does detail that, and a whole lot more as you can see, but that's the information from the Maven repository format. Now, let's jump back over to the slides if I find them, and see what I'll show you next. Yeah. So we saw the pull token, and I used the pull token now to log in, and I showed you how to use them as environment variables. And we saw how we can use the pull token in the URL to browse the simple index for Python and see the different packages and also for Maven and see the SBIRM and provenance information. Now, I'll show you a few demos. I have a little bit of time for that. So let's go over here. Let's have a example script. I'll show you an example script first. I have let's go, for example, the pNPM test script. So if I go the pNPM test script is a very simple script. It initializes a new PMPM project in a new folder that it created, and it's importantly, it it sources the, credentials from that environment variable file that I showed you. And then in this case, I'm doing direct access. So I'm setting up the registry with PNPM as a configuration to access the JavaScript repository. And then I set the identity username to use for configuration to use the pull token identity, and then the password, the same thing. And then I add a couple components. That's all. And then I run an install and a list of the components. So if I go pnpm so that was the pnpm test. If I run this script, pnpm test, you see it runs, downloads the dependencies, and creates that project. We can also look in the editor here. Example scripts. The this is the folder got created now. You see there's the package JSON with the two dependencies and and, like, the name of the project and so on. There's the the log file with the integrity numbers and so on pointing at the Tenga repository, NPMRC, the configuration file that was created, and the node modules that got downloaded. Similar examples, if you run, for example, the dot slash bantest, we just let that run, does essentially the same thing. If I look at the script here, now you see it creates the create directory test test BAN, and the BAN test is a similar thing. It's just different syntax for exactly the same idea, essentially. In the case of BAN, there's a BUNFIX. TOML file that you need to create. There's no command to do that. So, we're just cutting the configuration into it. And you see here, again, I'm using the environment variables to get injected. And then I add a bunch of BUN components into a BUN. Depending on, like, a bunch of components, install it into a PM, and you see here, there's my components. And you see in the project, the test plan project, it created all the necessary assets, and here's all the modules all coming from Chainguard. Now I'll show you one more example. That's the chain guard. I will in terms of time, I'll go maybe a few minutes over, but that should be okay. I'll time it so that we're good. Christine and Alekka are wondering. Trevor is asking if you have a roadmap for cargo packages. So cargo, let me think about cargo is the system that's also used for Rust packages, right? And yes, we are looking at go, rust and .net/nougat as one of the next ecosystems, while in parallel also ramping up our package. As you saw earlier, we have a good amount of packages, like 200,000 plus in the JavaScript ecosystem and like a high coverage for our customers what they need, but more customers coming on meets more libraries, and obviously the ecosystems are also using very fast, so we have all those. Great question though, thank you Trevor. Next one I wanted to show you quickly is there is a UV example project that I have. So I'll run this. I'll just go. Sorry. I was being CD training example projects, UV example. This UV example does a similar thing. For the authentication in Python projects, it's very common to have the dot net RC file. So, I go and show you that dot net RC file, you just go live with a cgr. Dev, and then the username and password in here. Then that works nicely for Python projects. I do a similar thing in this script here. So it basically is configured to access the two indexes here from Chainguard, the remediated one and the simple index, and it gets a bunch of dependencies from as declared here. And especially, for example, here I'm declaring dependency to Flask, and this will actually pick up the remediated version. So not two point zero, but 2.001. So this is a newer version where we backpointed the CV, fixed into that version, and updated it with a smaller bump on the local version, which is this CTR plus one project. If I run this again with my test script, you see this test script builds a new virtual environment, clears everything out, downloads everything, gets the right dependencies here. You see here Flask and so on. And then what it also does and you see here Flask, it picked up the right version of Flask. There's also, like, other dependencies, like setup tools and work check also got picked up as fixes. Some of those are declared. Some of them are tentative dependencies, and you see it also asks me to log in now because I ran what's also here in the script. Where's the test dot s h script? I also ran a gripe environment variable, like a gripe scan, which is a security scanner of the virtual environment. And then I verified which environments, which libraries are from Chainguard with the library's verify command. So the library's verify command here showed me that all of those things are built Chainguard, MarkupSafe, in this case, snuck in from elsewhere or there's something else going on there. But you also saw that gripe work tech has no high security issues because we picked up a remediated version. So that's how you can build, you can scan, and then you can also verify libraries. I can show you some other verification here as well if you go dot dot slash Chainguard artifacts. So, for example, I can go chain CTL libraries, verify flask. I have just a flask wheel here locally, and I can verify, oh, that one is from Chainguard, or I can go same one for a common slang, for example. Here, this is a bit more common use case would be a Java one because the Java dependencies are automatically inserted in the Maven repository cache. So, you have those files locally as they stand, and you can verify them. So, you can say, hey, is that from Chainguard? If you just look at that char, you can't tell if it's from Chainguard or not, right? So, we need to have a tool to verify that ChainCityLibrariesVerify does that. And you see here, in this case, this is a version from Chainguard. It basically goes out to our servers, compares checksums and looks at metadata and so on to completely check that. And also, there's a cosign check, so it does a signature check of it as well. On the Python project, I also can show you the UV example here. Where are we? The virtual environment here has the libraries in it. And you can, for example, see here, there's the SBOM information right in here. And if I look at the SPDX for this and scroll up, you see that similar to how I showed you earlier, the information for the library in the Java ecosystem in the SPDX file, well, here's the Python one. In Python, it ends up within this project's virtual environment, and you can look at the SPDX file right here. So very useful to check this out as well. Now, so this was a whirlwind of demos. Let's see where we're at. So what if a library is not found, right? So I showed you direct access. What if a library isn't found? Well, Chainguard repository is our approach to prevent this problem for you, because what we do is we also provide you artifacts from the public repositories, specifically from the NetNPM registry. But what we do is we do not serve you malware. So we check the software that's in the public repository, filter it out, and only give you the goods, so to speak. And those is only for the ones we weren't able to build just yet. So that way you can have full coverage, then, that's where we're at. ChainGuard repository allows you to do that. It also adds a global cool down period. So we allow the community to find those malwares, and we can also block them ourselves then. So you get one single trusted access point for all your packages you needed without having to have a repository manager, which is also something you can do. Obviously, here, Chainguard repository is configured in Sono type Nexus, can look like that. I've demoed this in other learning labs in the past. All these tools seamlessly work with Chainguard repositories, and also Chainguard repository because we use the same format. So all you need to know, though, is have a tool like Nexus repository that allows you to configure another upstream proxy repository with credentials, and then you can consume all our libraries, but also manage your private packages on your enterprise potentially. Just like with Chainguard repository, you have one central access point. Obviously, Chainguard repository is a great starting point for that, specifically if you don't have a repository manager yet or don't want to use one. Verification, I already showed you chain CTL libraries verify some file. You can also bulk that up and do a whole coverage archives and so on. That allows you to detect which ones do you still need to worry about replacing, essentially. And that was it. So thank you for joining me today. I went a bit over because I had too much exciting material to show you. That's okay, though. And that's a trend we have, by the way. In terms of question, I saw a question from Trevor, and I answered that already. Couple of things I want to tell you about. I mentioned the TriviaTAC and Light LLM related aspects that are still spreading. There is a session coming up on the April 2, so very soon, or next week, in fact. And it's not an April joke because it's on the April 2. Dan and Reid will talk to you about what exactly happened, what is going on in the ecosystem there. I saw a message earlier on LinkedIn where someone's saying like 19,000,000 secrets were stolen across lots of LLM users. So, this is not the end of it because those credentials will be used for further attacks. So, stay tuned and hold on your horses, maybe get to Tinker libraries, so you can stay safe and secure. But do join Dan and Reid. It's super interesting to learn about how these attacks happen and how creative the attackers essentially are, unfortunately also how successful the sometimes are. Then a week later, we have a session of new product announcements. Also check out the blog that we have at chaincode.dev, where the announcements are available from our assemble conference, but this is going to go and be a deep dive and show you more details how we create these new features as well with our Drift S AF and other agentic approaches, and just what's coming up for you in the future. There's lots of cool stuff that we are going to be shipping and working on. And then, last but definitely not least, a little bit further out, Erica is joining me today as well in the background, has been helping. So thank you so much for that, Erica. And next time, it's time for me to pay back because you're going to do a great learning lab about securing a CICD pipelines with Chainguard. There's a whole bunch of things involved. Libraries is one of them, packages, containers, Helm charts. There's a lot of products from Chainguard that are really, really useful and secure for your CICD pipeline. And Erica knows all about it and is going to show you, and that's going to be awesome. So I will be on the background on that one because I wanna learn from Erica as well. So I'm looking forward to that. And with that, I'm wrapping it up. Only a few minutes over. Thank you so much for joining me. It's been great, and I look forward to hear from you. I think that's it. So, again, thank you so much. I will see you out there in one of