News
Denis Maligin exposes the vulnerability nightmare hiding in your containers
Container adoption has exploded across every environment imaginable: from massive datacenter platforms to resource-constrained edge deployments. Each promises faster deployments, better scalability, and simplified operations. Yet beneath this containerized utopia lurks a shared nightmare: vulnerability chaos that spans every Kubernetes cluster, every edge node, and every container registry.
At Edgecase 2025, Denis Maligin, Sr. Sales Engineer at Chainguard, didn't just talk about this problem, he dissected it live on stage. To stay in line with the subject of the Multiverse Saga, Denis sees two parallel universes: datacenter and edge. They have different requirements, but similar challenges.
As Kubernetes has evolved, we’ve seen multiple “timelines” emerge: the original path of large-scale platform engineering, and a divergent path where Kubernetes powers constrained edge environments. Each universe has its own challenges, yet one problem spans them all - vulnerability chaos in container supply chains.
Weakest link in modern infrastructure
Today’s attackers don’t need to break your code—they exploit the components you rely on. Legacy base images, sprawling CVE lists, and incomplete SBOMs have made the software supply chain the weakest link in modern infrastructure.
In his talk, Denis took a technical look at modern approaches to redefining supply chain security. He taught us how minimal, continuously updated, signed images with complete SBOMs can eliminate entire classes of vulnerabilities before they ever reach production. Added to that were some quality memes, mostly made by Denis himself.
Some of the subjects Denis talked about
- The risks hidden in traditional “hardened” images
- Why SBOM completeness and provenance matter for compliance and security
- Continuous patching and digest pinning to reduce operational burden
Security at the source
Denis: “It's mostly quite difficult to infiltrate and change the source code of the open source projects. It's almost impossible, I would say. But interfering with the supply chain, with the build process, as we're seeing every week, it's quite possible. What's the solution to that? How would I be able to protect myself from this? Security at the source is the safe source for an open source.”
Live demos: Grype > Trivy
The best part of the talk was a live demo, or four demos actually, where Denis compared common public images with hardened alternatives, showing how teams can eliminate CVE noise, improve pull performance, and build supply chains that are truly verifiable. Scanning a legacy image versus a minimal, continuously updated image might seem brutal, and the outcome was indeed brutal.
Both Trivy and Grype are great open-source tools for scanning container images and other software artifacts for vulnerabilities and misconfigurations. But during a live demo, Denis showed us why Chainguard prefers Grype over Trivy. The most important reason is that Trivy doesn’t display results for Alpine when scanning for vulnerabilities.
In another demo, he showed the audience how easy it is to manipulate the metadata and deceive the scanning tools. In other words, these tools give a false sense of security. To show this can be detected when you use the right tool, Denis introduced Sigstore. This tool makes trust cryptographically verifiable.
Proven strategies bring order to this chaos
And so we learned how mutable tags, bloated base images, and metadata-driven scanners create unpredictable risks across environments. Why traditional patch cycles lead to persistent CVE debt, and how these challenges play out differently in datacenters versus edge deployments.
Most importantly, Denis gave us proven strategies to bring order to this chaos: reproducible builds, digest-based deployments, minimal images with smaller attack surfaces, and the use of SBOMs and signed provenance for compliance.
At the end, Denis encouraged everyone to go to https://images.chainguard.dev and download their free ZeroCVE images to use in their projects. Because declarable and reproducible builds are the root of trust.
