Container Vulnerability Scanning for GitOps
September 25, 2026•CloudCops
Your GitOps pipeline is green, the image has been pushed, and Argo CD is ready to synchronize it. Then the scanner reports a long list of high-severity CVEs, many inherited from a base image, some already patched by the distribution, and others attached to code your application never loads. Developers stop trusting the findings, security teams start approving exceptions manually, and the control designed to reduce risk becomes another source of deployment friction.
Container vulnerability scanning works best when it produces decisions, not just alerts. In a production Kubernetes environment, that means combining image analysis with software bills of materials, reachability-aware triage, registry controls, admission policies, and runtime visibility. The practical question isn't whether to scan. It's how to make scan results useful enough that engineers act on them without bypassing the process.
The Reality of Container Vulnerability Scanning
The first scan usually feels like a security breakthrough. A CI job unpacks an image, finds vulnerable packages, and posts a report to the pull request. The second scan is where operations become difficult. Every rebuilt image may contain findings from the operating system, language libraries, transitive dependencies, and inherited layers, while the same underlying issue appears across several services.
A scanner doesn't inspect a container as a running process. It decomposes the image into layers, identifies operating system packages and application dependencies, then matches that inventory against vulnerability databases such as the National Vulnerability Database. This approach catches known flaws in outdated packages and embedded libraries before deployment. It also explains why a small application can produce a large report, because the image contains more than the code the application actively executes.
A useful introduction for teams establishing the practice is this guide to vulnerability scanning from Technovation LLC. For application libraries specifically, software composition analysis adds dependency context that a purely operating-system-focused image scan may miss.
What the scanner can and can't see
Container scanning became a mainstream DevSecOps practice rather than an optional add-on. A 2018 DevSecOps Community Survey summary reported that usage of container and application security tooling rose from 23% in 2017 to 56% in 2018, while nearly half of respondents were already using security products to identify container vulnerabilities. Among organizations with mature DevOps processes, almost two-thirds were scanning containers for vulnerabilities.
That shift made sense because production exposure remained widespread. A widely cited industry figure reported that 87% of container images in production had high-severity vulnerabilities, up from 75% the previous year (SentinelOne). The figures shouldn't be treated as a complete measure of exploitability, but they do show why teams can't rely on manual review or developer awareness alone.
Practical rule: A scan tells you what known vulnerable components are present. It doesn't tell you, by itself, whether an attacker can reach the vulnerable code or what happens when the workload is running.
Known-vulnerability matching has hard boundaries. It won't reliably identify zero-days, runtime-only attacks, insecure permissions, exposed secrets loaded dynamically, or malicious behavior that leaves no known package signature. Treating a clean image report as proof that a workload is secure creates false confidence. Treating every finding as an emergency creates alert fatigue.
The useful middle ground is to preserve the inventory, record the image digest, identify the component's origin, and add deployment and runtime context before deciding whether to block, remediate, mitigate, or accept the risk.
Mapping the Container Security Lifecycle
A container moves through several security decisions before it serves traffic. The developer builds it, the scanner analyzes it, a reviewer validates the result, a GitOps controller deploys the declared digest, and runtime controls observe what the process does. Each stage answers a different question.
Build and scan
Build-time scanning should inspect both the final image and the materials used to create it. The final image reveals what will be shipped, while dependency analysis can trace packages back to lockfiles, manifests, and parent images. Pinning base images by digest makes the result reproducible and prevents a mutable tag from changing without notice between validation and deployment.
The scanner's output should be attached to the immutable image identity, not just to a repository tag. A tag such as api:release can move. A digest gives the registry, pipeline, admission controller, and auditor a shared reference to the artifact that was assessed.
Validate and deploy
Validation is where raw findings become a release decision. A platform team might allow a known issue in a development namespace when no fixed package exists, require an approved exception for staging, and block the same image in an internet-facing production workload. That isn't inconsistency. It's risk policy applied to different environments.
GitOps adds an important control because the desired state lives in version control. The pull request can carry the image digest, SBOM reference, scan summary, exception record, and policy result. Argo CD or Flux then reconciles only the reviewed declaration. The deployment path remains automated, but the evidence stays connected to the change.
Monitor the running workload
Static image analysis can't detect runtime attacks, and it can't reveal every risk introduced by Kubernetes configuration. A workload may run with excessive privileges, access files outside its intended scope, make an unexpected outbound connection, or load behavior that wasn't visible in the static package inventory.
Runtime monitoring therefore complements, rather than replaces, image scanning. It can observe process execution, filesystem access, network activity, privilege changes, and drift from the approved image. A strong lifecycle uses static evidence to prevent avoidable risk and runtime evidence to detect what the build process couldn't know.
A secure image is an approved starting point, not a security guarantee for the process that runs from it.
Integrating Scans into GitOps and CI/CD Pipelines
The most effective pipeline design gives engineers feedback early, applies a clear release gate later, and enforces the final decision at the cluster boundary. A single blocking job at the end of a long pipeline is easy to resent and easy to bypass.
Start with pull requests. Build the candidate image, scan it, and post a concise comment containing the image digest, affected component, severity, fixed-version information, and policy outcome. Keep the full report in an artifact store or security system. Developers need a short explanation of what changed and how to fix it, not an unfiltered export of every database match.
A practical flow looks like this:
- Pre-merge feedback: Scan the changed image and relevant dependency manifests. Highlight new findings introduced by the pull request rather than redisplaying the entire historical backlog.
- Registry promotion: Require a successful scan before promoting an image from the build registry to an environment-approved registry or repository. Record the SBOM and result against the digest.
- GitOps declaration: Commit the approved digest to the environment repository. Store exception references and policy metadata next to the manifest so reviewers can see why the image is permitted.
- Admission enforcement: Use a Kubernetes admission controller to reject images without an approved digest, current scan evidence, or the required policy status.
- Continuous reassessment: Rescan retained images as vulnerability intelligence changes, even when the image itself hasn't been rebuilt.
The CI/CD security guidance from CloudCops is useful context for placing these controls inside an auditable delivery workflow. The important design choice is to avoid making the scanner the only authority. The pipeline should publish structured evidence, while policy code decides what evidence is sufficient for each environment.
Make failures predictable
Don't fail every build for every severity. That produces noise and encourages exception sprawl. Define rules around factors such as exploitability, image provenance, workload exposure, whether a fix exists, and whether the package is reachable by the application.
Admission control should be stricter than pull-request feedback because it protects the cluster from changes that may arrive through another path. Still, its rejection message needs to be actionable. Tell the engineer which digest failed, which rule denied it, what evidence is missing, and where an approved exception belongs.
A GitOps controller should never be expected to compensate for weak artifact controls. If an unapproved image can be referenced freely, reconciliation will faithfully deploy the problem. Secure the registry, validate the digest, and make the policy decision reproducible.
Taming Alert Fatigue and False Positives
More findings don't automatically mean better security. An evaluation of Docker scanning tools found that static scanning can produce false positives, cannot detect runtime attacks, and that combining multiple tools still resulted in a detection rate below 50% in the evaluated dataset (independent analysis). The lesson isn't to abandon scanning. It's to stop treating scanner output as a prioritized attack list.
A CVE attached to a package is a starting point for investigation. Ask where the component came from, whether the distribution has backported a fix, whether the vulnerable function is included in the SBOM, whether the application can reach it, and what controls protect the workload. A package may retain a version string associated with a vulnerability even though the vendor has applied the patch without changing that string.
Use SBOMs as evidence
CycloneDX and SPDX SBOMs give the team a structured inventory that can be compared across builds and stored against an image digest. They also help distinguish direct dependencies from transitive ones and make it easier to trace a finding to its source package or base image.
The emerging practice is context-aware triage, not raw CVE counting. Coverage on container security testing and SBOM workflows describes how scanners increasingly use SBOMs and digest-level results while teams add continuous monitoring and drift detection. That model supports a more defensible response when a scanner reports a vulnerability but the affected code isn't reachable or a downstream patch has already been applied.
Use explicit statuses rather than deleting inconvenient results:
- Remediate: A fixed version exists and the component is reachable or exposed.
- Mitigate: Patching isn't immediately available, so network controls, reduced privileges, or feature restrictions lower the risk.
- Accept temporarily: The finding is understood, evidence is recorded, an owner is assigned, and the exception has an expiry condition.
- Dispute: Package metadata or distribution backport evidence shows that the finding doesn't represent the effective installed state.
Reachability analysis has limits. A static call graph may miss reflection, plugins, dynamic imports, or configuration-driven behavior. It should raise or lower priority, not become an excuse to ignore a finding without review.
The question isn't “How many CVEs are in this image?” It's “Which findings can affect this workload, through which path, under which controls?”
Enforcing Standards with Policy as Code
Manual review doesn't scale across many repositories, clusters, and teams. A security engineer can approve a handful of exceptions, but that person shouldn't become the deployment system for an entire organization. Policy as code makes the decision explicit, reviewable, testable, and reversible.
OPA Gatekeeper and Kyverno can validate Kubernetes resources at admission. A policy can require images to come from an approved registry, insist on immutable digests, reject privileged containers, or require an attestation that links the image to a scan result. The scanner supplies evidence. The admission policy determines whether that evidence satisfies the environment's rules.
Encode risk, not arbitrary severity
A useful policy distinguishes between environments and workload exposure. For example, a development namespace may permit findings without a fix when the image is isolated, while a public production service may require an approved digest, current scan evidence, and no blocking findings under the organization's defined risk model.
Don't hard-code a single severity threshold and call the job complete. A high-severity package in an unreachable command-line utility isn't equivalent to the same package in a public-facing request handler. Policy can require additional metadata, such as an owner, business service, namespace classification, exception reason, or compensating control.
This practical guide to policy as code for Kubernetes provides a useful reference for connecting admission decisions with version-controlled platform standards.
One pattern is to test policies in CI before enforcing them in the cluster. Render the Kubernetes manifests, evaluate them against the same constraints used by admission, and publish violations in the pull request. Once the rule is trusted, move it into enforcement mode. This prevents a policy rollout from surprising teams with failures they couldn't reproduce locally.
The policy repository should be managed like production code. Review changes, test expected allows and denies, retain history, and make rollback straightforward. Exceptions should also be code-backed, with a named owner and a clear reason. Avoid a permanent bypass label that any developer can add to a manifest.
The following video can help teams frame the relationship between policy definitions and Kubernetes enforcement:
A scalable model gives developers self-service remediation. The rejection message should point to the failed rule and the approved path, such as updating the base image, regenerating the SBOM, or requesting a time-bound exception. Security retains control of the standard without forcing every deployment through a human approval queue.
Proving Security Outcomes for Regulated Environments
Regulated organizations need more than a scanner dashboard. Auditors and internal risk teams need to understand what was scanned, which artifact was deployed, what decision allowed it, who approved an exception, and whether the control remained active over time.
The evidence chain begins with the image digest. Link that digest to the build run, source revision, SBOM, scan database state, policy result, GitOps commit, cluster admission event, and runtime workload. If a team rebuilds the image, the new digest needs a new assessment. A report tied only to a mutable tag can't prove which artifact was evaluated.
Government guidance for containerized systems makes recency part of the control. It requires all image components to be scanned before production deployment and states that only containers scanned within a 30-day vulnerability window may be actively deployed in production (FedRAMP container vulnerability scanning requirements). That requirement changes the operational design. A one-time release scan isn't enough if the vulnerability picture changes while the image remains in service.
Build a security observability view
OpenTelemetry can carry structured events from CI, registries, admission controllers, and runtime systems. Prometheus can record policy outcomes and scan coverage, while Grafana can present service-level views for platform teams, engineering managers, and auditors.
Useful measures include:
- Scan coverage: Which production image digests have current evidence, and which workloads lack it?
- Remediation age: How long do findings remain open by severity, service, and environment?
- Policy outcomes: Which rules block deployments most often, and which repositories generate repeated violations?
- Exception health: Which exceptions have owners, expiry conditions, and compensating controls?
- Artifact traceability: Can the team move from a running workload to its Git commit, SBOM, scan result, and approval record?
Don't confuse measurement with security. A dashboard that shows many scans may still hide ineffective triage or missing runtime controls. Pair operational metrics with periodic evidence review, sampling deployed digests and confirming that the records match the cluster's actual state.
This approach also supports broader frameworks such as ISO 27001, SOC 2, and GDPR, but the mapping should follow the organization's control objectives rather than rely on generic compliance labels. Auditors usually value a repeatable process and an intact evidence trail more than a visually polished report.
Building a Mature Container Security Practice
Maturity comes from making the safe path the normal path. Start with a small policy surface, prove that engineers can understand and fix failures, then expand enforcement as the evidence improves.
Establish the foundation
Begin by standardizing image builds. Use approved base images, remove unnecessary packages, pin release artifacts by digest, and generate an SBOM during the build. Run a scanner in pull requests and retain the report with the artifact rather than sending only a summary to chat.
At this stage, separate new findings from inherited backlog. Blocking every existing issue can stop delivery before the team understands the data. Focus the first gate on new risk, exploitable or reachable components, and images intended for sensitive environments.
Add lifecycle controls
Next, connect the registry, GitOps repository, and admission layer. Require promotion evidence before an image can enter an approved repository, commit immutable digests to the environment repository, and reject workloads that bypass the approved path.
Introduce policy tests before enforcement. Test both permitted and denied manifests, document exception handling, and make rejection messages useful. The platform team should be able to show exactly which rule made a decision without opening several disconnected systems.
Move from presence to context
Once the basic flow is stable, improve triage with SBOM comparison, package-origin data, distribution backport handling, and reachability signals. Store decisions as structured records so that an exception isn't lost in a ticket or chat thread.
Add runtime monitoring for process, filesystem, network, privilege, and drift events. Static scanning protects the artifact before deployment, while runtime controls help identify behavior that package analysis can't see.
Operate the control continuously
Review stale images, unowned exceptions, repeated policy failures, and workloads that lack current scan evidence. Treat base image maintenance as a product responsibility, not an occasional cleanup task. Keep the policy and scanner configuration in version control, test changes, and roll back a rule when it creates an unintended deployment failure.
CloudCops GmbH designs and secures cloud-native platforms with GitOps, CI/CD, Kubernetes, observability, and policy-as-code practices across major cloud environments. If your team needs to turn container vulnerability scanning into an auditable delivery control, visit CloudCops GmbH to discuss platform engineering and security implementation support.
Ready to scale your cloud infrastructure?
Let's discuss how CloudCops can help you build secure, scalable, and modern DevOps workflows. Schedule a free discovery call today.
Continue Reading
Least Privilege Principle: A Practical Guide
Learn the least privilege principle, why it matters, and how to enforce it across AWS, Azure, GCP, and Kubernetes with policy-as-code and a pragmatic rollout
Shift Left Security DevOps Guide to Build Safer Pipelines
Learn shift left security DevOps patterns, CI/CD integration, metrics and pitfalls to ship faster without sacrificing compliance or stability.
What Is Platform Engineering and Why It Matters Now
Learn what is platform engineering, how it differs from DevOps and SRE, the core principles and components, and a maturity roadmap to get started.