Name: Whats New Product Announcement And Releases
Uploaded: 2025-11-14T20:28:33.892Z
Duration: 56 min 38 s
Description: Whats New Product Announcement And Releases

Transcript for "Whats New Product Announcement And Releases": Awesome. Well, we'll go ahead and get things started. I'm sure more folks will join as we roll along here, and that is a okay. Well, this is our what's new, update on everything that's new and coming next from ChangGuard. We do these roughly on a quarterly cadence. My name is Sam Katzen. I'm from the product marketing team here at Changar. And, like I said, if you want, go ahead and drop in where you're coming from today into the chat. We'd love to see where we are all joining from. And in terms of who we're gonna have on today's discussion, I'm gonna be joined by, really, a dream team of colleagues from Chainguard on the product marketing side. We'll have Bria, Aditya, and Anoushka. And on our product management team, we have Mark, Tony, Tazeen, and Angela coming to us today. So we've got a lot of great stuff for you. And in terms of what we're gonna be covering, we're gonna start with some of the priorities that we hear from customers and organizations that we're talking to on a daily basis. We're gonna actually have a little bit of data and insights that we got from the last quarter that we'll share as well before diving into each of our core products in containers, libraries, and VMs. If you have any questions, please don't hesitate to throw them into the q and a as we're rolling along. We'll do our best to answer them as they come up. And then at the end, we will also be having a a q and a session. So if you wanna save any, that's a perfect time to do that. There will also be polls that are going on throughout the session for each of the product categories. And I'm told that for each one of those polls, to participate, you had a chance to win a gift card or a book of your choice. For all you readers out there, this is our way of celebrating the GA launch of Schengard pie libraries for Python, which you can hear more more about in the library section. Now before we get on to take each of the product updates, I did wanna dive a little bit into some some data that we gathered in the last four of here to talk about some of the driving forces that we see behind our customers and organizations development priorities and decisions. And, for anybody who was on here last quarter, you might remember me starting out with these four key outcomes that every organization has in some capacity. There may be different weightings for them for different parts of an organization's life cycle and maybe different terms that are used, but really comes down to these four things. Whether it's trying to operate more efficiently, reducing costs, trying to drive innovation faster, obviously, increasing revenue and reducing risk. In some capacity, everybody's trying to do one or more of these four things. And while each of us doing our jobs, ideally, we see the work that we're doing in these four outcomes. We can see how we're contributing to all of them. But often sort of in a force through the trees way, it becomes challenging to understand what exactly is making it easier for us to do that versus making it harder for us to do that. And we actually looked into some of these things this quarter. We introduced a survey of 1,200 software engineers and technology leaders that kinda touched on some of the takeaways around contributing to these outcomes, like how you, how different factors are helping to reduce cost in an organization or perhaps, help drive innovation faster. So I'd love to get into some of these. And the first major one that I wanted to share was just how frequently maintenance is taking center stage over innovation for for engineering teams. Nearly 80% of engineers point to code maintenance as a drain on their time, and they're spending just 16% of their weeks actually doing what they love, building features, building new things that differentiate the product. And I think that what this toil trap really highlights is this imbalance that exists between upkeep and creation, and that causes slower progress and ultimately ultimately less output for an organization. So maintenance, we can say, is slowing innovation, but what exactly is being maintained? Well, increasingly, that answer is that it's security that's being maintained. Combination of tech debt that two out of three engineers see frequently and passing a vulnerability resolution that 40% of engineers are spending significant time on. All that indicates that a lot of organizations still have a fairly reactive approach to securing their software development life cycle. Right? It's indicative of a world where soft for security is kind of external to engineering workflows. That becomes an obstacle that requires a ton of time consuming react work. So as organizations try are trying to reduce their risk, what they're ultimately doing is taking on more manual work that reduce that increases their costs rather than focusing on the meaningful things that make their engineering teams happy and also produces things that people are ultimately going to to spend money on. Right? And so this last point that I wanna bring up here is all around what it is what's happening when engineers are able to spend time on that valuable work. One of the real challenges that we've heard about is this idea of too much tooling, right, and the need to context switch. 88% of engineers called out the negative impact of context switching, and I'm sure if we think about it for a minute, each of us has an example from our own daily workflows where we have too much tooling we're moving between them and it's causing us to break a flow state. And the fact that 60% of engineers, acknowledge a lack of integrations between their tooling really makes this problem more severe. Right? So you have a broad set of tooling that's not deeply integrated leading to making engineering, engineering lives more cumbersome. The trick here is that while engineering teams want the newest, the shiniest, the coolest tooling that is gonna make their lives easier, it's critical to make sure that new tooling can fit within existing processes and workflows to complement them rather than recreating them. So just share a few takeaways around toil, the risk of reactive security and the amount of time that it takes to maintain, and this idea of, tooling overload and context switching being a drag on productivity. And so what we're gonna we we hear from customers about the technology and security innovations that great initiatives that they're taking on to drive these, core four outcomes. But in order to actually get there, in order to make that impact, in order to have success, organizations need to find solutions to their toil traps, to their reactive security fosters, and to their district disparate tool. But what you'll hear from the team today is how the new capabilities that we've introduced across ChangeGuard libraries, containers, and VMs, and what's coming in the future are focused on lowering those barriers to velocity. They're gonna help increase proactive, continuous security guardrails, make it easier for engineering teams to maintain the secure by default prep posture, while at the same time, operating within their existing workflows to make them more productive. Each product will kick off with some of the new things we've launched this quarter before sharing some details on what's to come. And so I'm gonna go ahead and start with containers and Aditya, who will be taking the baton from me. Aditya, if you wanna hop on stage and get started. Hey, everyone. My name is Aditya. I am a product marketer, on the Chainguard team supporting the Chainguard containers function. Been here about thirteen months. In a few moments, I'll be joined by, my colleagues, Tony and Tazeen, We'll talk a little bit about where we're headed with Changer containers. First, I wanna start with quick recap of the last quarter. So starting with what we recently released, we're gonna start with Helm Charts. So Changer came out with 40 plus first party Helm Charts that help containerized organizations migrate off of Bitnami charts and images. As many of you all know, Bitnami recently introduced a licensing change that moved formally free charts and images behind their paywall. And all of Chaingard's images are soft forked from those Bitnami, repos and meant to be drop in replacements, for your Bitnami migration. These are, fully, backed by Chainguard's minimal hard end zero CV images and guarded under our SLA with the Helm charts themselves being delivered as OCI artifacts to the registry of your choice. Tazeen will give a little bit more information on where we're headed from Helm charts for now. But for anyone interested, you can head over to images.changar.dev and take a look at the Helm charts that we have in our catalog. The other exciting announcements, were upgrades to how folks and users actually interact with our console. So first, we launched save as functionality and custom assembly. As many of you already know, custom assemblies are tooling that allows customers to take a standard or stock chain guard images and add packages it to meet the needs of your application. And for folks, you know, who are often first time using minimal images that don't have all the packages, that don't have a package manager shell, this can often be a really efficient way to, one, reduce the burden to customize your images, but also get to that production ready variant faster. And the important thing about custom assembly is that we extend our SLA to the full stack of that container image. It's not only the source container image that you started with, but everything that you added on top. Now one of the biggest road map requests we heard coming out of the custom assembly launch was the ability to create multiple variants of the same standard image. So for example, for a platform team to build one variant of Python for application team a and create a slightly different variation of Python for application c and b. What this allows them to do is maintain each image and it's only the minimal packages and set of requirements for that application, while also still maintaining the flexibility to have a customized image from Chaingard. With save as functionality, you can now quickly create new variants of any Chaingard image with as many variants as you want that are specific to each application downstream. And on top of that, we launched self serve provisioning for catalog customers. So as we discussed on the last webinar, Chaingard launched a new pricing model called catalog pricing that gives customers full access to our container catalog over 1,800 images. Now when we first launched, that catalog model, it there was a fair bit of friction to actually get your hands on the net new image that was in the Chingart catalog. With self serve provisioning, that's become a one click experience. So you simply head over to the Chingart catalog, you look at the full list of images, that Chingart has available, and you can just very quickly add a new image. And similar to the save as functionality, you can rename that image so that you understand exactly what you meant to use it for. You can delete images. You can edit images, and you can create new variants of each individual image. So for what's coming up next in the Chagua containers roadmap, I'd like to invite, my colleague, Tony Camp, onto the stage. Thanks, Aditya. Hey, everyone. I'm Tony. I'm a PM on the containers team, and I'm just gonna spend a few minutes talking about what's coming up for container images. The item I'm I'm here to talk about is policy gates. And if you're wondering what policy gates are, it's best to start with what we have today and where we wanna go to in the future. So today, this diagram kind of outlines what happens when a Chainguard image receives an update. That update is received. It flows automatically into your Chainguard console registry. And then if you have, any mirroring or syncing setup, it also flows down into your third party, artifact registry as well. With policy gates, we wanna be able to introduce a set of conditions or rules that an update must pass in order for it to get synced into your Chainguard console registry or to get pushed down into your third party registry. What will happen is in between the update and the registries, this policy gate or set of conditions is going to sit and monitor any of the updates that come out. And as they come out, if it passes, they do get synced to your registry. However, if they don't pass that set of criteria or conditions, we will block that update from being available to the registry, and we'll send appropriate notifications letting you know what was blocked and why. Phase one of this rollout would look something like we provide a set of those policies premade for you that you can simply toggle on or off, and you have a few other controls, which I'll demo, here shortly. And then moving on to something in our phase two, we're looking at being able to provide, some syntax or ways for you to custom create your own policy gates based on the rules that you define and not just the premade policies that Chingart creates for you. So before I go any further, I'm going to stop my share, screen share, and then bring up a a demo. Okay. So, hopefully, everyone can see this okay. What we're looking at right now is the overview page when you sign in to your Chainguard, console. And you will see on the left hand side, some of the the links that you are very familiar with, but there's also this new one for policies. So what I'm gonna do is click on the policies link, and I'm presented with this page showing some of those premade policies I described before. Each one of these policies has a name, a brief description, a status of whether or not it enabled or disabled, and a few buttons to allow you to toggle or, turn on the policy and have it start adhering or, I'm sorry, enforcing downstream on your, registry. So I can enable a policy immediately, which means as soon as I click this button, it's being enforced. The image updates that are rolling out are being, monitored. And if they don't meet this condition, they will not be available to your, registry or your third party downstream registry. You can also schedule one of these policies to go live at a later date. So imagine you want to, set a future date for the policy to start, enforcing. However, you want to wait a little while before it's enforced so you can monitor any of the changes and make sure that nothing unexpected is going to happen when this policy goes live. You can also set a policy just to alert only, which means, it will not ever enforce anything downstream. It's just going to monitor any of the updates, make sure that they pass conditions. If it doesn't, it's going to send it to an audit log and alert list that I'll show you as well. But if you're curious what this looks like on your registry, I'm gonna come over to, the images tab, and you'll see I have a list of the images that are available to me. And if I look at the second column, you'll see a policy column, and there's a few callouts here. So I'm gonna click into this nginx custom repository, and I'll see a list of all the tags available to me. And I'll notice these top two have a warning symbol on them. They are still available for me to pull. I can still use these. These are still being synced. However, this is being, monitored or alerted that it doesn't adhere to one of the policies I've set up. So there's something for me to look into. However, down at the bottom, you'll see that there's the blocked symbol, and each one of these versions 1.24Dot01.23 dot zero are disabled and no longer able for me to pull or will not be synced into my registries. If you're curious about why why this is happening, you can click on each one of the icons, get sent into this, audit screen, this, log that will show you all of the policies, which ones have been either blocked, which ones, which one of your images have been blocked, which have been warned on, the policy that it's breaking, and the origin. Alright. So that's all for the screen share demo for now. I'm gonna take a quick minute, get back to our slides. And I wanna take a moment and introduce Tazeen, who will be walking through and sharing a bit more detail about Helm charts and along with the demo. So thank you very much. Hey, everyone. My name is Tazeen. I'm a part of the product management team here at KingCard. Today, I'll be giving you a brief overview of what is coming up next with Helm charts. So let's go to the next slide here. We're continuing to expand both the breadth and depth of our home offering, starting with enhancing the user experience, focusing on better home charts discovery and also management directly from our console and, images directory platforms. Our upcoming updates include better documentation or readmeats at the chart level, the ability to look up mappings between home charts and their dependent images, and rendering the charts, values dot yaml files from the UI for quick access and inspection. We're also extending our home chart coverage. Many of our customers today, they're leveraging community home charts to deploy our images, and it leaves them wondering if those charts are coming from a safe source, whether they've, inadvertently exposed themselves to malicious content. We're going to solve this pinpoint for our customers and help keep them safe by building home charts for the rest of our images catalog and deliver those charts as signed OCI artifacts alongside our hardened containers from a single trusted chain guard registry. And in later phases, we'll differentiate these charts further through secure by default first principles so that they can come hardened, secure, and compliant with the right security frameworks right out of the box. Now I think I have some time to do a demo for you. So, let me set up my screen share. Alright. I hope everybody is able to see this. Okay? Cool. Yeah. So I am going to show you some of the upcoming user experience improvements we are making for home charts. If you are an existing customer with the ChainGuard account, you may already be familiar with this view from console.chainguard.dev. Currently, you're able to browse the console to see exactly which home charts are available from ChainGuard and which ones have been provisioned to your org. In this example, you can see that this org has been provisioned 12 out of the 40 plus Helm charts that we have available today. You're also able to review the versions that are available for each chart and when exactly they were released. So here's an example of that. This is the extent of the Helm UI today, but as I said, there's more coming up. So first and foremost, we're introducing Readmes at the chart level, which is you can find that from the overview tab here. And think of the Readmes as a quick start documentation, which will explain exactly what each chart is, which application it is deploying, and any configuration details that your developer teams need to know to deploy the chart correctly. You can also see the associations between each chart and its dependent images right here from the images tab. Let's say you want to use the cert manager, health chart. You can see here that this chart uses the cert manager CA injector image, the, webhook image, Acme Resolver, and cert manager controller. If you wanted to use the chart but you weren't sure if you have access to all the relevant images, especially if you're not on a catalog pricing model, this will help you identify which images you already have access to versus which ones your account representative may still have to provision for you. You can also view a rendering of the chart's values dot YAML file right here in the UI. From here, you can browse, you know, the, the default values configurations for the health chart, or you can copy or download the chart, directly into your machine for further inspection. So, yeah, this is just a quick overview of the console improvements coming up. We'll be rolling these out as they become available, so make sure to keep an eye on updates from ChainGuard to be notified when these capabilities start landing in the platform. And with that, I am now going to pass it over to the next speaker, Bria Giordano, to talk about Chaingard libraries. Thanks so much, Tazeen. I'm so excited to be chatting about Chaingard libraries and all of the exciting things that have recently been released. We've had a really exciting quarter, and we're just so excited to share those updates with you. These updates span across different language ecosystems and also across different features. So let's go ahead and dive on in. So we're gonna cover first what was recently released and then we'll transition into a demo as well as what's coming up soon. So to start, we're really excited you all might have seen our announcement about Cheyngard libraries for Python that recently went in GA. This GA announcement also included this this new feature and capability. It's really focused around reducing engineering toil when it comes to CVE remediation. A lot of our customers who are using our libraries already for mitigating malware and reducing their attack surface were also asking, hey, can you help us as well with the CVE headache that's been going on? Now the way we handle CVEs and containers is a little different than how we're able to do so in libraries and that's because many of you all are pinning to old versions. You don't always have the option to upgrade to latest as soon as that's available. And so if for our customers, many of them are pinning to old versions and instead of, you know, being able to update to latest or to a fixed version as soon as it was released, we are prioritizing back porting these upstream fixes for critical and high vulnerabilities so you can stay secure without kind of any modification or breaking change in your production environment. So what we do is we actually go ahead and we remediate these CVEs in our highly requested libraries. We started with the libraries that were causing our customers the most pain points. Examples include Django and Flask and we back forth these patches from the latest version into the versions that our customers are using over the last few years. This then buys you the time to upgrade when you're ready but it's also significantly reducing your attack surface as well in the meantime. These remediated libraries are fully tested and they include all the same benefits that you're familiar with already when it comes to our library's products including the full provenance and s bomb information. And this feature is currently available in ShakeOut libraries for Python and GA. Now the other thing that was really helpful for this feature that was a requirement as we started to look to evolve into this capability was how we would partner with our scanners and partnerships. So as a part of this feature launch, we also announced two different partnerships, or chain guard libraries. We now integrate with both Skype and Trivy. So you can use and scan your chain guard libraries for Python using scanners that you're already trusting. Many of our customers, these were our top two requested scanners, we're already using these scanners, and so we wanted to make sure we prioritize these partnerships. So now these scanners are able to detect our chain guard libraries remediated versions. So what that means is when we remediate a fix and patch it to an older version and back port that patch, these libraries are able to pick up, okay, not only is this library coming from Chainguard but we can also validate that that CVE has been patched as well. This is just the start of our scanner integrations and over the coming weeks and months, you're gonna see a lot more announcements about this that we're really excited to continue to share with you. Now the final thing I wanna share with you about what was recently released is a lot of the improvements when it comes to Chainware. So Chainware, for those of you who are using our product or might not be familiar with just yet, is a way of verifying where your libraries are coming from. This is where you can confirm that your libraries that you're using are being con are being sourced from Chainguard versus a different alternative such as an upstream repository. So this is helpful if you choose to set ChainGuard libraries as a priority and then you still set a fallback registry such as PyPI, NPM, or Maven Central as a fallback. You can then run Chamber against any artifact, directory, or container to verify, okay, this library was built from Chainguard. It's using all the s form information as you're seeing here. And you can also get, an overall view as far as the number of the coverage percentage of the number of applications or the libraries in those applications that are being pulled from ChainGuard. This is available today for Python and Java and we do have more improvements that we are making today. A lot of you are already familiar in using chain c t l already, and we are continuing to bring, this feature and embed it into that experience so you experience so you have one experience that you're familiar with on our containers product as well as on our libraries product. So that is a little bit about what was recently released and now I'm going to go ahead and hand things off to Angela, to walk through a demo of our CB remediation feature that we just covered, and to also highlight what is coming up soon. Alright, Angela. It looks like you're here. Are you able to jump on and do the demo? Yes. Alright. Thanks, Bria. Alright. I'm gonna share my screen, and I'm gonna be doing a demo of our Python CB remediation feature. Alright. Okay. So I'm sharing, my screens, in Versus Code right now, and I have up a example, just simple Python, project. And, I'm just gonna kind of go through, what the setup looks like, and then we'll I'll show, kind of, like, how we're using our remediated libraries and the scanner output recognizing our high and critical CV fixes. So the first thing I'm showing here is a configuration project file. So I'm using UV for this project. This file is just a simple Python project. There's a few dependencies, that I'm gonna be downloading, and these examples of Flask URL three and, these other packages are pointing to versions that have high and critical vulnerabilities in them. And with Chingart libraries with our CV remediation feature, we are actually, fixing those in, these fixed versions. And so we'll show how we, kind of consume those remediated libraries. Down here at the bottom, so we're pointing to two there's two different indexes that I'm using. The first one here is a separate index specifically for our remediated libraries, and then this index is for our all the Python libraries that we're building from source. And I have, my, like, pool token configured in, a net RC file on my local in my local, machine. Alright. Okay. So the first thing I'm gonna do is we're actually going to first demonstrate not using any of our remediated libraries, and I have a simple script here. Basically, what it does is it cleans up, the project environment. It then will download and resolve all the libraries and install it into the virtual environment. And then finally, it runs the gripe scanner, on the installed libraries to show what CDs are present. Alright. So I'm gonna jump down to the terminal. I'm going to run this script. And on this first run of the script, since we are only using our main Python libraries repository, you'll see in this output here that there are a few high severity CDEs, for all those libraries that we've installed. Alright. So now what I'm gonna do is we're basically just gonna add, another reference to be able to consume our remediated libraries. There's also this index strategy that, argument that we use for UV to, make sure that the resolution of all these packages continues continues to work when our remediated libraries have, dependencies on our non remediated libraries. So I'm going to run the same exact script again. This time, it's going to pull down, the remediated versions. Awesome. And so now you can see the gripe output doesn't have any high vulnerabilities reported, since we have actually fixed those and, gripe recognizes our fixes. You also see that the versions installed have that plus c g r suffix, indicating that these are libraries with CD remediation. Awesome. And that's it for my demo. I'm gonna switch back to the slides here. Alright. We're gonna I'm gonna share a little bit about what's coming up next for libraries. You know, a few things that we've been working on and super excited to share with you all. So, the first thing is Chingar libraries for JavaScript. We announced JavaScript libraries, back in, I think, in September. We're in a closed beta for the JavaScript library's product. And, it's designed similarly to our Python and Java libraries where we are building all these packages from source, that you would typically, you know, download from MPM. It's designed to mitigate the malware attacks that occur in the MPM ecosystem today, and all of these libraries are built in our hardened Salsa two environment. They'll be distributed to customers this fall, provenance, and SDOMs. And we're, in the early days of building out these libraries, and getting, you know, expanded coverage libraries, on MPM. So there's some examples here of popular libraries that we've built to date. And then the last point on this slide is we're also gonna be working on verification tooling to be able to verify that these libraries are built by Chainguard, and then check what level and percentage of coverage, is coming from Chainguard versus the upstream MPM registry. Alright. Next up, we are going to be working on a browsing experience for remediated CDs in our console. This is going to be an experience showing which CDs and Python libraries we have, done CD remediation for, enabling you to search more easily for where those remediations have happened. And the goal of this is to really offer visibility to your development and security teams, on the impacts of CB remediation. We've heard this feedback from a couple customers, so we're excited to be, working on this. We have some designs, and we'll be working with our engineering team to implement this in the next few weeks. Finally, on what's coming up next, we already have hundreds of hundreds of thousands of libraries that we fill across Python and Java, with several in JavaScript as well. And we're continuing to build out more to cover what your team's using production today. Coverage of these libraries is, really one of the main things that we are focused on, and so, we're really focused on building out what is needed by our customers, and so feel free to reach out to our team to learn more about, what coverage we have in your existing environment. And we're always prioritizing and building new libraries. So let us know if there's something we don't have, that you would want. Okay. Awesome. I'm going sorry about that. I muted myself. Alright. I'm gonna be passing it now to Anushka who's going to, talk about our Tringard VMs product, and she should be here shortly. Thanks. Thanks, Angela. Yeah. Back in March when we announced the ChainGuard VM's product, we started off with the container host. This was to help our customers run their containerized workloads as they leverage Shengard containers. Over the last couple of months, we've been collecting feedback on from these early customers. And, what we realized is customers want specific VMs in order to support their workloads. And this is what led to us creating the base as well as application VMs. Under base VMs, we have the ChainGuard OS, which is a clean, minimal, secure base to help customers build their applications on top of it. Java and Python are secure based images that are backed by the CVE remediation SLA, which is seven days for remediating all criticals and fourteen days for remediating all other types of CVEs. This is useful for customers to run their Python as well as Java applications. Following the successful deployment of Chainguard application images, customers wanted secure VM images to run Jenkins, NGINX, as well as QUID proxy. And that is why we launched these application images, application VM images. These are essentially VM counterparts to chain guard container images supporting these specific workloads. We understand that our customers have workloads running on cloud as well as on prem environments, And that is why it's important that all of our VM images are supported across cloud, which includes the three major cloud providers, AWS, GCP, as well as Azure, and also on prem environments such as Nutanix, qcow two, raw. What I'd like from you right now is to drop in requests to us around any future application as well as base DMs that we should be creating so that we're able to support your workloads better. Like I said, VMs product is a work in progress and something that helps us deliver exactly what you need is a strong collaboration with all of you. So Mark and I have been speaking to over a 100 different customers as well as prospects. And as we continue to refine the v VM product, what we realize is compliance is an essential piece of the puzzle, which is why we have now launched compliance capabilities for our VM images. Our VM images with FIPS 140 dash three validated cryptography backed by a NIST cryptographic module, which is CMVP certificate, is now a drop in replacement across the three major cloud providers. This essentially reduces any type of effort that an engineer would have otherwise had to do. This includes activities like research around controls, implementation of hardening, validating cryptographic modules, and documenting evidence, significantly freeing up developer time. Next, we have launched hardened VM images. These include hardening the images up to stick guidelines as well as making sure that these images are compatible with the CIS benchmarks in place. This reduces effort of applying 200 plus stick controls that a developer would have otherwise had to do in order to demonstrate compliance. We are also very close to signing a deal with CIS authorities in order to officially on, onboard them as a partner. Apart from this, we're also taking a lot of proactive steps to ensure that our solutions are even secured in a future state where there are a lot of new developments. First is Secure Boot. This ensures that VM boots only software which is signed with cryptographic keys, ensuring that your system's startup process is tamper proof right from hardware all the way to the OS. The second is quantum resistant hybrid KEMs. This ensures that cryptographic authentication and key exchanges stay secure even in a post quantum era, effectively preventing future decryption attacks aided by quantum computing. Our compliance capabilities are designed to make sure that customers are able to drive key benefits. There are three large benefits that we help customers unlock. First is dev toil savings. Essentially, we off board all the activities that a developer would have otherwise had to do in order to maintain compliance, in order to achieve compliance, which is a one time cost, as well as effort to maintain compliance, which is a monthly effort that needs to take place. Second, this freed up developer time can now be, okay, can now be invested in innovation resulting in better features as well as products that help our customers improve their competitive positioning and effectively sell more. Thirdly, we help unlock revenue. By having these compliance capabilities built in from the beginning, our customers are now able to sell to highly regulated customers. This includes health care as well as finance sector and also government bodies such as the DOD as well as the federal government. That's essentially what we have what we have launched in the last quarter. Now I'd like to hand it over to Mark so that he can walk us through what's coming next for for Cheynguard VMs. Thank you, Nuska. So my name is Mark Baker, and I'm product manager for Cheynguard VMs. I'm gonna talk to you a little about what's coming next with Cheynguard VMs. So first is gonna be customer assembly. You may be really familiar with customer assembly from Chaingua containers. Change it customer assembly allows you to specify exactly what you would like in an image. And this is extremely helpful because rather than having to customize an image after build, we generate the image to your specification, including all the packages that you require and nothing else. And not only do we generate the image, but then we then maintain it. So every time there's an update to any of the packages or any of the dependencies, the image automatically gets refreshed so that you always have access to that image that you have specified free from CVEs. Now this is something that we're building at the moment. So, we anticipate bringing it at some point in, hopefully, in early twenty twenty six. But it it should really help you decrease the amount of work that you need to perform in your golden image pipelines, those customization pipelines where, you know, that you're typically running. We look at what else we have, going on. So we're looking at, kernel level FIPs. So for this, we're looking at kernel level entropy, FIPs entropy source for the kernel. And this will allow instead of using kernel independent FIPs, this is, FIPs within the kernel. And this allows us to build out support for the crypto API. Now this is that is quite a long term thing. So but certainly, kernel independent having kernel level fits with kernel entropy, something that we have to we'll be delivering 2026. Crypto API will follow on from that. We're also growing out the hypervisor and platform support. So with Hyper V and indeed others that customers are acquiring. Building out the catalog. Again, on the container side, you know, we have those 1,800 plus different container, applications available in the catalog there. With VMs, we're very much playing catch up. So as we're engaging with customers and seeing what you, the community, would like us to build into that VMs catalog, we'll start building that out to give you more choice to service more workloads and more applications. Customer assembly, which we just discussed, and then also immutability. Depending on the use case, we've seen customers have asked us around how if we can provide immutable VMs. So these are VMs that can obviously can be customized at build time if you're using something like customer assembly. But when they're running, no changes can be made, certainly to the to the user space. Right? So, sorry, the user file system, so where the applications are running. And this really talks towards, intrusion or security prevention rather than just detection, and management. And then finally, we're looking at in place updates. So, again, if several workloads are great, being able to, work with node replacement, so replace nodes when, you need to be able to get access to new fixes and new patches and new features. But we also have customers that said, actually, there are times when they want to be able to apply an update in place, but for either reasons of application or business continuity or or because they need to schedule, some downtime or or some application refactoring. And so being able to apply in place updates, something, again, that we'll be looking to to deliver in 2026. So let's go ahead and, show you some of, Shenguard VMs in action. And there we go. I just need to share my, the appropriate, window here. There we go. So hopefully, you'll see that coming up. So here I am in the e c two console, and you can see that, actually, I have a number of different ChainGuard, instances running. So if we take go and take a look at, take a look at some of these. In fact, let me just filter this so you can see that these are, Chainguard here. We're gonna pick up onto, or else we got some Ubuntu, some AL twenty twenty three, running too. But we go and pick on, gonna pick on one of the chain guard ones. If I let's start with this one. And so here, let's see. This is the node that's running in e c two. You can see down here from the AMI name, that it's actually, for EKS. Right? So it's, for EKS one two three, and we'll we'll dive a little into that in a second. You also see from the AMI location, it's been launched from AWS Marketplace. AWS Marketplace is where we publish all the ChainGuard AMIs, the ChainGuard images. And so if you wanna be able to get access to those, to be able to try them out, we'd love you to get in touch there. We go ahead and connect to this environment. You see, we're connecting using session session manager, which tells you that this actually has the s m SSM agent installed. So we we supply the Cheynga VM for this environment with the AWS agents, pre installed so that you can access those straight away. That's optional, though. You don't need to have to have those. So we just take a look at quickly, something you'll see here, you name minus a. We see that this is running a six seventeen kernel, so quite a recent kernel. And that's because with this, VM tracks upstream stable. Right? We also have a couple of other things. You can see, down here, we have running system d unit. So you can see ChainCloud VM looks, for all intents and purposes, like a regular VM. And so no different perhaps from many other VMs that you're that you're typically running today. There is a difference though. If we go and check out, for example, let's go and take a look at this VM here. This one you'll see, again, in the air, my name is EKS, but this one is FIPS. So this is one of our FIPS compliant VMs. And if you're running FIPS compliant workloads, for example, in Amazon EKS, or FIPS that need workloads that require FIPS compliance, This is going to be the the the image that you can start with. You don't need to go adding FIPS to it yourself. It's already there. And so if we go and take a quick look, for example, in this environment, couple of changes that will, will just call out a couple of differences. So first, if we do the same thing again, you'll see that we're running the LTS kernel. Right? And this is because for compliance, we ship an LTS kernel, a six twelve, the upstream LTS kernel, validate that with FIPS and indeed the STIGs, and other components that we we work with. And just to, show you that, for example, we can here, we do open SSL dash FIPS dash test. You'll be able to see here that we are running a full FIPS validated module within this environment. And and we even have the link to the CMVP here at the bottom. So, again, if you care about compliance and if FIPS is part of that, you can straight away get up and running with a FIPS compliant VM for hosting, in this case, your, container workloads. The other thing I'll call out whilst we're here is, if you we run this little command called boot CTL. This, gives us details on the security profile, right, of our boot environment. And so straight away here, I want to be able to call out that secure boot here is enabled. Right? We are all the chain guard VMs now support secure boot, by default. And so, again, if it's not something you require, you can you can turn it off. But, but certainly in those compliance and those secure environments where you want to ensure that, your boot process hasn't been interfered with, then secure boot is enabled by default. And as you can see here, up and running. And then I'll make the, the final point. So these are these VMs are running as part of our cluster, our EKS cluster. So they're a chain guard host. We have both FIPS and non FIPS VMs running alongside, in this example, Amazon Linux and, Ubuntu. So we have three sets of non FIPS compliant VMs here running, and then one set, these Tango VMs that are running in FIPS compliance. So this gives you the all the flexibility you need to be able to run securely in compliant environments. If I switch back and, just wanted to to to to wrap up and say that ends the session for Taingard, update this quarterly update. Thank you so much for joining, and we really hope that you'll be able to join us in, the session next time, next quarter. I mean, again, that we'll be looking to to deliver in 2026. Let's go ahead and, show you some of, Chainguard VMs in action. Hopefully, you'll see that coming up. So here I am in the EC 2 console, and you can see that, actually, I have a number of different Chainguard, instances running. And so if we take go and take a look at, take a look at some of these. In fact, let me just filter this so you can see that these are, chain guard here. We're gonna pick up onto, one of those. We got some Ubuntu, some AL twenty twenty three, running too. But if we go and pick on go and pick on one of the chain guard ones if I let's start with this one. And so here, let's see. This is the node that's running in e C two. You can see down here from the AMI name, that it's actually, for EKS. Right? So it's, for EKS 123, and we'll we'll dive a little into that in a second. But you also see from the AMI location, it's been launched from AWS Marketplace. AWS Marketplace is where we publish all the Chaingard AMIs, the Chaingard images. And so if you wanna be able to get access to those, to be able to try them out, we'd love you to get in touch there. We go ahead and connect to this environment. You see, we're connecting using session session manager, which tells you that this actually has the s m SSM agent installed. So we we supply the Cheyngular VM for this environment with the AWS agents, pre installed so that you can access those straight away. That's optional, though. You don't need to have to have those. So we just take a look at quickly, something you'll see here, you name minus a. We see that this is running a six seventeen kernel, so quite a recent kernel. And that's because with this VM tracks upstream stable. Right? We also have a couple of other things. You can see down here, we have running system d unit. So you can see change out VM looks, for all intents and purposes, like a regular VM. And so no different perhaps from many other VMs that you're that you're typically running today. There is a difference, though. If we go and check out, for example let's go and take a look at this VM here. This one you'll see, again, in the AMI name is EKS, but this one is FIPS. So this is one of our FIPS compliant VMs. And if you're running FIPS compliant workloads, for example, in Amazon EKS, or FIPS that need workloads that require FIPS compliance, this is going to be the the the image that you can start with. You don't need to go adding FIPS to it yourself. It's already there. And so if we go and take a quick look, for example, in this environment, couple of changes that we'll, we'll just call out a couple of differences. So first, if we do the same thing again, you'll see that we're running the LTS kernel. Right? And this is because for compliance, we ship an LTS kernel, a six twelve, the upstream LTS kernel, validate that with FIPs and indeed the STIGs, and other components that we we work with. And just to, show you that, for example, we can here, we do open SSL dash FIPS dash test. You'll be able to see here that we are running a full FIPS validated module within this environment. And and we even have the link to the CMVP here at the bottom. So, again, if you care about compliance and if FIPS is part of that, you can straight away get up and running with a FIPS compliant VM by hosting, in this case, your, container workloads. The other thing I'll call out whilst we're here is, if you we run this little command called boot, CTL. This, gives us details on the security profile, right, of our boot environment. And so straightaway here, I want to be able to call out that secure boot here is enabled. Right? We are all the chained RPMs now support secure boot, by default. And so, again, if it's not something you require, you can you can turn it off. But, but certainly in those compliance and those secure environments where you want to ensure that, your boot process hasn't been interfered with, then secure boot is enabled by default. And as you can see here, up and running. And then I'll make the, the final point. So these are these VMs are running as part of our cluster, our EKS cluster, so they're chained out hosts. We have both FIPS and non FIPS VMs running alongside, in this example, Amazon Linux and, Ubuntu. So we have three sets of non FIPS compliant VMs here running, and then one set, these 10 guard VMs that are running in FIPS compliance. So this gives you the all the flexibility you need to be able to run securely in compliant environments. If I switch back and, just wanted to to to to wrap up and say, that ends the session for JaneGuard, update this quarterly update. Thank you so much for joining, and we really hope that you'll be able to join us in, the session next time, next quarter.