What's the difference between scanning at build time and at runtime?

Build-time scanning checks a freshly-built image before it's pushed anywhere, catching issues early in CI. Runtime/admission-time scanning checks an image right before or as it's deployed to a live environment, catching vulnerabilities disclosed after the image was originally built and pushed, which build-time scanning alone would miss.

What is an SBOM and why does it matter for image scanning?

A Software Bill of Materials is a complete inventory of every package and dependency inside an image. It's the foundation scanners use to check for known vulnerabilities, and it's increasingly required independently for supply-chain transparency and compliance, letting teams quickly determine exposure when a new CVE is announced.

Should every vulnerability found block a deployment?

Not necessarily — most teams set a severity threshold (e.g. block only on Critical or High severity, or vulnerabilities with an available fix) since blocking on every low-severity or unfixable finding could make the pipeline impractically noisy.

Why can a previously 'clean' image later show vulnerabilities?

Vulnerability databases are updated continuously as new CVEs are disclosed. An image that passed scanning at build time can later be found to bundle a package with a newly-disclosed vulnerability, which is why registries and scanning tools continuously re-scan stored images rather than scanning only once.

Does image scanning replace runtime security monitoring?

No — image scanning catches known vulnerabilities baked into the image before deployment, while runtime security monitoring watches for anomalous or malicious behavior in already-running containers, which scanning alone can't detect (such as a zero-day exploit or an attack that doesn't correspond to a package-level CVE).

DevOps

Image Scanning

IntermediateTechnique10.1K learners

Image scanning is the automated process of analyzing a container image's layers, installed packages, and dependencies to detect known security vulnerabilities (CVEs), misconfigurations, embedded secrets, or license issues before the image…

#ImageScanning #DevOps#Technique#Intermediate#ContainerRegistry #RuntimeSecurity #PolicyAsCode #GoldenImage #SoftwareDelivery#Glossary#SkillVeris

Definition

Overview

A container image bundles far more than just an application's own code — it typically includes a base OS layer, system libraries, language runtimes, and third-party application dependencies, any of which may carry known vulnerabilities that the application team didn't write and might not even be aware of. Image scanning tools address this by unpacking an image's layers, cataloging every installed package and its version (building a Software Bill of Materials, or SBOM), and cross-referencing that catalog against vulnerability databases like the National Vulnerability Database (NVD) to flag known CVEs, along with their severity ratings, so teams can decide whether an image is safe to deploy. Scanning typically happens at multiple points in the pipeline: at build time (scanning the freshly-built image before it's pushed to a registry, failing the CI pipeline if critical vulnerabilities are found), at registry/push time (many registries scan automatically on push and continuously re-scan stored images as new vulnerabilities are disclosed against packages already in the registry), and at runtime/admission time (blocking deployment of an image with unresolved critical vulnerabilities via a Kubernetes admission controller, even if it somehow made it into the registry). This layered approach reflects the reality that vulnerability databases are constantly updated — an image that was clean when built can become vulnerable weeks later when a new CVE is disclosed against one of its bundled packages, which is why continuous re-scanning of stored images matters as much as scanning at build time. Common tooling includes Trivy, Grype, Clair, Snyk Container, and cloud-provider-native scanners built into ECR, Artifact Registry, and similar services. Beyond CVE detection, many scanners also check for hardcoded secrets accidentally baked into an image, misconfigurations (like a container configured to run as root unnecessarily), and open-source license compliance issues. Image scanning is a foundational DevSecOps practice — it shifts vulnerability detection left, from 'discovered in production during an incident or audit' to 'caught automatically in the CI pipeline before the image is ever deployed,' and is frequently a required control in compliance frameworks governing containerized production environments.

Key Concepts

Analyzes container image layers, installed packages, and dependencies for known vulnerabilities
Generates a Software Bill of Materials (SBOM) cataloging everything inside an image
Cross-references packages against vulnerability databases (e.g. NVD) with severity ratings
Performed at multiple pipeline stages: build time, registry push, and runtime/admission
Continuous re-scanning of stored images as new CVEs are disclosed over time
Detects hardcoded secrets, misconfigurations, and open-source license issues beyond CVEs
Common tools: Trivy, Grype, Clair, Snyk Container, and cloud-native registry scanners
Can be configured to fail CI pipelines or block deployment above a severity threshold

Use Cases

Blocking CI/CD pipelines from deploying images with critical, unpatched vulnerabilities

Generating SBOMs for compliance and software supply-chain transparency requirements

Continuously monitoring previously-scanned images for newly disclosed vulnerabilities

Detecting accidentally embedded secrets (API keys, credentials) baked into an image

Enforcing runtime admission policies that reject images with unresolved critical CVEs

Auditing third-party or public base images before adopting them in production

Frequently Asked Questions

From the Blog

AI & Technology

Generative AI Explained: From Text to Images

Generative AI creates new content from patterns it learned — understand how text generation, image synthesis, and more work.