Aqua's open source vulnerability scanner — sandboxed because security scanners shouldn't be able .
5.1K
sha256:d657ddb72c92…
2 Bytes
v2
9 days ago
Aqua's open source vulnerability scanner — sandboxed because security scanners shouldn't be able to compromise their hosts (TeamPCP, March 2026).
github.com
objects.githubusercontent.com
release-assets.githubusercontent.com
mirror.gcr.io
ghcr.io
pkg-containers.githubusercontent.com
sbx run docker.io/sbx/trivy-kit:latestRun the following command to install sbx on your machine.
brew install docker/tap/sbxwinget install Docker.sbxA standalone sandbox kit for the Trivy
open-source vulnerability scanner from Aqua Security.
The kit installs trivy from a pinned, digest-verified GitHub release at
sandbox creation time and drops you into a bash shell with the binary on
PATH and your workspace mounted as the working directory.
In March 2026 the threat actor TeamPCP compromised Trivy
itself — force-pushing GitHub Action tags, shipping an infected v0.69.4
binary, and using the resulting credential harvest to weaponize 47+ npm
packages downstream. Microsoft's
response guidance
prescribes "governed execution pipelines" with "vault isolation and egress
filtering". This kit puts that prescription one sbx run away: scanner
runs in a microVM, your ~/.aws / ~/.ssh / ~/.docker/config.json are
not mounted, egress is allowlisted to six hosts (release fetch + vuln DB),
and the install is digest-pinned against tag-rewrite attacks.
cd ~/work/some-project
sbx run --kit "docker.io/sbx/trivy-kit:latest" trivy .
agent@trivy-some-project:/Users/mark/work/some-project$ trivy fs .
Or from a git URL targeting this repo:
sbx run --kit "git+https://github.com/docker/sbx-kits-contrib.git#dir=trivy" trivy .
Or with a local clone of this repo:
sbx run --kit ./trivy/ trivy .
The first launch downloads, verifies, and installs Trivy. Subsequent launches reuse the sandbox; the vuln DB is cached on a persistent volume.
Trivy is fully open source — no API key needed for the standard scan
flows (fs, repo, plain image). Aqua's commercial feeds (premium
indicators, SaaS reporting) are out of scope for this kit; if you need
them, fork and add the appropriate serviceDomains and credentials.
The kit's network allowlist covers exactly six hosts:
| Host | Why |
|---|---|
github.com | Release page entry point for the install tarball (302-redirects) |
objects.githubusercontent.com | Actual redirect target for this repo's release asset (confirmed by hand) |
release-assets.githubusercontent.com | Kept alongside it since the redirect target isn't guaranteed to be the same host for every repo/asset |
mirror.gcr.io | Trivy's default primary vuln DB source (mirror.gcr.io/aquasec/trivy-db) |
ghcr.io | Trivy's fallback vuln DB source (ghcr.io/aquasecurity/trivy-db) |
pkg-containers.githubusercontent.com | GHCR blob storage backend |
Both DB sources are declared in the allowlist rather than redirecting Trivy to one specific source via env vars. The reason: env-var-based security config is fragile — anything running as the agent user inside the sandbox can override or unset it. Declaring all required egress at the policy layer keeps the trust footprint observable and survives a compromised agent process trying to subvert it.
Tightening this footprint — both the install channel (currently a pinned GitHub release) and the DB source (currently Trivy's defaults) — is the v2 path: install via a hardened-distribution channel where the entire build pipeline is observable and signed. Deferred until that integration lands cleanly at the runtime layer.
Anything else — registries you want to scan images from, custom vuln DB mirrors, your reporting endpoint — should be added with a per-sandbox or operator-level allow rule, not in the kit:
sbx policy allow network --sandbox trivy-some-project "registry-1.docker.io,auth.docker.io,production.cloudflare.docker.com"
This keeps the kit's default footprint minimal and forces deliberate opt-in to anything image-registry-shaped.
By default the kit does not mount the host Docker socket. Image scanning has three workable modes:
trivy image --input <tarball> (recommended) — docker save
the image to a tarball on the host, mount the tarball into the
workspace, scan it inside the sandbox. Zero socket exposure.trivy image <registry>/<repo>:<tag> — Trivy pulls the image
itself directly. Add the registry's hosts to a per-sandbox allow
rule (see above). Requires no socket./var/run/docker.sock — works but defeats the
isolation. Don't.For routine scanning of what's in front of you, prefer
trivy fs . against the workspace mount.
The install command pins:
TRIVY_VERSION=0.70.0 (published 2026-04-17, post-TeamPCP)Linux-64bit and Linux-ARM64To bump: edit spec.yaml, update both the version string and the
SHA256s sourced from the release's checksums.txt. Sigstore signature
verification is a worthwhile follow-up but out of scope for v1.
sbx rm trivy-<basename> removes the sandbox and its persistent vuln
DB cache. The workspace bind-mount on the host is untouched.