Name: What’s New: Product Announcements, Feature Releases, and Roadmap
Uploaded: 2026-04-09T18:16:15.733Z
Duration: 49 min 47 s
Description: What’s New: Product Announcements, Feature Releases, and Roadmap

Transcript for "What’s New: Product Announcements, Feature Releases, and Roadmap": Hello, everyone. Welcome to the What's New webinar, at Chainguard. We are so excited to have you all with us. By way of intro, I am Ross Gordon. I'm on the product marketing team here at Chainguard, and we have a whole host of folks here, up on upcoming on stage today, to walk through all of the amazing innovations that we have at Chainguard and what we've recently released and what's coming soon over the next quarter or two. So everyone will introduce themselves as they come up here, but excited to walk you through what's coming from Chainguard. So our agenda today, gonna talk a little bit about the tension that we're seeing in engineering today. If you have been following the news, it's been a busy two, three weeks across cybersecurity, across AI. So we'll talk a little bit about that tension. We had our Assemble conference about two, three weeks ago at this point. And if you missed it, we'll do a quick recap of everything we launched there. And then we'll get into our core product areas, Chainguard containers, Chainguard libraries, and our platform. So let's jump in to the tension that we're seeing today in the industry. So on one hand, it's really never been more exciting to be an engineer, to be in, be in tech at large. In many ways, all of the value from AI is starting to come to its head. We we see it through stats being shared, across the news news organizations and from what individual startups are saying themselves, is is happening inside their own repos. For example, about 25% of Y Combinator winter twenty twenty five startups said nearly all their code is now being AI generated. And effectively, the bottleneck no longer is just writing code. It's really how fast humans can absorb the change, and that's from the CTO of Axios, Dan Cox. On the flip side, it's, also never been riskier and scarier to be in the industry. Claude discovered 500, high severity zero day CVEs, and that was just a precursor to what we learned this week with Claude Mythos coming out or being in early preview. And there's been a host of attacks over the last six months. Shai Hallou from last year, even in the last three weeks. We saw the Trivia attack, GlideLlm, Axios. They've been serious in how it's caused everyone to rethink their own security posture. And speaking of that Trivia attack, I wanted to just chat through at a very high level, what we saw happen, first from HackerBot Claw getting into the Trivia repo and from there, exposing and exfiltrating all of Trivia's keys, which caused a malicious version of a Trivia container and Trivia actions to be spread across the industry. From there, the blast radius started to grow. So canister worm was was released with those, exfiltrated keys, which impacted around a 140 different MPM packages, including from major maintainers like Emil Group and OpenGov. We saw check marks. Their Kix scanner also was exploited, and and shipped malicious action versions. And then finally, LightLlm and Telenix from the Python library side of the world having, you know, nearly a 100,000,000 downloads a month between the both of them, and just speaks to the value of being secured by default. So all of this basically suggests the scan and patch era of security is over, especially when you can find, vulnerabilities very quickly. You have to start, with a secure base, and and starting secure by default is really the only way to guard your software supply chain. Super excited to be here with the group today to walk through the entire Chainguard platform. This looks a lot different than if you've been following Chainguard for a while. We've grown our product SKU catalog quite a bit from just containers, and libraries and VMs. Recently, and we'll walk through this in a moment, we added OS packages, actions, and agent skills to the broader Chainguard repository, and we'll walk through what that means. Of course, all of these brand new artifacts are powered by the Chainguard factory, which is powered by our Driftless AF, framework as well as everything being built with SolSoft three compliance, so in a totally isolated, and a and a hermetically sealed environment. And all of this ultimately helps you have a trusted open source software stack, for a continuously secure by default artifacts. So excited to walk through it. So all of our artifacts effectively are are shifting your supply chain posture from being really reactive to proactive, and all of the, features and new releases that we'll be chatting about today kinda fall into one of three buckets. The first is just making it really easy to be secure by default. It's going to be increasingly important to be secure by default in a world where, you know, vulnerabilities are discovered by the day and supply chain attacks can, can penetrate whether or not there's a CVE at all. Number two is protecting more of the customer software development life cycle. So what we wanna be able to do is ensure that what not just your containers are protected, but your libraries are, your CICD workflows are, and your agent skills, your OS packages, your VMs. You wanna cover more of that stack so that you can be secure by default. And then finally, you wanna just increase the velocity, that you're able to be secure by default with Chainguard AI. And we have Sam on the team here to walk through, what some of those innovations look like on the Chainguard AI side. So let's jump into a quick recap of what we saw at assemble at at Assemble. First is the Chaingard repository. So this is the place that stores all of our artifacts, and what we're basically doing here is creating a single endpoint that is, across all of, your your artifacts. So we're starting first and foremost with JavaScript. So what that means is there's policies attached to that repository, meaning, in the case of JavaScript, you can cool down. You can have a cool a protected fallback to npm via cooldown. So you'd have seven days and a flexible amount coming soon. That allows you to, have a, protected environment with both Chainguard libraries being secured by default with, JavaScript, coming with with, NPM coming soon after. And then over time, we're adding all of our artifacts to this, so you can add policies such as, CVE blocking, such as license enforcement, such as long term service enforcement, making sure that all of the artifacts that you're consuming from Chainguard meet the compliance and security standards of your organization. So that's that's Chainguard repository, and we'll get into the details of what's what's coming and what's coming soon there, later on in in in today's webinar. And then next is we wanted to dig into one of our first new artifacts, Chainguard actions. So these are built from source CICD actions or workflows, that are continuously secured over a specific secure rule book that we're that we're hardening against. And every action ships with the, you know, expected provenance that you'd expect, the SBOMs that you'd expect, and a list of all the hardening steps that we're taking. So on an example as an example here, we actually, ingested the official Cloud Code action, from Anthropic and found that there was a script injection vulnerability. And then rather than just informing that the script injection exists, what we did is we actually fixed it and we're publishing it to our hardening catalog. This is in enclosed beta right now. If you're interested, you can, go to any of the docs on the tab here and, get, sign up to join the actions beta. With that, we'll pass it over to Sam to chat through agent skills. Awesome. Thanks a bunch, Ross. So Ross just talked a little bit about, actions and how we're thinking about new artifacts to cover the CI pipeline. But we're also thinking about autonomous agents working across the software development life cycle and the instruction files they run called skills. Now I'm sure for a lot of us, this is kinda old hat, but Chainguard agent skills is all about securing these instruction files that often have these super broad remits, like controlling shell access, tool permissions, file systems, and network requests. And so to protect organizations from these skill based attacks that are quite rampant and are continuing to pop up and propagate, we, have created a, an evolving, security and quality rule set that we actually measure each of these, agent skills against, and we publish them with a full audit trail. So this is another good example just like actions is and, frankly, just like containers or libraries about us extending our, Chainguard factory and our ability to continuously maintain across new and different artifacts specifically in the AI era. Now we also introduced a new way to consume zero CVE packages that comprise our container images, and we're calling that Chainguard OS packages. So every catalog customer today has access to all of our images and our packages, all 30,000 of them. But we recognize that there are teams out there that really wanna do the image building on their side of the house. This could be because they're heavily regulated or they just love that level of control and governance. But for those teams that are sort of a DIY plus shop, that doesn't mean that they have to be in the business of maintaining and rebuilding packages themselves. We can offload that toil and burn for them while still giving them that modicum of control that they want as it pertains to the image building. And so for those organizations that are standardizing on Chainguard images, a piece of feedback that we've heard pretty consistently is, gosh. We really love what you're doing for all this open source, but what about my commercial software? Is there any way that you can cover any of that? And up until now, that answer has unfortunately been no. But at Assemble, we introduced Chainguard commercial builds. And the idea here is that we partner with a number of these ISVs to package their commercial software. We take their binaries, and we're actually just rebuilding the open source, system level packages underneath, their own custom code. And so what our end customers get is zero CVE, hardened, secure, continuously rebuilt commercial software via container images. And so you can see on the screen today the number of, partners that we have. We expect this to continue to grow. If there's, some commercial software that you're adopting today and that you really would love to see be see added to this, please reach out to us. We'd love to hear more and continue to build out this ecosystem. Now lastly, I wanted to talk a little bit a little bit about adoption here. So whether you're, using commercial, images from us or kind of building your software on top of our base images, we recognize just how critical it is to, make sure that you're using all the Chainguard software that you're you're purchasing. At Assemble, we introduced the Guardant. And this is an agentic extension of the Chainguard factory. And the first use case that we're really focusing on is helping teams migrate to container images and packages. And it's pretty unique how the Gartner does this. It runs inside your organization's environment, and it understands the context of your Dockerfile and the artifacts that your organization uses. And then it takes that, that context and converts your Dockerfile line by line, testing it as it goes, to make sure that what it's producing is a stable, accurate version that uses Chainguard base images and packages. And we really see the Gartner, being a game changer for so many of our customers today because it allow everyone from developers to platform teams to abstract a lot of the hurdles that come with adopting secure by design, open source software. And we're pretty excited or I'm very excited. We're very fortunate today because, my colleague, the better Sam, is actually gonna be on here in a minute to demo the Gardener. So I will go ahead and invite her on, and I need to stop screen share, which is somewhere on the screen. I apologize, folks. We're doing it live. Oh, somebody did it for me. Awesome. Sam, I'll I'll have you come on. I'll hop off. Alright. Thank you, Sam. Hi, Ron. Sam Morris here, one of the solutions engineer here at Chainguard. I'm gonna go ahead and share my screen if I can so I can demonstrate a little bit more about the Gardener. Alright. Cool. Again, Sam Morris here demoing the Gardener for you. The Gardener essentially goes through and converts your Docker files to use chain guard based images, but it does even more than that. Instead of just changing the front line of a Docker file, it goes through and updates your package definitions using your, APK add instead of an app get update, and also builds the image for you to ensure that it builds successfully and runs functionally. So I'll go ahead and show converting a simple Docker file here. This one is in Ubuntu base. It does the AppGet update, install, curl, git, and Python. Sets the working directory, copies over files into the working directory, and then sets the command. So let's go ahead and run this. The command to interact with the Gardener is through Chainctl. So this assumes that you have ChainCTL, which is our command line tool already installed and updated to the newest version, accept our terms of use. And then you just have to do ChainCTL agent Dockerfile. In this case, build is the command to migrate. Just do a one to one migration. You pass in your Dockerfile name. This case is just Dockerfile. And the tag information to you because it's going to build an image and then run it as a container to do some tests. You also have to provide your group ID, which you can find in your Chainguard console, or you can get with ChainzTl as well. So enter and see it run. So what this is doing is going layer by layer, and each line of a Dockerfile corresponds to a layer of an image and is building that layer, testing it, continuing on, and converting the next layer. This way, we can make sure that if there's a failure, it's caught early, and the agent can kind of reconcile those failures. So for the sake of time, I'm gonna go and look at a migrated example. So I'll do, like, a side by side view, to show what this looks like. This is a pretty simple Dockerfile. Most enterprises will have more complex ones, but, again, just wanna show a simple example. It goes ahead and converts it to a chain guard base image, switches the the packages to do an APK add, and then keeps everything else the same. So there's no invasive changes added with the build command. Alright. I wanna show another command as well that I think will be useful to you all. It doesn't just do the migration, but it does optimization of your Dockerfile. So there's many optimizations that you can apply. Some key ones are multistage, so converting your Dockerfile to use multiple stages, including our dev variant, which includes the the shell and the package manager, to a smaller runtime variant at the end. It reorders instructions to improve your your layers and your build cache usage, and it also can append instructions too. For example, if you have multiple run commands, it'll append it into one, creating one layer instead of multiple in your build, which will make your image smaller and have a a generally faster push and pull and build time and all that good stuff. So let's go ahead and run the optimize command as well. Again, it's the exact same thing as before, changectl agent Dockerfile, but optimize instead of build. So if I run this on a migrated Dockerfile, it'll go ahead and start the optimization. What's great too is since this is an agent kind of running in the background doing all these things, you can go ahead, walk away, grab a cup of coffee as this runs, or you can watch it interact as well. So if you hit tab, you can see what it's doing line by line, layer by layer. And it'll suggest, various optimizations and give you a optimized Docker file that you can do your build with. This is introducing more invasive changes again, so you might want to check what it's suggesting as it's not as it might reorder instructions and remove duplicates and things like that. But it gives really good guidance as to why it's suggesting those optimizations. So we'll show an example of the optimized version on the side here. On the side. Cool. So this is an example. In this case, this image, if y'all are looking closely at what it's doing, it's really just creating a Python based image for you. So it it's able to reconcile that this is a Python image. So it pulls in latest dev as the biller image and then the smaller runtime variant, the non dev variant that is from Chainguard directly. It also converted it to the multistage as well, so, applied the multistage optimizer. You can pass these in as flags if you wanna apply specific ones. Otherwise, it'll carte blanche, do all the optimization possible. Great. So I believe that's it for the demo, but I will pass it back to Sam Katzen, the other Sam. Awesome. Thank you so much, Sam. I'm just gonna bring back up our slides here. And, it. So, that was actually a really great job by Sam illustrating how the Gardener works, and it enables some of the migration that we hear a lot of feedback on about how critical it is. This is also a really great segue to talk about Chainguard containers. And, we'll start with some of the things that we've just released to our customers and then get into, a lot of what's what's coming next. My one caveat to all this is that this isn't all the things that we've released recently. We only have so much time on these calls, and so we kinda just try to, keep it keep it as streamlined as possible. Please, if there's anything that you didn't hear from us today and that you kinda feel like is still outstanding that you'd love to hear more about, reach out to your account team or a a representative at Chainguard, and we'll absolutely fill in the blanks for you and get in touch. And so, first, I wanna start with policy gates. Earlier, we heard Ross introduced Chainguard repository and some of the initial policy engine work there that's happening for libraries. Well, at the same time, we're also building out policies for containers as well, enabling teams to enforce things like, LTS only versions, blocking end of life images, and limiting languages to preapproved versions. In the future, this is something that we're gonna be doing even more on, and we'll talk about it later today, adding configurable policies for a particular open source licensing that you wanna only use. This is available today via ChainCTL in beta, but we're planning to centralize and unify all of this via the Chainguard repository in the future, and so more coming there. For custom assembly, there's a number of new meaningful upgrades that we just recently introduced. The first is actually around custom certificate management, which we know we've gotten a ton of feedback from all of you on. With custom CA certs, it's pretty straightforward. You declare certificates once in your image, configuration, and Chainguard handles placement and rebuilds automatically. This removes a ton of toil. Available to available today is predefined SERP bundles for AWS RDS and DOD PKI, and we've actually increased the size limits here for up to 50 kVs. If that doesn't work for you, please reach out. I'm sure we can be flexible in that capacity. I also wanted to quickly touch on private APK repos. This direct private endpoint, actually enables access to the full catalog of 30,000 plus packages if you're a catalog customer today. If you're not, if you're per image, it'll enable you to access all the different packages that are part of your images as well as some, OS level packages as well. And, what this basically means is that it gives you a secure endpoint to pull from, for custom assembly. It also gives you a chance to, enable just a ton more customization using custom assembly. We also unveiled some major updates to our FIPS modules relatively recently. We announced our own, OpenSSL 3.414 dash three module. This is a big deal for us, and it's a big deal for all of you because it means that we can, directly remediate inboundary vulnerabilities for customers without waiting on any third party. And this is something that, no other provider can really do today. This validated module not only enables what I just described, but it completes everything, required to align with NIST's guidance through 2030. Now I'm gonna go ahead and turn things over to to Tazeen, my colleague, who'll talk a little bit about what we've been up to with Helm charts. Tazeen? Awesome. Thank you, Sam. And, hey, everyone. My name is Tazin Progga. I am a product manager here at Chainguard. So you just heard of some of the powerful new additions that we've made to our Chainguard containers product. I'm going to round out that list by telling you about one more, which is our recently launched community Helm charts offering. So Helm is a core deployment strategy for many modern, software development organizations. And ever since we launched our IAM guarded Helm Charts last year, we've gotten so many signals, from customers telling us that they are using upstream community Helm charts to deploy their Chainguard images, but it's a friction prone experience for them for a variety of reasons. First of all, there's no trusted standardized source, where they can grab Helm charts for all of their hardened images needs. Then there's operational toil involved when customers have to figure out which charts to pull down from the Internet, verify if those originated from official sources, and then hand edit the values files for each of those charts in order to install Chainguard images. And so it is precisely for those reasons, to help you overcome those challenges that we decided to expand our Helm catalog by repackaging official upstream Helm charts as signed and maintained OCI artifacts available from the same trusted Chainguard registry where you get your hardened Chainguard images. Now our charts come preconfigured to use our secure by default images, and they're thoroughly tested by Chainguard because we deploy them in representative environments and carefully validate their core functionality before every release. We launched with 25, community home charts and are almost at 100 already. In fact, we have an ambitious goal to scale coverage and grow the community charts catalog, to at least 300 charts by the end of this year, which, of course, is going to be made possible thanks to our powerful Chainguard factory. Now with that, let me give you a quick tour of these community charts. And just give me a quick second here to figure out the controls, and how to switch to video. Alright. Let's give you a quick tour of our new community Helm charts from our Chainguard console platform. So as you can see here, I am on console.chainguard.dev, and I have logged in. So this is for anybody who has a Chainguard account. Once I've logged in, I can find the Helm Chart section from the left hand navigation bar. And then, when I click into it, I have, essentially two split views, for Helm Chart. One is my organization view. So as you can see, there are two Helm Charts provisioned to my org already. These are the Postgres and RabbitMQ Helm chart. Alternatively, you can also navigate over to the catalog view, and this is where you can browse, all of the Helm charts, that are currently available from Chainguard. So as you can see, as of today, there are a 134 Helm charts. And, this includes not just our recently launched community Helm charts, but also our IAM guarded health charts. And the way that we, enable users to distinguish between the two currently is, the IAM guarded health charts all come with this, shield icon. As you can see next to this airflow chart, the API six chart, also Argo workflows, they all have the shield icon next to them, and these are the IIM guarded variants. Anything that does not have the shield icon is, is essentially the community repackaged variant of the chart. So in this particular case, this airflow health chart is the community chart variant. So once I click into it, the experience should be fairly similar to what you're used to with other Helm chart repositories like artifact hub. So pretty standard. The first tab here is the overview or, like, the read me, a quick introduction, of this Helm chart. You have the chart versions to see, like, exactly which versions are available from Chainguard, the default values, chart metadata. And then lastly, you can also see exactly which images are deployed by this by this airflow home chart. Yeah. And, yeah, if you if if there's anything that you like here from this list, anything that you want to start trialing or you want to use, in your organization, you have the ability to request the chart right from console. So this should you can select whichever chart you need, and that should help create a support ticket for you so that our go to market teams can reach out and, help you get sorted. If you did not have a Chainguard console account, no worries. You can still see, the relevant information about these charts from our, public directory. So that is images.chainguard.dev. So once you're here, you can scroll down, find the Helm Chart section. If you click on it here, you can see all the Helm charts that are available. Again, similar to the console, you're able to distinguish between what is a community chart and what is an I'm guarded chart via this shield icon. And once you click in, again, you have a similar experience to the console where you're able to see the MeetMe chart versions, more metadata about the chart and the dependent images. Alright. I hope you found this useful. Alright. I hope that was informative. If you're interested in trying out any of our charts or you want to learn more about anything, please reach out to our team, via your team guard reps, and they'll get you sorted. So let's now hop into what is coming up next in containers land. Alright. So we'll keep the momentum going with Helm charts. I've already mentioned how a key focus area, for this year is to scale up coverage of our charts, and ensure it's easy for customers to be able to adopt and get value out of these charts with things like more in product self servicing and general usability improvements. We'll also eventually, start making these charts more aligned to our secure by default ethos, similar to what we do with our secure images today. So some foundational improvements, there will be around ensuring our charts follow, common Helm best practices as much as possible, for instance, by minimizing the use of root users wherever it's feasible to do so without impacting chart functionality, and then also integrating with, common Helm linting tools to verify the quality of our charts, independently. If you have ideas on what you'd like to see, from hardened help charts from Chainguard, I would love to hear from you. So definitely get in touch via your account teams. Alright. And, we're also working on some exciting new integration opportunities with our scanner and CNAP partners, which would really supercharge the value that you are able to get from those tools. We're developing a recommendation engine that can be embedded in our partner solutions to identify artifacts, in customer environments that can be easily replaced by secure, by default, Chainguard equivalents and show the exact CVE, reduction benefits that can be achieved by migrating. And as I said, this is essentially supercharging your scanners from being detection and alerting tools to a more powerful remediation oriented workflow. Okay. And with that, I will now be turning things over to Ross to talk to you about JingGuard libraries. Ross, please take it away. Awesome. Thank you, Tazin. So that's our containers business. Excited with all the amazing improvements that Sam and Tazin and both Sams actually just walked through. Let's get into Chainguard libraries. We've released a bunch over the last few months and excited to share what everyone wants to know. Our coverage is growing quite a bit across our Python, Java, and JavaScript ecosystems. We now have over half a million different versions, for Python, which is super exciting. This includes some really widely requested AI libraries like, PyTorch and Torchaudio. So super excited about that. And then across our current Python customers, we have about 90% 95%, average coverage there, and that continues to grow as we continue to get all of the power we can out of the Chainguard factory. On the Java side, we've passed over a million different versions. And for JavaScript, we're at 80,000, which accounts for almost all of the top 500 npm high impact dependencies. And for those unfamiliar, the npm high impact is a list is a broader list of dependencies that either are, depended on by 500 other dependencies or are downloaded, in a in a in a in a top 500 for download. So excited about, all the progress we're making on the coverage side of the house. And with this coverage and given all of the, intense attacks that we've just walked through earlier in in the webinar today, we're actually offering libraries for free until June 30. So, again, in light of everything going on, we wanna make sure that everyone is protected, as best they can. So you have full access to our three ecosystems until June 30. That's about three months. And as you can see, team PCP, they're the threat actors on the TriviaTac, LineLLM, Telenex. They basically fired their shots. Right? It's the year of the supply chain, and you guys are gonna be busy for a long, long time. That is if unless you're using Chainguard because none of our library's customers were impacted, as a result of any of the attacks, including Axios. So, if you're interested, you can just sign up, to for a console access, if you don't already have access to the console, and you can entitle yourself to to libraries. And if you have any questions, our team is more than happy to, help you get set up. From there, we've also launched ecosit libraries ecosystem console browsing. So, you can go into the broader console and just as you have for containers, you can now browse all of the different, libraries that exist across Python, Java, and JavaScript, and for Python especially. Since we're remediating a handful of c b CVEs in that ecosystem, you can see which, libraries have a remediated fix and can can browse to your liking there. So Lots of improvements on the overall experience there, coming soon. As mentioned, want to hit it again, but we have the built in cooldown for JavaScript libraries in general. That cooldown is going to a protected fallback for npm. So what that means is if you are using our JavaScript endpoint, that means if we have built it, you get the chain guard version. And if we have not quite built it yet, then you will get the upstream version that has passed the seven day cooldown. Ultimately, we're making sure that you're protected if you are as we build as as best you can, as we build more libraries, from source, your protection automatically improves to be chain guard built, secure by default. And we plan on, bringing more policies and more ecosystems that Angela will talk through in in just a moment. And with that, I'll let why don't I bring up Angela to walk through a demo of the Chainguard repository specifically for JavaScript? And and that'll be it for me until, the q and a. So excited to bring Angela up on stage. Alright. Hey, everyone. I am Angela. I'm on the product team here at Chainguard. I'm gonna share my screen, and I'm gonna go through some quick demos, around our console and the Chainguard repository with the upstream repo that Ross just walked through. So let me see how to share my screen. One second. I'm going to start with the console here. As Ross mentioned, we recently rolled out console browsing for libraries across our ecosystems, Python, Java, and JavaScript. So you can see all the libraries that we've built from source. This is showing what Python libraries we have available today. You can also filter in to see which ones we've remediated CVEs for. So as an example, I can search for one of the common ones that comes up, URL of three. Can click into that, and we can filter in to see remediated CVEs. You can click into those specific versions with, anything with that CGR suffix where we've back ported those CVE fixes and see more details, around that. Going back to the browsing pages, we can see all the Java libraries here, can search for any library we've built in Java as well as JavaScript. And then the one new thing that we've recently launched within JavaScript is, the Chainguard repository, which enables you lets you basically enable the upstream repository here. So you can see in my organization, I have the upstream repository enabled. What that means is that for anything that Chainguard hasn't built yet, we provide that built in fallback to the MPM repo. And on top of that, we provide a cooldown period as well as malware detection, before we're serving any of those libraries. So this is the browsing experience. I'm gonna now switch over to my Visual Studio. One second. Alright. So I'm gonna do a quick demo within the terminal here and show you what using JavaScript libraries within our Chainguard repository looks like and how easy it is to get started today. I have a really simple NPM application that's just installing a few dependencies here. And within this app, I have a configuration file. This is the NPM RC file. Right now, I have two entries. So, we're gonna first pull from the public MPM registry, which doesn't provide any of that malware protection, that Chainguard does. And then later, I'll just switch over to start pulling from, our Chainguard libraries, using the repository for JavaScript. So what I'm gonna do first is I'm gonna run an NPM install. This is just gonna install directly from the public NPM registry. And to just check that real quick, I can I'm gonna run this NPM view command and just check for one of the packages that I've just installed here. And if you look closely, you'll see that this tarball is coming from the npmjs.org registry. So works as expected. Now what I'm gonna do is start switching over to point to Chainguard libraries. All I need to do here is basically update that registry URL to start to point to the Chainguard repository. Here I have a pointer to the Chainguard repository with the upstream repo enabled. So gonna save that. I have my authentication set up here. And so I'm gonna first clear my cache real quick, and then I'm gonna run the same npm install command. This time, it's going to pull libraries from the Chainguard repository, and we should see that there's no changes needed to to the application itself. It'll just automatically, resolve to Chainguard libraries. Alright. So it looks like that installed successfully. And I'll just show you the difference with kind of verifying that these libraries are getting pulled down from, Chainguard. So here, you'll see the tarball is being pulled from libraries.cgr.dev. In addition, you'll also be able to see we have attestations and provenance for all those libraries that we build from source. And then I'll just show an one more example of one of these packages that we haven't yet built. So I'm gonna view more details on that mammoth package here. And you'll see the difference here is that you can see the JavaScript dash upstream repository as part of that URL. So that kinda shows that this this package is coming from the upstream repository with the cooldown and, malware detection in place. Alright. So that is the demo. I'm gonna stop sharing screen, and let's go back to the slide deck. Alright. So I'm gonna jump into now around what's next with coming up for libraries. We're working on a lot of new exciting stuff over the next couple of months, so let's let's dive in. Okay. So I just showed what that upstream repository setup looks like with JavaScript. That's available today. Up next, we're gonna be expanding this to Python. So similarly to that JavaScript experience, we'll have a protected fallback, to the PyPI repo for our Python libraries, along with that same cooldown and malware flagging capability. We've heard this as a top, and ask from a lot of our customers, in order to make that onboarding experience a lot more seamless for you. Cool. Another thing that we're working on in the library's land is improving our overall experience. And so one of these one of the things that we are gonna be building out is a coverage reporting and, request experience within our console interface. The idea here is that we are gonna be surfacing, the current live as well as historical coverage metrics that around which libraries we've built over time, so that you can have that visibility, for your organization. As well in addition, we're also building out a request workflow within that within the console so that you can request new libraries and be able to track them, in one kind of centralized dashboard, that will kind of be expanding across all of our artifacts. So this is something we're excited to be, implementing so that you have that visibility across your organization around your security posture and being able to track, what libraries we're building and which ones we've covered, over time. Alright. Up next, we are also working on Mac support for Python libraries. This is extending our current Python libraries so that any of those native packages are available and supported on Mac developer machines. So this, the big sort of, you know, impact of this is being able to protect against your developer machines, in addition to what's running in production, on on Linux environments. Up next, another exciting one. So we are expanding CV remediation to our Java libraries. We I showed you what that looks like in the console with Python today. We are expanding this to Java, so essentially backporting CV patches to older versions of Java libraries, and we're starting with the Spring Boot ecosystem. That's one of the ones we've heard a lot of requests from across you all, and we have plans to expand into some of those other critical, ecosystems within Java too. We know that, you know, pinning two versions and, that have CVEs and the toil that that is introduced with upgrading these versions, causes a lot of headache for your engineering and security teams. And so the focus of this is to solve that solve those problems. And then the last one on the list here for libraries, another really exciting thing we're starting on is Go libraries. So we're adding Go to our catalog of libraries, ecosystems, on top of what we have today with Java, Python, and JavaScript. The main focus for Go is gonna be around remediating CVEs across Go modules, to protect you from known known vulnerabilities. We've heard from some of some talking to, you all that, you know, sometimes there's just one or two vulnerabilities that end up, you know, impacting multiple Go services, which results in a lot of that engineering toil. So, the goal here is really reducing that toil and, reducing your known vulnerability risk with Go. Alright. So that's that's coming up with Chainguard libraries. I'm gonna hand it off to Sam to talk a bit more about our platform, investments. Awesome. Thank you so much, Angela. And, thank you all for tuning in. I'll get through this relatively quickly so we can open up time for questions. Let's start with what we recently released here. Wanna give a quick shout out to the Chainguard activity center. We know that as Chainguard becomes more of a center of gravity for all of your open source and software development and supply chain needs, you really need to be, aware of what's going on within Chainguard, whether it's life cycle issues with, container images or breaking changes. And so we wanted to make sure that we were able to convey that in a more unified way, which is exactly what the activity center is. This came out just about a week or so ago. So this is relatively hot off the presses. Not only is there an in console experience, which you can see on screen here, but it also integrates into your tooling, and workflow. So that could be Slack, that could be email, that could be Teams, also via API, and delivers updates on all the things that I just called out. So breaking changes, image life cycle updates, any product or entitlement updates that you might have. So we see this as a pretty big step in enabling more seamless and real time awareness for you and all of your users within the Chainguard console. In terms of what's coming next down the pipe, the first thing I wanna call out here was, a v two of our API. And we're building this out to be more robust and more multifaceted to fit with more enterprise use cases. So covering more IAM use cases and permissions, providing programmatic finer grained controls, adding more endpoints and bolstering the reliability so that you can automate more of your workflows that involve Chainguard across your different environments. So this will be beta in h one. And you heard a few different things about this today. I just wanna call back to it one more time. The idea of a new policy control via the Chainguard, repository. So this will be everything from customizing cool down periods and overrides for urgent CVE fixes, license policy that I called out before, CVE control policies to block versions with critical or high severity CVEs. All this will be available across the console and API and, CLI, interfaces. And so, again, the intent here is to make sure that it is very easy for, you to manage all the different artifacts that you're using from Chainguard. As we expand across all these different use cases, all these different surface areas, we really wanna make sure that you have, again, a centralized, unified spot to manage all of it and to have that level of control. So, that's the end of our content. I'm really excited to bring everybody back up on stage here to take any questions and answers. Well, you have questions, we have answers. We've been, taking on a lot of them in the chat. I guess I'll just open it up to anybody who wants to share any others that we can address live here. Ross is back. Maybe a couple other folks can come back. My my last plug for you is at the very end of this, when we end this thing, there will be a survey that you can take to to basically grade our performance here. And, feedback is a gift as far as we're concerned. So let us know anything else you think about today's content, anything else you want us to add or include. And in the meantime, if there are any questions, we're happy to take them. As I look through the chat, there are a couple that we answered along the way here. I know there are some questions about CICD actions and where we'd be expanding to. I think Ross addressed this and called out GitHub actions first. Ross, anything you wanna add there? Just if there's other ecosystems that you'd like to see from us, feel free to either ping me or drop that as a support ticket. We're happy to prioritize based off customer demands and and and needs. So, starting with GitHub for now, but, what's next is totally what's next. There it is. And, there was another question around the Gartner that I wanted to call out, whether the from statement could be, modified to be for a pull through proxy. This is a great use case and something that we really do see all the time across our existing install base. And so, we're in beta right now. We will absolutely be addressing this. I can't guarantee as to when it will be addressed, but one of the benefits here with the Gartner is that because it runs inside of your environment, it should have that context and be able to make that modification. It's it's a a real boom that this is such a smart tool and can do all these modifications on the fly. So we expect that to be something that we'll be able to deliver on. Tazin, did you wanna address that question about Helm and, the Shield icon? I can repeat what I shared in chat. Yeah. I hear you. The icon way, it's definitely not ideal to distinguish between, the iron guarded charts and the community community charts in the UI today. Icons are really easy to miss. We we we know that. We have some upcoming changes planned that's going to do split views, add in a little bit of, like, filtering as well to be able to distinguish between the two sets of charts more easily. Awesome. I don't know if there's anything else that's outstanding that we did not address, or if there's anything else that's come in. I guess my, my last plug that goes beyond the survey callout is just that we consider this an ongoing two way dialogue. So if there's something that you didn't see addressed today that you want us to address, or any feedback that you have for us or for the team, we are always open to it. The goal is to iterate and and, grow together. So we appreciate everybody joining and being part of this for us and being along for the journey. It's been a a busy few months. We expect the next few to be just as busy. So, looking forward to making these better in the future. And have a good rest of your day. Awesome. Thank you all.