Container Image Security Scanning in CI/CD Pipelines
A scanner doesn't look at your application code in isolation. It inspects every layer of the image: the base OS packages, application dependencies across ecosystems like npm, pip, and Maven, compiled libraries, and configuration artifacts baked in at build time. That layered inspection is the strength, and it's also why the scope of what you scan matters as much as whether you scan at all.
Vulnerability categories extend well beyond CVEs in OS packages. A properly configured scanner surfaces hardcoded secrets and credentials embedded in image layers, misconfigurations like containers running as root or exposing unnecessary ports, license violations in open-source dependencies that create legal exposure, and end-of-life software components that will never receive a patch. Teams that configure their scanner narrowly, chasing CVE counts alone, leave every other category completely invisible.
The gaps are where things get expensive. If your image is only scanned at build time and never again, CVEs disclosed after that build date accumulate silently. Runtime drift, packages installed, files modified, or processes spawned inside a running container after deployment, is entirely invisible to build-time scanning. Secrets introduced at runtime via environment variables or mounted files never appear in image layer analysis. These aren't edge cases. They're predictable, and they go unnoticed precisely because the initial scan passed.
There's also the attack surface that CI/CD itself creates. Compromised build systems, poisoned dependencies, and supply chain injection can introduce malicious artifacts that look clean to a scanner pointed only at application code. Scanning must cover the artifacts the pipeline actually produces. Small teams without dedicated security staff are especially exposed here because no one is systematically watching for drift or re-scanning stored images on a schedule. The gap isn't negligence; it's bandwidth, and bandwidth is exactly what small teams don't have.
The Three Stages Where Scanning Belongs in a CI/CD Pipeline
Each stage catches a different class of risk, and a runtime finding frequently means something slipped past both build-time and registry checks. That's useful diagnostic information, not just an operational headache.
Stage 1: Build Time
Scan every image on every commit and pull request before it can be merged or promoted. Fail the build on findings that meet your defined severity threshold. This is the earliest intervention available, and it establishes a floor: nothing ships without being checked against known vulnerabilities at the moment it was built.
Inline scanning, meaning scanning directly in the pipeline before pushing to any registry, eliminates the risk of credentials or malicious artifacts reaching an intermediate registry before vetting. If your pipeline pushes first and scans second, there's a window during which a compromised image exists somewhere that other systems are polling. The window is small, and it's entirely avoidable.
Pre-commit hooks sit even earlier. They catch secrets before those secrets leave the developer's laptop. Secret scanning at this stage is the cheapest remediation you have: rotation before exposure, not rotation after.
Stage 2: Registry
Images sitting in a registry accumulate risk on a schedule that has nothing to do with your build cadence. A CVE published six weeks after your last build applies to every image in your registry containing the affected package. Without scheduled rescanning, you have no visibility into that accumulation.
Daily or weekly scheduled rescans catch disclosures that postdate the original build. For teams already operating on a single cloud provider, this is the lowest-friction path available: AWS ECR with Inspector, Azure ACR with Defender for Containers, and GCP Artifact Registry with On-Demand Scanning all provide continuous rescan capabilities without additional tooling. You're paying for the infrastructure regardless. The scanning integrations are often included or inexpensive.
Stage 3: Runtime
Runtime scanning detects drift, specifically packages installed, files modified, or processes spawned inside a running container after deployment. It also surfaces credentials exposed in running workloads via environment variables, which no amount of image-layer analysis will find.
For Kubernetes environments, admission controllers function as a policy enforcement layer at the scheduling level, blocking unscanned or policy-violating images before they ever run. For small teams, this provides a backstop that compensates for the moments when someone deploys directly from a local build. That happens more often than anyone wants to admit.
Choosing a Scanner: What Trivy, Grype, and Snyk Each Actually Do
The tools are meaningfully different in ways that affect small teams specifically, and picking the wrong one creates friction that compounds.
Trivy
Trivy, maintained by Aqua Security, has accumulated over 36,500 GitHub stars and operates as a single binary covering containers, infrastructure as code, secrets, licenses, and Kubernetes clusters. It absorbed tfsec, so Terraform scanning comes bundled. For teams who want one tool across container and infrastructure security without paying for it, Trivy has been a widely recommended default.
One significant caveat: Trivy's release infrastructure was reported as compromised in a supply chain incident in March 2026, with attackers allegedly hijacking GitHub Actions tags and pushing malicious images to Docker Hub, and vulnerability database updates were reportedly suspended as of March 25, 2026. Before relying on Trivy for production use, verify its current recovery status and database freshness against Aqua Security's official communications directly.
Grype
Grype, from Anchore, does one thing: vulnerability matching against known CVEs. No IaC scanning, no secrets detection, no license checks. Its real differentiator is composite risk scoring that combines CVSS severity with EPSS score, which is the probability of exploitation within 30 days, and CISA KEV catalog status. That combination surfaces the most actionable findings first.
A critical CVSS score reflects theoretical severity in a lab context. A CVE with a critical CVSS score but a 0.1% EPSS probability and no presence in the KEV catalog is a fundamentally different problem than a high-severity CVE with a 95% EPSS score that appears in the KEV list, meaning it's being actively exploited right now. Treating them identically is how pipelines fill up with noise and developers start ignoring scan results entirely. Grype's composite scoring cuts through that.
Grype also runs faster than Trivy for pure vulnerability scanning. In a pipeline that runs on every commit, seconds accumulate. It works well as a second-opinion scanner on critical or externally facing images precisely because Trivy and Grype use different databases and matching engines, and their blind spots don't overlap.
Snyk
Snyk is a commercial tool. Its clearest differentiation is developer experience: IDE integration, automated fix suggestions that surface the minimum necessary package upgrade or base image change, and remediation guidance that's actually context-aware. It maintains its own vulnerability databases, which often identify risks ahead of public databases.
The limitations are real. Snyk is primarily cloud-hosted, and full functionality requires sending data to Snyk's servers, which makes it impractical for air-gapped or heavily regulated environments. Costs can escalate substantially as repository counts grow. For developer-first organizations with commercial budget who prioritize remediation guidance over raw scanning speed, it's a strong choice. For a five-person team watching infrastructure spend, it warrants careful evaluation before commitment.
Recommended Configuration for Small Teams
Use Trivy or Grype as your primary CI/CD scanner and run Grype as a second-opinion pass on high-risk or externally facing images. If you're already on a single cloud provider, layer in native registry scanning as a continuous complement. Different databases, different detection methods: the goal is coverage that's deliberate, not duplication for its own sake.
Shrinking the Attack Surface Before Scanning: Minimal Base Images
The most effective thing you can do before optimizing your scanner configuration is reduce what the scanner has to look at. A standard ubuntu:22.04 image ships roughly 150 packages, including a shell, a package manager, and a collection of system utilities that have no business being in a production workload. Any of those can become a post-exploit tool if an attacker gains access.
Distroless images contain only the application's runtime. Switching from a full Python image to python:3.12-Alpine can significantly reduce OS-level CVE counts, according to analysis published by AquilaX. That reduction isn't cosmetic. Fewer actual packages means fewer actual vulnerabilities, not just fewer findings to suppress. Distroless images also start faster and are smaller on disk, which translates to faster pull times and lower registry storage costs.
The tradeoff is real: debugging without a shell is genuinely harder. Inspecting a running distroless container requires tooling and planning that a full OS image doesn't demand. Figure out your debugging strategy before you adopt distroless in production, not at 2am during an incident when you realize you have no way to inspect what's running.
Fewer packages produce fewer findings, which produce fewer false positives to triage, which means the findings that do surface are more likely to reflect genuine risk. Reduce the surface area first, then optimize the scanner configuration.
Making Scan Results Actionable: Severity Triage and What to Actually Block On
Raw scanner output on a non-minimal image can surface dozens or hundreds of findings. Teams that try to fix everything fix nothing, and eventually they start ignoring the scanner entirely, which is worse than not running it. The challenge isn't detection; it's prioritization disciplined enough that a small team can act on it consistently without a dedicated security engineer making judgment calls on every build.
CVSS scores alone aren't sufficient. A critical CVSS score reflects theoretical severity in an idealized attack scenario. It says nothing about whether anyone is currently trying to exploit that vulnerability, whether exploit code exists in the wild, or whether your specific deployment context is reachable by the relevant attack vector.
A better framework uses three inputs together. CVSS as a floor: severity below a defined threshold doesn't block the build under normal circumstances. EPSS score: the probability of exploitation within 30 days, expressed as a percentile. A finding at the 95th EPSS percentile and a finding at the 1st percentile are not equivalent problems, even if their CVSS scores match. CISA KEV catalog status: if a CVE appears in the Known Exploited Vulnerabilities catalog, it's being actively exploited in the wild and should be treated as immediate, regardless of CVSS score.
A reasonable starting blocking policy for a small team: fail the build on critical severity combined with EPSS above a defined percentile threshold, or on any KEV catalog match. High severity without active exploitation evidence gets flagged and tracked but doesn't stop the pipeline. That distinction is what keeps a vulnerability management process functional rather than one that stops deploys over theoretical risk every other sprint.
Set these thresholds explicitly in written policy. Ad hoc decisions per build produce inconsistency and tribal knowledge that disappears when someone leaves the team.
Two categories deserve special treatment regardless of CVSS score. CVEs with no available upstream fix require documented risk acceptance, not silence. Ignoring them because no patch exists is the wrong response; accepting and documenting them is the correct one. Hardcoded credentials found in an image layer should trigger immediate rotation, not just a ticket in the backlog. A credential in an image layer has potentially been sitting in a registry for months, visible to anyone with registry access.
SBOMs: What They Are, When They're Required, and How to Generate Them From the Pipeline
An SBOM, a Software Bill of Materials, is a machine-readable inventory of every component in a container image: OS packages, application dependencies, libraries, with version and origin metadata for each. In practical terms, it's the answer to "what exactly is in this image?" made persistent, exportable, and queryable after the fact.
The relationship to scanning is direct. Most scanners follow three steps: parse the image to generate a component inventory, match that inventory against CVE databases, report. An SBOM is essentially that first step made durable. A stored SBOM lets you retroactively scan an image against a CVE published months after the image was built, without rebuilding or re-pulling the image. That retroactive capability is what converts scanning from a point-in-time check into something that actually keeps pace with the threat landscape.
Regulatory Landscape
The compliance context for SBOMs has shifted substantially in a short period. US Executive Order 14028 requires SBOMs for software sold to federal agencies. The EU Cyber Resilience Act legally mandates SBOMs for products with digital elements sold in the EU. PCI DSS 4.0, fully mandatory as of March 31, 2025, requires a software component inventory that functionally constitutes an SBOM even though it doesn't use that term. Verify current CISA and HHS guidance directly for the latest requirements; this space moves fast enough that anything written down has a shelf life.
For teams in finance, healthcare, defense, or critical infrastructure, SBOM delivery is increasingly a procurement gate. Enterprise buyers and regulated customers are asking for them before contracts are signed.
Formats and Generation
Two formats dominate. SPDX, maintained by the Linux Foundation and standardized as ISO/IEC 5962:2021, is best suited for license compliance and open-source auditing; BuildKit's built-in SBOM generator outputs SPDX natively. CycloneDX, an OWASP project, is optimized for security workflows, includes vulnerability metadata and dependency graph fields, and integrates with OWASP Dependency-Track for continuous tracking across a portfolio.
For pipeline generation, Syft from Anchore produces SBOMs in either format from container images, and Grype can scan a Syft-generated SBOM directly. That modularity is worth preserving: the SBOM becomes an artifact that other tools can consume independently, not just an intermediate step in one scanner's workflow. Store SBOMs attached to the image in the registry alongside the image manifest. An SBOM stored somewhere else is an SBOM that will be missing when you actually need it.
How Scanning Maps to SOC 2 and HIPAA Controls in Practice
SOC 2 is nominally voluntary. In practice, if you're selling to enterprise buyers in the US, it functions as a prerequisite. The question isn't whether you'll pursue it but when, and whether your existing practices will hold up when you do.
SOC 2
Auditors are looking for evidence of process, not just tooling. Having a scanner in your pipeline isn't sufficient on its own. What they want to see is a documented vulnerability management process: defined thresholds, a record of findings, evidence of remediation on a defined timeline. Every image push is a change. Scan results attached to that push create an audit trail that directly satisfies change management control requirements.
Image signing and registry policies that restrict production promotion to scanned images serve as access control evidence. The auditor's question isn't "do you have security tools?" It's "can you demonstrate that your process consistently enforces your stated policies?" Automated scanning with documented thresholds and signed image enforcement answers that question in a form auditors can actually evaluate.
HIPAA Security Rule
The HIPAA Security Rule doesn't mention containers. It maps to container security through its underlying control categories. Access control maps to RBAC and network policies restricting which workloads can handle PHI. Audit controls map to centralized, time-synced logging of container activity. Integrity maps to signed images with verified provenance. Vulnerability management maps directly to your scanning discipline; consult current HHS guidance for updates to HIPAA technical safeguard requirements, as interpretive guidance continues to evolve.
The practical implication for small teams: the same scanning infrastructure, the same SBOM generation, the same signing and registry policies, serves both frameworks simultaneously. The documentation layer, written policies with defined thresholds and consistent evidence of application, is what converts technical controls into something an auditor can evaluate. Build the practice, document it as you go, and the compliance posture follows from the work itself.
