Understanding Kubernetes Image Scanning Workflow

Author

Govardhana M K
October 11, 2025

In partnership with

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.

👋 A big thank you to today's sponsor THE CODE

Find out why 100K+ engineers read The Code twice a week

Staying behind on tech trends can be a career killer.

But let’s face it, no one has hours to spare every week trying to stay updated.

That’s why over 100,000 engineers at companies like Google, Meta, and Apple read The Code twice a week.

Here’s why it works:

  • No fluff, just signal – Learn the most important tech news delivered in just two short emails.

  • Supercharge your skills – Get access to top research papers and resources that give you an edge in the industry.

  • See the future first – Discover what’s next before it hits the mainstream, so you can lead, not follow.

👀 Remote Jobs

📚️ Resources

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

🧠 DEEP DIVE USE CASE

Understanding Kubernetes Image Scanning Workflow

You may not have missed the recent supply chain attack that hit the npm ecosystem. In September 2025, attackers gained access to maintainer accounts and injected malicious code into popular packages like debug and chalk, silently compromising thousands of systems within hours.

Container images face the same risk.

Do you really know what’s inside the containers you run?

Do you trust the base image you pulled from a public registry months ago?

Do you verify every update before it moves from staging to production?

These are the questions that shape your image scanning workflow, the foundation of securing Kubernetes workloads before they ever reach the cluster.

First things first. Let us understand the most common types of image scanning you would see.

Image Scanning as a Part of the Build Process

The earliest point to start scanning images is during the build itself. As soon as an image is created, scanners like Trivy or Snyk can inspect it for known vulnerabilities before it ever reaches the registry.

In this approach, every image is scanned right after it is built. The scan runs as part of the CI job triggered by a developer’s commit. Once complete, the scanner provides a verdict. If it passes, the image is pushed to the registry for use. If it fails, the developer must fix the issue before the latest build becomes available.

This approach helps surface issues early, but it comes with trade offs:

  • Frequent scans slow builds - limit to key branches or run on schedule.

  • Rebuilding base images triggers redundant scans - use pre scanned bases.

  • Outdated CVE feeds create blind spots - sync databases regularly.

  • Too many alerts reduce focus - fail only on high or critical issues.

❝

Build time scans show only what exists at creation. New vulnerabilities found later will still require re-scanning at the registry or cluster level.

Image Scanning Integrated Within the Image Registry

In this approach, as soon as a commit is pushed, the CI pipeline builds the image and pushes it to the registry. The registry then takes over scanning responsibility. Integrated services perform periodic scans to detect vulnerabilities in stored images.

This model ensures that images already in use are not forgotten. Even if a vulnerability is disclosed after deployment, the registry can flag affected images and notify teams. It shifts scanning from a one-time check to continuous visibility.

However, there are some considerations to keep in mind:

  • Registries often scan only new uploads - configure periodic rescans to catch new CVEs.

  • Scan coverage depends on registry features - not all support deep analysis or multi arch images.

  • Results can be delayed if scanning queues build up in busy environments.

  • Some registries require extra permissions or paid tiers for advanced scanning.

❝

Registry integrated scanning provides ongoing protection, but it should complement build time checks. It is most effective when used to monitor already published or long lived images.

Image Scanning Inline as a Part of the CI/CD Process

Here, image scanning is embedded directly into the CI/CD pipeline, operating inline with security policies before any image is pushed to the registry. The scan results are evaluated against defined rules, and only compliant images move forward through the pipeline. Anything that fails policy checks is blocked immediately.

Still, some points need attention:

  • Inline scans can increase pipeline execution time - balance between depth and performance.

  • Security gates must align with real world policies - overly strict rules can block valid releases.

  • False positives should be tracked and triaged instead of being ignored.

  • Integration with version control and CI tools needs careful tuning to avoid build failures on configuration changes.

❝

Inline scanning enforces security as part of delivery, not after it. It is best suited for mature CI/CD setups where automation and policy management are already in place.

With this basic understanding, let us get into the prime context of image scanning in the Kubernetes ecosystem.

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 200+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session