Dependency Firewall started with packages: npm, Maven, PyPI, NuGet and the rest. But protecting Docker and OCI containers is just as important. The first line of a Dockerfile can bring in more third-party code than the whole package.json.
A base image brings in packages nobody chose
FROM node:22 brings a Debian release, a runtime and several hundred OS packages into the build. Nobody on the team chose those packages, and docker pull does not check them, so a known vulnerability in any of them ships with your application.
Images now go through the firewall too
With this release, docker, crane and oras pull and push through Dependency Firewall. The firewall fetches the image from Docker Hub or another registry, runs your rules on it and serves it only if it passes. The rule engine is the one that already runs npm, Maven and PyPI.
Start with a login and a changed host name
Run docker login against your firewall host. Then put that host in front of the image name: FROM alpine:3.20 becomes FROM your-firewall-host/alpine:3.20. The repository and the tag stay the same, in a Dockerfile and in a Kubernetes manifest.
Container clients only let you change the host, so the username names the firewall. A cluster pulls through the firewall with a pull secret for that host.
What the firewall checks in an image
- OS packages. The vulnerability rule reads the apk, dpkg and rpm databases in the layers and matches each package against its distribution's advisories. Application dependencies such as node_modules are checked when the image is built, if the build installs through a firewall.
- Every layer. An image is built in steps, and each step is stored as a layer. Malware and secrets rules scan every one, so a key that an early step added is found even after a later step deleted the file.
- Age. A delay rule holds a newly published tag, read from the build date in the image.
- Every tag. When latest points at a blocked 3.18, a pull of latest is blocked too.
The first pull of an image takes longer
The first pull of an image nobody has pulled before waits while its layers are scanned. Findings are stored per layer, so the next image on the same base waits only for the layers it adds.
A new CVE blocks the next pull of an image
The firewall stores what is in each layer. Every pull is matched against the advisory data of that moment. An image that passed in January is blocked the next time it is pulled after an advisory crosses your threshold, and nothing has to be scanned again. The firewall decides on requests: it does not reach images that were already pulled.
Try it on an image you already use
Container firewalling is an add-on to the Cloud plan, and we enable it per organization. Ask us to turn it on, during a 14-day trial too. Then log in, pull an image and open its page in the dashboard. It lists the build steps grouped by base image, with the vulnerabilities each step brought in.