Sign inSign up

sbx/trivy-kit

Verified Publisher

By Docker, Inc

Updated 9 days ago

Aqua's open source vulnerability scanner — sandboxed because security scanners shouldn't be able .

Sandbox Kit
0

5.1K

sbx/trivy-kit repository overview

Digest

sha256:d657ddb72c92…

Size

2 Bytes

Schema

v2

Pushed

9 days ago

Specificationspec.yaml

SANDBOX KIT

Aqua's open source vulnerability scanner — sandboxed because security scanners shouldn't be able to compromise their hosts (TeamPCP, March 2026).


Network Egress

github.com

objects.githubusercontent.com

release-assets.githubusercontent.com

mirror.gcr.io

ghcr.io

pkg-containers.githubusercontent.com

Run in a Sandbox

sbx run docker.io/sbx/trivy-kit:latest

Make sure you have docker sbx installed

Run the following command to install sbx on your machine.

macOS
brew install docker/tap/sbx
Windows
winget install Docker.sbx
Learn more about docker sbx

trivy

A 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.

Why this kit exists

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.

Usage

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.

How auth and egress work

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:

HostWhy
github.comRelease page entry point for the install tarball (302-redirects)
objects.githubusercontent.comActual redirect target for this repo's release asset (confirmed by hand)
release-assets.githubusercontent.comKept alongside it since the redirect target isn't guaranteed to be the same host for every repo/asset
mirror.gcr.ioTrivy's default primary vuln DB source (mirror.gcr.io/aquasec/trivy-db)
ghcr.ioTrivy's fallback vuln DB source (ghcr.io/aquasecurity/trivy-db)
pkg-containers.githubusercontent.comGHCR 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.

Image scanning

By default the kit does not mount the host Docker socket. Image scanning has three workable modes:

  1. 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.
  2. 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.
  3. Bind-mount /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.

Version pinning

The install command pins:

  • TRIVY_VERSION=0.70.0 (published 2026-04-17, post-TeamPCP)
  • SHA256 per-arch: Linux-64bit and Linux-ARM64

To 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.

Cleanup

sbx rm trivy-<basename> removes the sandbox and its persistent vuln DB cache. The workspace bind-mount on the host is untouched.