Skip to Main Content
Talk Intermediate Grype (Apache 2.0), Trivy (Apache 2.0), containerd (Apache 2.0), Apache 2.0, MIT, GPL-2.0

80% of Your Container CVEs Live in Code You Didn’t Write

Proposal status is Rejected
Session Description

You patch a CVE in one microservice. Next sprint, the same CVE appears in fifteen others. You patch those. The sprint after, three new ones. If this is your security backlog, the problem is not your scanner — it is where you are fixing things.

Roughly 80% of container vulnerabilities do not live in application code. They live in shared base images — the OS layer, the language runtime, the shared libraries that every microservice in a fleet inherits. Scanning detects them downstream, after deployment. Every service inheriting the same base image multiplies the remediation work. The result is not reduced risk; it is compound interest on technical security debt.

This session reframes container security from an operational treadmill to an architectural decision:

  • The economics of CVE multiplication — one vulnerable base image × 20 inheriting services = 20× the remediation work, with each sprint

  • Live demo: dissecting a public ubuntu:22.04 base image with Grype to show exactly where the CVEs originate (OS layer vs. app layer)

  • The foundation-layer fix: consolidate to a minimal, hardened base image, rebuild once, propagate downstream

  • Before-and-after metrics from switching to pre-hardened base images — CVE backlog reduction and sprint-hours reclaimed

This is tool-agnostic and works with any scanner (Grype, Trivy, Snyk OSS). Attendees leave with a concrete process they can begin this sprint. 

Key Takeaways

  1. A CVE remediation decision framework: criteria for whether to fix a vulnerability at the base layer or the application layer — so the same CVE stops reappearing across every inheriting service.

  2. A base-image hygiene checklist — consolidate base images → rebuild from a minimal/hardened source → propagate downstream — executable within one sprint using Grype or Trivy.

  3. A method to calculate CVE remediation multiplication (vulnerability count × dependent service count) in your own fleet, to quantify the cost of downstream patching and build the case for foundation-layer investment. 

References

https://github.com/anchore/grype
https://github.com/aquasecurity/trivy
https://www.cisecurity.org/benchmark/docker
https://nvd.nist.gov
https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf
https://www.cleanstart.com

Session Categories

Engineering practice - productivity, debugging
Talk License: Grype (Apache 2.0), Trivy (Apache 2.0), containerd (Apache 2.0), Apache 2.0, MIT, GPL-2.0

Which track are you applying for?

Security

Speakers

Sanket Modi
Sanket Modi Sr Engineering Manager | CleanStart Security

Sanket Modi maintains roughly 100 hardened, open source container images, rebuilt daily and kept current through continuous version upgrades and proactive CVE remediation—so the teams consuming them inherit a clean foundation instead of a vulnerability backlog. His work centers on a single idea: most container CVEs come from the base image, not the application, so the durable fix belongs upstream, at the foundation, where it can be made once instead of patched everywhere. Over 14 years spanning SDET, DevOps, DevSecOps, and engineering management, he has moved from testing and operating systems to building the secure foundations other teams build on, and now leads community efforts at CleanStart Security. He spoke on container security at KCD Delhi 2026, and regularly writes and runs community sessions on supply-chain integrity, image hardening, and reducing security toil for developers. He believes the best security is invisible—embedded in the foundation so teams focus on shipping products, not managing CVE queues. KCD Delhi was a first step toward larger cloud native stages. 

https://www.linkedin.com/in/sankethmodi/