Find and fix vulnerabilities in code, dependencies, containers, and infrastructure as code
Pull the latest version of this image from the Ghost registry. Pulling requires authentication — generate a token and run docker login first (see Authentication below).
The Ghost catalog is public to browse, but pulling images requires an account. Generate a pull token below (or from your Account → Tokens page) — you'll get a ready-to-paste docker login command, then docker pull works.
The username is generated automatically (it looks like robot$<project>+<auto-id>, not the name you typed) and is included in the docker login command above. The secret is shown only once when you create the token.
All Ghost images are signed with cosign. Verifying the signature before deployment ensures the image has not been tampered with.
Install cosign via brew install cosign or download from the Sigstore releases page.
Reference this image in your Dockerfile as a base layer:
All examples in this guide use the public image. If you've mirrored the repository for your own use (for example, to your Docker Hub namespace), update your commands to reference the mirrored image instead of the public one.
For example:
registry.ghost-prod.alphabravo.io/ghost-base/<repository>:<tag><your-namespace>/dhi-<repository>:<tag>For the examples, you must first use docker login registry.ghost-prod.alphabravo.io to authenticate to the registry to pull the images.
Most Snyk commands require authentication. Provide an API token through the SNYK_TOKEN environment variable when
running the container.
Replace <tag> with the image variant you want to run.
# Check the Snyk CLI version
$ docker run --rm registry.ghost-prod.alphabravo.io/ghost-base/snyk:<tag> --version
Mount your project and pass your API token:
$ docker run --rm -e SNYK_TOKEN -v "$PWD:/project" -w /project registry.ghost-prod.alphabravo.io/ghost-base/snyk:<tag> test
$ docker run --rm -e SNYK_TOKEN registry.ghost-prod.alphabravo.io/ghost-base/snyk:<tag> container test alpine:3.20
The Snyk CLI ships an MCP server in the same binary. Start it over stdio so an AI assistant can call Snyk scans as tools:
$ docker run --rm -i -e SNYK_TOKEN registry.ghost-prod.alphabravo.io/ghost-base/snyk:<tag> mcp -t stdio
# syntax=docker/dockerfile:1
FROM registry.ghost-prod.alphabravo.io/ghost-base/snyk:<tag> AS scan
ARG SNYK_TOKEN
COPY . /project
WORKDIR /project
RUN snyk test --severity-threshold=high
| Feature | Standard Snyk images | Docker Hardened Snyk |
|---|---|---|
| Security | Standard base with common utilities | Hardened base with reduced utilities |
| Package manager | Full package managers (apk, apt) | System package managers removed |
| User | Runs as root | Runs as nonroot user |
| Attack surface | Full system utilities available | Significantly reduced |
Runtime variants are designed to run Snyk commands in production and CI. These images typically:
docker debug for any debugging needsDev variants include -dev in the variant name and tag. They are build-time images intended for multi-stage
Dockerfiles. These variants:
To migrate from the official snyk/snyk images to Ghost hardened images, update your deployment configuration and
potentially your Dockerfile.
| Item | Migration note |
|---|---|
| Base image | Replace snyk/snyk images with Docker Hardened Snyk images |
| Entrypoint | The entrypoint is snyk; pass subcommands such as test or mcp directly |
| Package management | System package managers removed in runtime variants |
| Non-root user | Runtime images run as the nonroot user |
| Authentication | Provide SNYK_TOKEN as an environment variable rather than baking in config |
Most Snyk commands require an authenticated session. Pass -e SNYK_TOKEN to the container, or run snyk auth from a
dev variant to populate the configuration mounted at the user's home directory.
By default, runtime image variants run as the nonroot user. Snyk writes its cache and configuration under the home
directory (/home/nonroot). Ensure any mounted project files are accessible to the nonroot user.
Non-dev hardened images run as a nonroot user by default. As a result, applications in these images can't bind to privileged ports (below 1024) when running in Kubernetes or in Docker Engine versions older than 20.10.