Open Source Container Scanners Worth Running on Sandbox Base Images
Layer image, permission, and runtime scanners, since none alone covers agent risk.
Open-source container scanners help secure AI agent sandbox base images, but no single scanner covers the whole risk. A layered practice checks image contents, audits deployment permissions, and detects or blocks dangerous runtime behavior. Because agents can change their environment after launch, those controls must extend beyond a clean build report, and protect the scanning tools themselves.
Why sandbox base images for AI agents carry higher CVE stakes than ordinary container images
An agent can decide at runtime what to install, call, and use. Its attack surface is therefore not fixed at build time. A vulnerability takes on greater stakes when the code inside the container can reason about its environment and attempt novel exploitation paths. Containment concerns extend beyond the application failing to include information leakage, cyberattacks launched from within containers, and escape attempts.
An OCI image records application content and launch configuration, but not what the application may access once running. Whoever launches it supplies that access through docker run flags, Compose files, or Kubernetes network policies. The agent and its authority travel separately. Meanwhile, AI-generated Dockerfiles, manifests, and dependency updates multiply image variants, and newly published advisories can expose vulnerabilities in unchanged images.
The two moments where scanning must happen and why neither one alone is enough
Before deployment, static scanners inspect OS packages and language libraries for known CVEs. Trivy, Grype, and Clair work at this layer. Their findings describe what is baked into the image, leaving later agent installations and calls outside their scope. A completed scan also misses advisories that come out afterward.
Runtime tools address a different question altogether. What does the container actually do once it starts? Falco and KubeArmor observe or constrain behavior associated with cryptomining, privilege escalation, container escapes, and abnormal process execution. They cannot retroactively patch the image, so runtime protection depends on build-time hygiene. The following tools cover these layers in turn, followed by the Kubernetes configuration checks needed to audit the environment around them.
Trivy as the build-time starting point
Trivy is the practical default for most teams because it combines image CVE scanning, Kubernetes manifest checks, infrastructure-as-code checks, and SBOM generation in one binary without external database setup. Its package coverage includes Alpine, Debian, Ubuntu, RHEL, and Amazon Linux. Language library scanning covers Python, Node.js, Java, Go, Ruby, Rust, and PHP. This breadth suits mixed agent workload images. It also generates software bills of materials in CycloneDX and SPDX formats.
Teams can turn on regex-based secrets detection to look for AWS keys, API tokens, and similar patterns. Deleting a .env file in a later Dockerfile step does not erase it from earlier layers. For sandbox pipelines, the recommendation is therefore to scan the resulting image for secrets as well as vulnerable packages.
Trivy still produces a point-in-time view. It does not persist scan history across builds, deduplicate CVEs across repositories, or assess runtime reachability of vulnerable code paths. Some transitive language dependencies can produce false positives, and native compliance evidence mapped to SOC 2 or FedRAMP is absent. Teams should scan base images on a schedule even when the code stays the same, and use the nightly results to send alerts into a SIEM. Its broad scope makes it a useful baseline, while a dedicated SBOM workflow may better suit some audit requirements.
Grype and Syft for a dedicated SBOM-first workflow
Grype paired with Syft separates the component inventory from vulnerability matching. Syft generates an SBOM at build time, and Grype scans that inventory repeatedly without re-pulling the image at each pipeline stage. Teams can share the same inventory. That reproducibility suits compliance-heavy pipelines where audit evidence is a first-class requirement.
Compatibility, however, cannot be inferred from the format name. Cross-tool SBOM handling can miss package matches, so teams should use the generating tool’s scanning workflow or explicitly test the pairing before production use. Grype also lacks Trivy’s Kubernetes manifest and infrastructure-as-code checks, and full SBOM workflows require Syft. This is a choice about inventory handling, whereas Clair addresses a different deployment pattern by placing scanning at the registry.
Clair for build-time scanning at the registry layer
Clair fits teams that want images scanned as they enter a registry in addition to a separate CI step. Developed by Red Hat, originally CoreOS, it powers the vulnerability scanning backend for Red Hat Quay and Quay.io. It scans layers and checks the packages it finds against vulnerability databases.
Its design is especially useful for teams with large catalogs of images. Clair keeps image analysis separate from vulnerability correlation, so it can match old indexes against new CVEs without scanning the images again. Its notification service can alert through webhooks when newly discovered vulnerabilities affect indexed manifests. Content-addressed OCI layers also let it skip layers it has already indexed, so it does less of the same work across image variants.
That design comes with more operational weight. Clair requires PostgreSQL and runs an indexer, matcher, and notifier rather than offering a built-in CLI for ad-hoc scanning. Teams that run Quay or a large self-hosted registry have a place to plug it in, while teams without one may get too little from it to justify running another service. However it is deployed, Clair shares Trivy’s and Grype’s blind spot. None sees what happens after the container starts.
Falco for threats that emerge after the agent starts running
Falco monitors kernel-level system calls through eBPF to detect suspicious runtime behavior. In agent sandboxes, these patterns include installing packages or running a shell when that is unexpected, and trying to read files outside the expected scope. Its rules can also match events associated with escape attempts and privilege escalation. These are behaviors an image scan cannot establish beforehand.
Detection is not the same as intervention. Falco alerts but never stops the suspicious action, so teams must connect it to an on-call response or automated remediation workflow. What does a 3 a.m. alert accomplish if nobody can act on it?
Deployment constraints must also enter infrastructure planning. Fargate-style runtimes such as EKS Fargate, AWS App Runner, and Cloud Run lack the on-cluster DaemonSet footing Falco needs. GKE Autopilot supports DaemonSets but blocks the privileged access it requires. Teams on these platforms should plan to scan images in CI and use cloud-side detection. Where kernel-level controls are available, KubeArmor enforces boundaries.
KubeArmor for enforcement at the kernel level
KubeArmor, from AccuKnox, blocks policy violations through Linux Security Modules, including AppArmor, SELinux, and BPF-LSM. Its distinction from Falco is direct enforcement. Where an agent’s permitted paths, system interfaces, and network connections can be bounded, whitelist policies can deny activity outside those limits. That approach can protect against unknown exploitation paths by refusing operations that were never permitted.
Restrictive policies can break useful agent operations, while permissive policies weaken the boundary. Teams usually run Falco first to see normal behavior, then set the expected limits in KubeArmor policy. The tools therefore work better in sequence than as substitutes. Both work on running containers, however, and neither audits the wider Kubernetes configuration to find where those containers face risks they need not face.
Kubescape for cluster and manifest configuration gaps
Kubescape audits Kubernetes manifests, Helm charts, and live cluster configuration against CIS, NSA-CISA, and MITRE ATT&CK frameworks. This adds context beyond package vulnerabilities and individual runtime events. Agent deployments may involve custom namespaces, elevated service accounts, and non-standard network egress, all of which need configuration scrutiny.
Its in-cluster operator supports continuous scanning and can generate network policies from observed pod behavior. Kubescape also uses eBPF for reachability analysis, distinguishing reachable loaded vulnerabilities from vulnerabilities present but unexposed in the running environment. That helps address Trivy’s lack of runtime reachability context. For infrastructure teams, the recommended cadence is an audit after cluster provisioning and after significant manifest or policy changes.
Kube-bench complements this work at a different layer. It audits cluster node configuration against the CIS Kubernetes Benchmark, including API server and kubelet settings.
How the scanner supply chain itself became an attack surface
The tools protecting a pipeline can also compromise it. Aqua Security’s official GitHub discussion describes the late-February 2026 attack in which an AI-powered bot exploited a misconfigured pull_request_target workflow, stole a Personal Access Token, deleted releases, and published a malicious VS Code extension to OpenVSX. The March attack was a separate second wave that used credentials the attackers had kept.
The v0.69.4 binary and Docker image, plus Docker images v0.69.5 and v0.69.6, were poisoned. Attackers force-pushed 76 of 77 trivy-action tags to credential-stealing code. CISA added CVE-2026-33634 to its Known Exploited Vulnerabilities catalogue on March 26, 2026.
Teams should pin GitHub Actions by full commit SHA, pin binaries and images by checksum and digest, and verify release signatures before use. Otherwise, a scanner intended to protect sandboxes can become a credential-theft vector upstream of them. Artifact identity is therefore part of the security boundary, a principle Docker’s Sandbox Kit Spec extends to agent permissions.
What Docker’s Sandbox Kit Spec changes about permissions in agent images
Docker’s Sandbox Kit Spec v3, announced September 24, 2026, moves agent permissions inside OCI images. It is an early-draft open-source specification, with a final version targeted for Q4 2026. The ecosystem is still forming around it.
A Kit is built with docker buildx build, pulled with docker pull, and can use existing scanning and signing tools. It can also serve as a base image through a FROM instruction, allowing a sandbox base image to inherit a governed permission set. Pinning its digest pins both content and permissions. A permission change therefore changes the image hash rather than remaining separate from the pinned artifact.
This addresses the separation identified at the start. The specification enables versioned, verifiable security controls and automatic approval of updates that do not escalate permissions. It does not make vulnerability scanning unnecessary or turn a CVE scanner into a runtime enforcer.
Assembling a layered scanning practice for sandbox base images in production
For a production team, the action path starts with Trivy in CI and scheduled scans of the base images still in use. Secret scanning belongs on the built image. Grype with Syft earns its place when reproducible SBOM handling is an explicit requirement, while Clair earns its operational cost where registry-scale indexing and re-matching are useful.
After provisioning, Kubescape should audit cluster configuration and significant manifest or policy changes, with a node auditing tool supplying node-level CIS checks where needed. Runtime protection then depends on the available infrastructure. Falco needs someone who will act on its alerts or an automated remediation path, and KubeArmor is useful once teams understand expected behavior well enough to enforce it. Teams on restricted serverless platforms can instead use CI scanning with cloud-side detection.
Commit pins, checksums, digests, and signature verification belong to both the scanning pipeline itself and the images it examines. Strong sandbox isolation remains a separate architectural protection. It reduces exposure, but a vulnerable base image remains a liability even inside a well-isolated sandbox, so isolation and scanning must reinforce each other.
