Transcript for "Establishing Continuous Compliance with Anchore & Chainguard: Automating Container Security":
So excited to have you, all here today. We are going to go ahead and kick things off. Welcome to our webinar with our newest ecosystem partner, Anchore. We're so excited about this partnership and to share today how we can support you on your continuous compliance journey with both Chainguard and Anchore. And I'm really excited to introduce these amazing experts we have in the room, Brad Bach, director of product at Chainguard, Neil Levine, head of product at Anchore, and you'll also be joined later by Tazeen Praga, who is also on our product team and and worked, really hard on this this partnership. Just a few, logistical things. During the webinar, if you have any questions, you can ask them in the q and a section on the right hand side of your screen. We will get to those at the end of the webinar. Wanna wanna, make sure we're answering all your great questions. But that is it from Keith. I will pass the torch to Brad to walk through the agenda and and kick us off. Great. Thank you so much, Lily. And, thank you so much, Neil, for for joining and for the great partnership. Really excited to to be having this tick off today. So, yeah, we're we're here to talk about continuous compliance. It's it's a really important topic, one that Jane Gard thinks about every single day. And this this is kind of the agenda. We're gonna start with the role of compliance in today's organizations. Why should you care? Why is it so difficult, and why do we need to do all these things we're doing, to address it? Moving from a reactive kind of point in time approach to a continuous compliance approach. And then we'll talk about how Chainguard and Anchore together can can help you get there, and we'll actually show you, with a demo. So, yeah, jumping right into it, you know, the role of compliance in pretty much every business, today. You know, compliance can sometimes be, misconstrued as just a cost, something that, you know, comes up every quarter, and you have to check a box and it's a pain, and then you can forget about it, until, you know, the next quarter. But it can actually drive top line growth for your organization. Technology and security leaders are in a unique position where they can unlock revenue and market opportunities by, entering markets that care a lot about compliance more efficiently. Achieving compliance can expand your addressable market and accelerate your entry into new sectors. When compliance processes are automated, you can easily show your work and shorten sales cycles by making audits smoother and kind of showing, you know, customers that you've you've done your homework. And, ultimately, demonstrating strong security and compliance builds provable trust, and increases your win rates and competitive deals. We know that from experience. That's that's one of our, biggest selling points. Your your ability to access these benefits, though, depends on having software development processes that are not just secure, but compliant and scalably so from the ground up. So let's take a look at how compliance could serve as a ticket to enter new industries and regions. Different sectors have specialized regulations like the ones you see on the on the screen here. You've got frameworks like the essential eight for Australian cybersecurity. Everyone knows HIPAA for The US medical industry, PCI DSS for for payment payment cards or sending payments, NIST two and CRA for European critical infrastructure and products and services. And then FedRAMP if you wanna sell into the US government, which, you know, nowadays, I think almost everybody has that goal of selling into the US government. Meeting these meeting these needs or meeting these these frameworks often means you're handling data like protective health and information or credit card data, or serving new geographies such as US government agencies, EU infrastructure, or or different, products and services around the world. If you're if you're achieving and demonstrating this compliance proactively, you you feel a lot more confident going after these opportunities knowing that the regular regulatory frameworks and requirements won't get in the way of you doing business. Of course, the flip side of compliance is the risk of getting it wrong. Different frameworks and regions impose pretty steep financial penalties for noncompliance. Just one good example is in New York. The New York Department of Financial Services can levy fines stretching from, you know, $2,500 to $75,000 for each day of noncompliance. Across Europe, NIST two imposes director liability and fines up to €10,000,000. The the Cyber Resilience Act can result in penalties exceeding 15,000,000. And in The US, HIPAA violations can cost your organization over $2,000,000 per violation. PCI DSS penalties can reach a $100,000 a month, and, you know, the list goes on. So these figures make it clear that compliance failures have a serious, tangible financial consequence and even a risk of personal or even criminal liability for your organization's leadership. Beyond fines I mean, compliance failures are just something that you don't you don't wanna have in your organization. They can have a cascading impact on on the business. You know, if you miss launch deadlines, you you can lose critical market windows. You can have customers that, you know, are depending on you for compliance, downstream. And if you're if you're not compliant, you can get customer churn and, you know, a road of trust and lost contracts. There's also just brand and reputational risk as these things, you know, are talked about in in the public, work that's around. One one breach or compliance incident can undo years of hard work building your brand. So, ultimately, compliance failures can put you at a competitive disadvantage, losing deals to organizations that can more clearly prove their trustworthiness. So kind of summarizing it, you know, there's there's, there's opportunities and risks. And where these things overlap is is, you know, what we're thinking about here today. It's not just a technical obligation. It directly impacts the bottom line. On the on the positive side, you've got increased revenue, market expansion, elevated customer trust. On the risk side, you've got compliance gaps leading to longer sales cycles, customer return, potential fines, or reputational damage. And so balancing these two sides is critical. If you're seeking to scale securely and responsibly, it as more and more industries and sectors of the economy, add compliance requirements, and they're just table stakes for even participating in the market. So let's talk a little bit about why this is hard, and why so many companies struggle to get it right. It starts with these mark modern architectures that are, you know, largely composed of microservices running in containers and Kubernetes, which has made it easier and faster for businesses to build and launch digital products using open source software, especially, with with more workloads, more open source components, and ever growing chains of dependencies, often from who knows where, the complexity keeps escalating. So staying compliant now means tracking each piece in this constantly shifting landscape, including, you know, visibility, oversight, and audit readiness. And, you know, there's there's exponential growth, in the number of workloads running more than ever before, and and global infrastructure spend reached over $300,000,000,000 in 2024 with 20% growth year over year. So, you know, huge expansion. Organizations are increasingly relying on open source to power new products and features, which means more components and dependencies entering the stack, and many of them are coming from unfamiliar or uncontrolled sources. Each of these new workloads and dependencies expands the compliance surface area, which makes it harder to track what's in use, where it came from, and whether it even meets regulatory requirements. So as your as your business technology grows, so do the challenges. Maintaining security, knowing what's in that software you're deploying, audit readiness, these all become moving targets, and they were they they demand tighter controls, more automation, better automation, and ongoing oversight. And doing all of that at the pace of of business can feel impossible. Alongside this explosion of new technology frameworks, there are rapidly growing numbers of vulnerabilities you have to figure out, how to deal with. Major frameworks like PCI, DSS, FedRAMP, and HIPAA mandate constant vulnerability management, and they set strict expectations for how quickly issues have to be addressed. So just as an example, PCI DSS can require, you know, prompt recording reporting rather and remediation of risks. Bed ramp enforces continuous scanning and documentation. HIPAA demands ongoing protection of sensitive health data, and a single missed remediation window can lead to compliance failures that are hard to come back from. Essential eight, for example, specifies remediation within forty eight hours and similar pressure is mounting across all major frame works. You might have seen just recently the FedRAMP 20 x requirements were released. Those mandate remediation of critical vulnerabilities that are that are reachable from the Internet within seventy two hours, which is down from thirty days previously. So staying compliant isn't just about finding vulnerabilities. It's about responding quickly, maintaining a kind of chain of evidence, and organizing efforts across multiple overlapping technologies, teams, and requirements. So amidst all of those stringent requirements is this graph you see here, which illustrates a sharp rise in software supply chain threats. In 2024 alone, over 700,000 malicious packages were discovered, up from a relatively tiny amount. I can't even tell how many it was before 2021. So you have this kind of hockey stick growth here. The search highlights this reality that attackers are targeting the open source ecosystem itself, not just the traditional infrastructure. So for engineering and security teams, this means even more time spent detecting, evaluating, and remediating threats. This adds a lot of strain and complexity, you know, on your on your engineering teams, and across your organization. So supply chain attacks reach unprecedented levels. It's clear that proactive automated defense and compliance measures are essential for protecting innovation, ensuring that you're ready for your audits, and moving towards continuous compliance. So let's focus on the real world impact on your engineering teams and your bottom line. One of my favorite buzzwords, that I may have helped come up with is developer toil. This constant need to remediate CVEs, often under tight SLAs, it saps their productivity and frankly sucks the joy out of the work. Teams trying to do this manually are forced to spend time on tasks that they serve compliance over direct business value, but the business value doesn't decrease because you have to spend more time on compliance. Any of these tasks like maintaining FIP's validated cryptography, manually scanning and building software bills and material, or prepping audit evidence, they take too much time by themselves, and together they're just derailing your teams on a regular basis. So they need to juggle multiple frameworks, disparate requirements, amplize the toil, and it further kind of increases the cognitive and operational overhead. So and you can see that, you know, in these in these costs, outlined here multiplied by, you know, the tens, hundreds, thousands. So elevating engineering out of this cycle requires shifting compliance to be automated and continuous. It frees up your teams to focus on what matters most. Shipping secure, reliable software that propels your business forward. So now, like, I'll turn it over to Neil now to talk about how to improve this this somewhat bleak picture and also to take advantage of the benefits of continuous supply clients that I've been painting here. Okay. Thank you so much, Brad. So it's it's a pretty stressful, environment for a lot of, folks in organizations at the moment. So, obviously, we're we're gonna try and help you find a path after this here. And the sort of the summary of this, which is where compliance has been very much a reactive one off manual set of activities that most organizations have been performing for many years now. This is about moving to a continuous one. Continuous implies or has within it sort of two implicit things, which is number one, it has to be embedded. You can't it's difficult to bolt things in after the fact. That usually ends up in less efficiency than when you've taken time to, make it a native part of your environment. And, obviously, the second part is everything has to be automated. A large part of the goals, for both Chainguard and Anchore and others at the moment is to try and automate as much of this as possible. When DevOps started, it didn't include security, and that later changed. We then brought in DevSecOps to represent the fact that we needed to automate security checks as part of our tools and processes. But compliance got forgotten about the large part of that, and I think this is now about trying to bring in compliance into the DevSecOps mentality without hopefully creating a new acronym to confuse people and, bloat marketing even more. Okay. So what does this mean in practice? And so I'm gonna go through some some of practical things you can do, and then we'll we'll show some demos to sort of try and connect the dots here. So like DevOps, which is about bringing teams together at the beginning of a project to work on, and understand what the end state is, This is a similar process now by bringing compliance, teams or individuals into into the conversation. So at the very beginning, you need to decide what are the policies that you are trying to comply with. Just becoming aware of that at the beginning of the project rather than at the end can, resolve a lot of issues straight out of the box. So understanding that you've got commitments around CRA or MIS two in Europe. You may be a US organization, but if you have US European customers, you still have to address those compliance needs. Things like FedRAMP might be more obvious, but sometimes you still have to comply with NIST requirements, as part of, you know, interacting with the US government here. So bringing the GRC team to try and understand what the end state is really is really important. And then the DevOps teams themselves may be trying to aspire to salsa levels even if that's not coming from a a regulatory burden. There may be, you know, a initiative to try and reach one of the salsa levels to sort of show that you have competency and maturity in how you're addressing your, supply chain concerns. So this is kinda like test driven development. You you're trying to work out what the end state is and then build up to it rather than doing it at the end. And so where possible, you want to be aware of those policies and encode them into both the tooling and the processes that you're following. Obviously, we're we're here to sort of, promote how Anchore and Chainguard work together. And, you know, there is now a clear demand to move towards using, secure by default or hardened images in in, in your pipeline here. So this is really about moving away from what a lot of organizations have been doing, which is creating golden images, which tend to be sort of very generic, have a large attack surface, and tend to be updated very infrequently. So moving towards images which have smaller attack surface are updated much more frequently. And, essentially, this is not moving not shifting left. This is like moving things out of your developers entirely by making the vendor for whom you you source these hardened images responsible for the compliance at the very beginning. So you're really trying to move it out of the organization's concern from the very beginning. This is obviously, a large part of where Chainguard are gonna help, and this this addresses a large chunk of compliance issues from the very beginning. Once you have these hard images into your pipeline, you then have to sort of think about the types of artifacts you need to be generating or the type of, outputs you want from the system here. So s bombs are a great place to start. They're very easy. They can be overlaid as part of existing tooling if possible, and they're very useful for zero day response as well as for compliance, obligations that you may have. If you are looking to do SELSA, which is more about the tools and the actual, you know, the CICD tooling you have, maybe the registry and so on and so forth, you need to work out what kind of outputs though the tools that you have can, produce for you. So don't ignore the pipeline tools when we think about this compliance. It's not just about the software that you're building or you're selling or you're operating. It's also about the environment here. The pipeline is part of your production environment when you consider the number of supply chain attacks which are hitting things like, popular CICD tools, or other developer. So think about the artifacts you wanna have. Make sure that they've been generated as part of the tools that you're selecting. And then the final piece is obviously to generate you know, you need to store all these things, to make it easy to produce the evidence that, your GRC team or auditors or regulators need to see. Simply just storing and proving that you've generated these artifacts and you have them stored often gets you into a compliance state in and of itself. A lot of regulators aren't necessarily looking to go through line by line on all of your, commits and your s bombs and your vulnerability reports, but they need to know that you're storing them. And so showing that you have the tools in place, that you can prove that this information is being captured, especially for some of the European regulations, is a large part of getting to a compliance state. But where you do need to actually generate specific documents, a list of vulnerabilities, the associated s bombs, and so on and so forth, having that in a place where it can automatically be produced, and sent onto security teams or your GLC teams or even directly to auditors is really critical here. So ensuring there's API access so you can do this stuff in an automatic way and it doesn't involve pointing and clicking by humans is a large part of the automated process which gets you into a sort of continuous compliance state. Okay. Let's move into some of the specifics, about our tools. But the key message here is to to to ensure that compliance is at the beginning of this, and this is both where Chainguard and Anchore are trying to ensure that compliance is a native property of what we're delivering rather than an afterthought. And I'll pass it back to Brad to, introduce some some some information about Chainguard. Come off on mute there. Thank you, Neil. Yes. Let's let's kind of go through, a little bit, on kind of what we're each bringing to the table here. So, you know, at at Chainguard, we are really focused on, building container images, and other products like, language ecosystem libraries, virtual machines, that are, you know, compliant out of the box. We we keep all of our we have our own package manager. We keep everything up to date, and we're we're very good about updating all of our images on a rapid cadence. And with the result is that when you you scan these things, most of the time, they're coming back with zero CDEs, which makes it a lot easier to achieve some of these, framework requirements out of the box. If you're trying to get FedRAMP certified, your vulnerability remediation story becomes a lot more simple when there are no vulnerabilities in the software that you're deploying. Our containers are packaged, with security best practices baked in by default. We have, FIP FIPs a certified FIPs open SSL that's kernel independent, for, you know, FedRAMP, StateRAMP, and CMMC environments. And all of our software comes with software built in materials, signatures and attestations and provenance built into every single or a piece of software that you get from us. And and essentially, you know, my job, I'm a product manager, but I'm focused on integrations and partnerships. We're constantly ensuring that we're compatible, with the broadest, you know, ecosystem as as possible. So when you're using tools like Anchore, you're you're kind of getting this better together experience where, you know, the the software that you're getting from us, is is interoperable and and you're getting complete and accurate scans and things for from Anchore as you're as you're thinking about continuous compliance. So I'll I'll pass it back over to Neil to say a couple words about Anchore. Sure. So, Anchore, is a platform which provides, a number of different core functions. There is an SBOM management function here. We generate and ingest SBOMs from, both registries, but also through CICD as images are being developed on and used and integrated into applications. So automating the SBOM generation, and storage is the the first sort of core function. The second function is the vulnerability management, default, you know, zero CVE or low CVE, hardener images, remove a lot of the initial burden. But, obviously, teams have internal software developments where they're then, you know, bringing in additional packages, bits of software from, you know, GitHub or other places online. So having that continuous vulnerability management for some cloud native applications in general is a second core part of it. And the last part is the compliance. It's the ability to generate the reports to store, the information and produce the evidence that your security teams need to amass for the GLC teams or for auditors is a large part. And here, we sort of work with, some out of the box policy packs, FedRAMP, NIST, and so on and so forth to sort of streamline and get you up and running much faster as part of that beginning journey where you encode the policies at the start of your, tooling design rather than at the end. Okay. So I think we're gonna hand we're gonna do some demos now. So I'm gonna hand this over to Tazeen from Chainguard to start, and then, I'll do the angle demo after that. Awesome. Hey. Thanks so much, Neil and Brad. And, hey, everyone. My name is Tazeen. I'm a product manager from Chainguard. So as you just heard from, Neil and Brad, Chainguard and Anchore complement each other really well. Chainguard images help your dev team start safe, with over 1,700 secure by default, zero CD alternatives to popular applications. While Encore complements this by helping you stay secure, continuously scanning those images and workloads, enforcing policies automatically, and validating compliance across vulnerabilities, licenses, secrets, malware, and more. And together, ChainGuard and Encore really give you the confidence that you need every step of the way from development through to production. Let's now take a deep dive into how this all looks in practice. We'll cover Chainguard first, and then I'll pass it back over to Neil to show how Chainguard zero CV images integrate seamlessly into Encore enterprise. Alright. Hopefully, you can all now see my screen. Cool. Alright. So, yeah, speaking of c or c d images, you can browse all, the images that are currently available in Chainguard's directory by navigating to images.chainguard.dev. Once you land here, you can sort through our AI, application, base, and FIBs images categories, or you can simply query if you're looking for something very specific. I mentioned earlier, that we have a robust catalog of over 1,700 images. Actually, it is at seventeen thirty one images, currently, to be more precise. And this list is only going to keep on growing as we keep adding more images to our catalog. So, really, there is something here, for everybody. Now let's say that, you know, you're looking for a hardened image for a database service, and you have decided to go with Postgres. So you can query our site by Postgres, and let's see what comes up. Alright. So as you can see, you'll have a few different options, that are available to you here. There's a variety of, FIPs validated kernel independent images for those who are prioritizing, FedRAMP compliance. And we also have, health friendly variants, all of which are delivered zero CVE, and they also abide by our, CVE SLAs. Let's actually look at the topmost image here. So as I already mentioned before, Chainguard Chainguard images are built daily from source, and they abide by our, best in class CVE remediation SLAs to rapidly patch any new CVEs. And as you can see in this instance, the post quest image is being constantly updated, and we're releasing new versions frequently, sometimes, like, multiple times in a day. If you're ready to start using the post press image, we make it really easy for you. You can just navigate over to this, overview tab, And here you'll find some quick start instructions to help you get started using the post press image, assuming you already have access. But let's say if you're still undecided about whether this is the right image for you, whether Chainguard is the, is the right vendor for you, one really cool functionality to help you decide is this comparison, feature. Here, you can, compare the latest, Postgres, image by Chainguard against popular, third party alternatives. So you can see from the drop down all the, third party alternatives that you can run a comparison against. For this demo, we're just gonna stick to the upstream postgres image, the latest version of that. And as you can see, over the past month, the Chainguard Postgres latest image, it did a lot better in terms of vulnerabilities than the upstream Postgres latest image. On average, our, CB count lingered somewhere between, you know, zero to one CBEs throughout the month. Whereas, like, as you can see with the alternative, it started out with over 80 plus CBEs on some days, lots of criticals and highs, eventually dropped down to about 20. But you can see there you can see that there's still a few critical and high CBEs that are still lingering about. Here's another, cool visual representation where you can verify how our images stay zero to low CVEs consistently over time versus alternatives. Now let's talk about provenance. For that, we'll hop over to the provenance tab. So as Brad mentioned earlier, Chainguard images come with verifiable signatures and provenance and attestations. Our images are signed using sigstore so that you can verify them using cosign. We also ship high quality s bombs with all of our images that tells you exactly which packages went into making up our image. And you can also query for specific packages here if you want to know, if it's in here or, like, you know, what version of that package, is being used by this image. Alternatively, you can even download, the full s bomb here if you want to continue your analysis elsewhere. You can also flip through the different versions, of our images to verify your last available CVE status. So, this is defaulted to the latest version, which as you saw in the comparison tab, this is free of CVEs. We can take a look at a few other, versions. So let's try, postgres 17.six. This too is free of CVEs. It was last scanned two days ago, at which point we did not find any vulnerabilities. We can go even further back. Let's try 17.5 here. Alright. So you can see 17 dot five. This is an older image. This was last updated about a month ago, which you can, find out from this really helpful the banner over here. That was also the last time it would have been scanned. When we last scanned it, we found that there are two CVEs of low severity, both coming from the BusyBox package. If you are using 17 dot five, your remediation guidance here is, as you saw earlier, both the 17 dot six and latest versions of Postgres are CVE free. So you can upgrade to either of those versions and, remediate these CVEs in your environments. Alright. So that's everything from my end. Let me now pass it back to Neil to show you how Anchore enterprise can help you get up to up to date CVE and compliance visibility into your Chainguard images. Okay. Thank you, Tazeen. Let me show my screen. Okay. Share a window. And hopefully, again, people can nod, thumbs up, indicate, shout when they can see the screen. Yes. There we go. Thumbs up. I like it. Thank you. Keep praying for the demo gods, everybody. Okay. So, here we can see, you know, continuation of, the chain guard catalog view that, Tazeem was showing. So I've got NGINX at this point. We can see the the latest, builds with, you know, as we've showed you, we've got a list of the packages. And luckily here, we have no vulnerabilities. So the first thing that, you know, we've worked on these two companies is ensure to ensure there is strong fidelity between the information being generated or produced by Chainguard and the information that Anchore is showing as well. Because a large challenge that you see between hardwood image, you know, catalogs and vulnerability scanners in general is when they're mismatching and they're telling you different things. So the first part of the the partnership we worked on is to really try and ensure that we have some, fidelity. So here, you know, we we're now in the anchor interface. We would go ahead and add the, NGINX image. It would be latest. One particular feature you probably wanna use if you're using our product is to watch the tag. So as new images are built, as to the show, that's pretty rapid. You would get them immediately. You'd get that pulled into the system, and, obviously, you can receive a notification if you wanna get a, confirmation of that. So I've already pulled in the, the NGINX image. It usually takes, you know, a minute or two, which I didn't wanna make a really sip and wait through during a demo. But let's click into this. So here we have the latest tag. Here we've got the, the sharp. And first off, we can see we have exactly the same packages listed on the SBOM as we saw on the chain guards catalog view. Anchore does go a little step further. We actually do explode out for those packages, and we can show you the packages. Sorry. That were also on the, the the catalog there. Same same packages with some additional metadata. We'll explode out all the individual files as well. So if you want to go through and see the files and file system, it's like an extended s bomb you get to see with Ancore here. This is important for some of the policy stuff, which I might show later, where, you know, things like modes, permissions, location, the additional things you can control for in the policy. And just to confirm the affinity here, we're seeing no poll no vulnerabilities. So, that's looking good. Okay. Let's check out another image. We'll pick the Internet's favorite whipping boy, which is WordPress, which, often tends to have issues. Here again, we see the the list of packages. And with the vulnerabilities, we're seeing three mediums. So nothing too concerning. No criticals, which is usually what most people care about. So here again, I've got the the WordPress image. It's being scanned in. Here's the latest sha. Again, you can see the packages that will be mapped exactly to the image, to the image catalog of Chainguard. Okay. So let's look at the vulnerabilities here. Again, so this is the important thing. We can see exactly the same list of vulnerabilities that we saw on the Chainguard view. There are no vulnerabilities which were surfacing as false positives or equally, we're not missing things which Chainguard have called out. So that affinity between, the tools is very important, and that's a large part of where the, integration effort between Shengard and Anchore has been put in. Okay. But let's let's start building and doing something with this image here. So if we look at the image metadata, you'll see, we have this image digest. Let's remember the first six characters, FD6387. So that's a unique identifier for this WordPress image. Let's say you've got a developer at this point taking this image and starting to load in, you know, presumably their blog or their their website. So I built another image here, a demo image I built up, using that image. And you can see here FD6387. So you can see here the ancestor of that image or the base image, the the the operating system, underneath the application as it were, is, represented here. And I built my own one on top. K. Let's go to the s bomb and see what I added. The Internet's other favorite, bet noir is Log four j. So here we I've added in a, you know, an old version Log four j, the one that caused all those concerns and those issues. You can see that's been broken out as a sort of a Java package distinct from the, operating system packages which, ChainGuard are responsible for. So if we flip over the vulnerabilities, you'll see the original three vulnerabilities, flagged up, as part of the, the Chainguard view. Those are these, you know, Alpine images, which they've got in here. But we've now got additional vulnerabilities indicating that we've got, you know, this this this, very, very, concerning package of Log four j. So that's coming up now. As, you know, your developers are building on top, you can start to see these additional vulnerabilities will be caught by the system. Critically for Anchore, we've been, you know, we've been talking this webinar about compliance. So a large part of the value of Anchore, is doing that continuous monitoring of the compliance status of these images. So here you'll see a slightly different view. We're currently using a policy bundle. This is a default one we ship with, which is really just looking for, you know, some some of those concerning vulnerabilities, which are being flagged up as things which would stop your pipeline or stop going to production or generate an alert of some sort. If we wanna look at, the FedRAMP side of things, let's flip straight away to a FedRAMP policy pack. So this happens instantaneously. We have all this data in the system. So rescanning for a different policy evaluation can happen straight away. There's no need to rescan the software. And you can see that it's calling out these criticals, as being a concern from, from a FedRAMP notification point of view. There's some additional checks we're doing as well. We've got a sort of high degree of sensitivity around things like Dockerfile configurations and other things. So other areas which might be a concern for, if you're doing a a FedRAMP assessment as we're adding these, vulnerable vulnerable packages, on top of the original image. Okay. So we can see now we can do that sort of immediate assessment of now we're out of compliance because I've I've built this this, this, failed, image with, you know, the Log four j content. K. But how do we generate this information? How can we show, to the security team or the developers that this stuff is now causing a problem? So let's pick this is our report system here. This is how we generate the information that goes out of the product into, other people's tools or, notification systems here. So we'll pick a particular report, say, images affected by vulnerability, and we'll narrow this down a bit. So first of all, I'll pick, the repo that, I used. And I'll also importantly show where we can notify just on the content that developers are adding and not worry about the things underneath. That is let's not worry about generating reports for the Chainguard images because Chainguard are responsible for those. You don't need to know about those. You only need to know about the things your developers have added on top. So let's add in the the repo, with my content where I built it, and let's generate results. So straight away, you can see here that we've flagged up the, the Log four j, software. Here it is on the artifact location. So that's coming up as the stuff that's now failed in this particular image or this particular repo, which only has one image in it anyway. So this is a critical thing here is that we're not notifying on things found in in Chainguard. If you want to see the things in Chainguard, let's apply this label. And now you can see we're calling out the the medium severity, here we go, the medium severity issues in the original WordPress image, which for a lot of people, that's not a worry. High or critical is perhaps where you're you're more interested. So so the good example of how we can generate this information, which is either just about the chain guard images, perhaps indicating, yep, maybe go look for a renewal of the, upstream from from Chainguard, pull that new thing in. Or if we flip it over, let's not worry about Chainguard. Let's just only worry about the content we've developed or we've added on top. Let's get a notification about new vulnerabilities which have appeared here. So the final part of this would be to obviously, let's save this report, issues in my, WordPress blog. You probably wanna schedule this so that maybe, you know, every Monday, I come into the office at 09:00. And, I have the information here about things which are now out of compliance because of these critical vulnerabilities. So this could be then connected to, you know, email or, you know, GitHub to generate a ticket. All the information is all stored within Anchore ready to be pulled out programmatic if you want to have it, you know, bring this into your custom sort of GRC, management tool. But all the information about the compliance state, either the change out images or for the content is available within Anchore. Okay. I'll pause there after a quick quick demo, and I will now pass it back to I think going back to Lenny to, close this out. Yes. Hello, everybody. Neil, Brad, Tazeen, if you don't mind staying on, we are going to do a little bit of q and a. Let me just pull this up. Great. Lee, does Anchore have a way to easily provide metrics slash reports on the provenance container images being scanned in a given context? So it just come off mute there. I'm not quite sure of the question. Why metric reports on the provenance container images? Yeah. I don't if you could rephrase the question, I'm not quite sure what that is. If if it's about the provenance data that, that Chainguard has, that's not pulled in, to the system. I was certainly interested in exploring sort of, you know, secondary validation and the provenance information about what it's about. But, Yeah. I don't know. Maybe if if if rephrase the question on the q and a, that would be helpful. Sorry. Lee, feel free to jump in if you have a little bit more context, for for Neil. In the meantime, we'll move on from Sam. Moving to a continuous compliance approach makes a ton of sense, but involves a pretty significant cultural shift in how software is built. What kind of recommendations do you have for an org looking to start to making this shift? Would you start with third party OSS apps versus base images with custom code on top? Brad or Neil, I'm not sure if if, I can give a I can start. Something that I've seen worked really well, we have, like at at Chainguard, we've got the 1,700 images, and many of our customers now are on our new contract pricing, which means you get access to all 1,731 of them or or some portion thereof. And what that gives developers is the ability to, you know if they have a need for something, how would they do that without Chainguard? They would probably go to TalkerHub. They would do a search. They'll do this Internet search, and, you know, kinda find out which technology they need, and then they'll go and pull that from somewhere. And by restricting, you know, the usage of things like Docker Hub, you're offered often introducing friction that developers kind of try to skirt around because they're under a lot of pressure to to shift. Right? So, basically, what what I'm getting to is, it it makes a lot of sense to make these the software that you've purchased available to developers to see, to kind of go through and, you know, pick the technologies that they need as they're prototyping their application, and and be able to kind of get a a hub like experience. And I also think just kind of standardizing as an organization on our, our base image. So whether they're they're developing in Python, they can add that Python to their online and their Docker file. You know, there's not zero friction for migrating, but if you're getting started, a lot of times that's an easy way to kind of slipstream these things into your, developer workflows in a way that kind of starts that cultural shift of starting with known good, to happen. Neil, you got Yeah. No. I've I've nothing to add. I was I was gonna go back and answer the, it looks like, Lee added some additional context on their the first question. So what should I go back and let me take that up? So, Lee said that Chainguard images have labels in them to indicate they were sourced from Chainguard, also signed. We'd like to be able to query Anchore to see how many images are based on Chainguard versus other sources. So, yes, we we capture all that information. You can generate reports showing, you know, total images may be deployed. We have an integration, say, with Kubernetes. You can say how many images deployed came from the ChainGuard repo versus from alternative repos. So, yes, we we have all that information if you need to generate an inventory or inventory. Sorry. I don't remember the right pronunciation in The US. So all of that information is stored, and, yes, you can you can sort of see the breakdown on sort of, you know, Red Hat versus a book two versus, Chainguard and so on. So Awesome. Great, Neil. Thank you. From Antoine, what is free for use and not? I can start on the Chainguard side. We do have there's two versions of our operating system. One is Wolfie, the other is Chainguard OS. And they're essentially, you know, the same thing except, you'll find a more complete set of things like APK packages, in Chainguard OS. We if you look at, like, Docker Hub, you'll find a handful a number of, images that we shipped that are open source and free to use, with the caveat being that we only maintain the latest tag on those things. So, you can always access the latest version there. And, you know, you don't use that software as long as that that works for you. Great way to try out these images, you know, give them some scans, you know, to see how they work for you before you talk to a salesperson or, do a demo. I'll also jump in with that. If you navigate to images.chainguard.dev, the site that I was demoing earlier, there's a section called starter. So those are all of our starter images. Those are freely available, just the latest version. But, yeah, easy it's easily accessible by anybody who who's looking to trial Chainguard. And then on the anchor side, so the anchor, enterprise product, that's that's commercial software. We obviously you know, we can do trials and, thirty day trials and so on. But we do have some open source tools which, you know, can help customers get familiar with the data that, is generated, by Anchore. So we have Sift, which is on GitHub, slash Anchore, which is a misbom generator. We have GRIpe, which is a vulnerability generator. We have Grant, which is a license information generator. So these are the same, technologies we use in our commercial products. They they generate the data. Obviously, you don't get the the storage of the data, the processing, the policy evaluation, which is where Anchor Enterprise comes in. Great. And, Bonnie, I saw your question, and I just responded directly with the agenda items. Hopefully, that, gets you what you need, but let me know if not. Jacob, when will Anchore STIG support the published Chainguard, DISA STIG profile or DISA STIG profile? Yeah. So STIG is actually something we didn't cover. STIG is the, is one of the compliance frameworks within the US government. So if you're running, a, if you're running software as a government user, you have to apply a STIG profile, which is a security technical implementation guide. It's essentially a set of security checks you have to go through. That's now become relevant for enterprises because if you're, applying for FedRAMP, you also have to now go through some STIG, effort yourself to prove that you're STIG ing, as it's called, your images. So Anchore does have a capability, to evaluate STIG, the STIG compliance. It's more about violations. Compliance has to be done in run time, but we can certainly look for violations early. So we do currently support, some major operating systems. Yes. It is a it is a good question. We haven't done work with Chaingard yet. That might be next on the road map if that's of interest. We may be focusing on the some of the compliance and vulnerability pieces you saw today. But, if that's of interest, I'm very happy to, look at getting that integrated as a supported profile within our our STIG, feature. Great. Thank you, Neil. From Darren, what protection do you offer against supply chain attacks, AKA pinning known good LTS images? You know, I think the best defense against supply chain attacks, is keeping everything up to date. If you're talking about an LTS version of, say, Postgres, you know, you know, vulnerabilities can be introduced or discovered post release. But the the way that you prevent supply chain attacks is, one, having knowledge of all of the provenance of all the software. You know, open source images are constructed of many different pieces of software that are pulled from different repositories. And so you want to know that the image that you got is constructed by who you think it was and and then nobody have the opportunity to put something in there, that's not that's not the intended, binaries or code. And then I would just say that, again, you know, keeping everything fresh, which is what we do. We you know, whenever there's a, an update, we apply that to the latest image. Even if it's an LTS version, we're still, you know, say, like a library or a a system package in that image has a vulnerability or very quickly patching that. So you're using the LTS version, but you're also getting everything else in the stack up to date, and you're, you know, ensuring that you have proof of provenance of all the software, in your images. And then on on the Anchore side, we so our policy engine, which I sort of briefly touched on there, where we have these policy packs for, you know, NIST 800 or FedRAMP and so on and so forth. The policies can also be extended to say, what do you allow where content can come from. So you can sort of put up a deny, which is, like, don't allow users to, download any any software except from a Chainguard repository, for example. So you can prevent people mixing and matching from different sources. So we do have some controls around origin of content. You can also with a policy control, I sort of briefly touched on this. You know, we capture not just the packages, but literally everything in the on the file system. So you can actually, say, you know, only this version of this package is allowed or even only this checksum of the file is upheld or, if you're worried about people maybe renaming, you know, packages or you've got custom bills or so on and so forth. So a policy language does allow you to say only allow or, you know, this particular file or this particular version or the inverse, you know, deny anything, you know, these kind of packages or these versions and so on and so forth. So yeah. So we do have policy control for you to sort of do effectively pinning within the system. But, yep. You know, I agree with Brad here, which is that, often, you know, just up I think it's a large part of the value proposition of of, of Chainguard is just update and let them worry about the sort of the the the quality of, the software that's coming in and the verification. One one more thing I'd add quickly to that that we focus on is, reducing the threat surface area by only including the software in an image that needs to be there. So you won't find anything in the executable path on the chain guard image that doesn't actually need to be there and that thereby therefore, kind of reduces your your threat surface area for images. Awesome. Well, thank you so much, everyone. We really appreciate, you joining us today. And thanks, Neil, Brad, Tazeem. So great having you on. Thank you very much. Thanks. Thanks so much for joining us.