A Deeper Look into the Continuous Verification Capability of Chainguard Enforce

Back in April we announced Chainguard Enforce, our comprehensive software supply chain risk management solution for containerized workloads. One capability that’s resonated with our early customers is what we call “continuous verification.” Security threats don’t stop at deployment time. If the container image can be deployed with no vulnerabilities today, who’s watching to make sure it doesn’t slip out of compliance tomorrow?

Software supply chain information is never stagnant. There are a number of solutions in the market for preventing vulnerable images from being deployed into production, but insufficient for mitigating certain types of supply chain attacks. For example, software composition analysis (SCA) tooling can tell you at deploy time, but what if a tool is installed during debugging or installed into a running deployment? Attacks that target a known CVE also fall into this category. Log4shell is one such incident that comes to mind. We spoke to many organizations that went through tedious amounts of work over the holidays to understand if they were running infected packages in their production environments. It doesn’t have to be this difficult!

This is where the continuous verification feature comes in. It continually verifies that software artifacts are compliant with the latest defined policies and known information (such as CVEs), and enforces even after the initial deployment. It enables your organization to have a continuous “inventory” of everything that is currently running (and what previously ran!) in your kubernetes clusters. This includes what packages are deployed, SBOMs, provenance, signature data, etc. It’s now possible to understand if, where and when a vulnerable image previously ran. The time to resolution (TTR), such as in the log4shell example, turns into seconds instead of weeks.

One of our favorite features is that before you enact a new policy which, for example, blocks deployments, continuous verification will let you know which components would fail this policy if the current versions of these components were to be re-deployed today. Especially in cases where deployment decisions are left up to individuals or individual teams, you may not have insight into the types of things that developers are shipping as it relates to metadata such as SBOMs and digital signatures (and against which root of trust etc.). Even without adding any policies, continuous verification will attempt to consume this type of information to help you make informed decisions regarding policies, and let you know just how similar or different these components are.

Last but not least, a few other notable features worth mentioning:

To recap, implementing restrictive new policies is effective at preventing security incidents and achieving compliance, but this does not account for the various software components that are already running in your production environments. Continuous verification will evaluate running components against your latest policies to keep you informed about the actual state of things, and help you determine how close you really are to meeting compliance requirements. We’re using Chainguard Enforce in our own production environments, and it has already caught a few issues for us! If this is a capability you’d like to test drive and learn more about, please reach out. We’d be happy to schedule a demo and/or provide you with a test environment to kick the tires.