TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Most Kubernetes clusters waste over half their resources, and sharing a cluster between teams makes the problem worse. A single bad guess at a resource limit turns into an outage nobody expected and a cloud bill nobody can explain.

Join Vikram Seshadri (Senior Evangelist, PerfectScale) and Hili Paryenti (Director of Product, Attribute) live on Sept 29 @ 11am ET to see how to fix it.

Learn How to Operate Kubernetes Multitenant Clusters Practically in Live.

Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Most common scenraio I see: A platform team ships a container image built on a base OS layer from six months ago. Nobody flagged it during code review because code review checks application logic, not the hundreds of OS packages bundled inside the base image. Three weeks later, a CVE disclosure lands for a library buried deep in that base layer, and the security team discovers the image has been running in production the entire time with a known remote code execution vulnerability. This is not a hypothetical. It is the default outcome of any pipeline that builds and deploys container images without a scanning step, and it explains why image scanning has become as standard as unit testing in mature Kubernetes environments. The question that actually separates teams is not whether to scan, but where in the pipeline that scan happens.

The most common starting point is scanning immediately after the image builds, before it ever reaches a registry.

A developer commits code to a Git repository, which triggers Jenkins and GitHub to build the image. Before that image gets pushed anywhere, Trivy and Snyk scan it for vulnerabilities. The scan results feed back to the developer directly, showing a breakdown by severity, critical, high, medium, and low, along with specific alternative base image versions that reduce the vulnerability count. Only after this check does the image get pushed to the image registry.

This example shows a real scan output: the current image carries 629 vulnerabilities, including 34 rated critical. The scanner surfaces four alternative base images, one of which cuts that number down to 55 vulnerabilities with only 3 critical, and offers an actionable fix PR the developer can open directly from the notification. This is the strength of build-stage scanning: the person who introduced the vulnerable dependency finds out within minutes, while the context of what changed is still fresh in their head.

The limitation is equally direct. This check only catches what existed in the image at build time. A base image that was clean on Monday can have a new CVE disclosed against it by Friday, and nothing in this workflow rescans an image that already sits in the registry.

To catch vulnerabilities disclosed after an image has already been pushed, scanning can move into the registry itself, running on a recurring basis against everything stored there.

The build and push steps look identical to before, Jenkins and GitHub build the image and push it to the registry. But now the registry deploys that image to a running environment first, and separately triggers Trivy and Snyk to rescan it on a loop, shown by the circular arrow feeding back into the Scan block. Scan results flow back the same way, notifying the developer with the same severity breakdown and upgrade recommendations.

This closes the gap the build stage only approach leaves open. An image sitting untouched in the registry for months still gets rescanned periodically, which means a newly disclosed CVE against a package already deployed in production gets flagged without requiring a new commit or a new build. The tradeoff is timing: an image can be deployed and running before its next scheduled rescan catches an issue, so this pattern works best as a supplement to build time scanning rather than a replacement for it.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)