When we launched container scanning in Safeguard v2, we got a common question: how is this different from Trivy or Grype?
It is a fair question. Container vulnerability scanning is not new. But Safeguard's approach is different in a way that matters: we treat container images as supply chain artifacts, not just scan targets.
The Container Supply Chain Problem
A container image is a layered composition of software from multiple sources. A typical production image includes:
- A base image (Ubuntu, Alpine, Debian, distroless) maintained by a distribution team
- System packages installed via apt-get, apk, or yum, maintained by package maintainers
- Language runtimes (Node.js, Python, Java, Go) maintained by their respective communities
- Application dependencies pulled from npm, PyPI, Maven, or other registries
- Your application code
Each layer has its own supply chain. Each layer carries its own vulnerabilities, licenses, and maintenance risk. A vulnerability in a base image's OpenSSL installation is just as dangerous as a vulnerability in your npm dependencies, but many organizations manage these risks in completely separate workflows using different tools.
Safeguard treats the entire image as a single supply chain artifact. One SBOM. One vulnerability report. One policy evaluation. One place to understand the full risk picture.
How Container Scanning Works
Image Analysis
Safeguard analyzes container images by inspecting each layer of the image filesystem. The analysis can work with:
- Registry images -- Pull directly from Docker Hub, AWS ECR, GCR, Azure ACR, GitHub Container Registry, or any OCI-compliant registry
- Local images -- Analyze images in your local Docker daemon
- Tarballs -- Analyze saved image archives
The analysis walks through every layer and identifies:
OS packages by reading the package database for the distribution. For Debian/Ubuntu, this is the dpkg database. For Alpine, it is the apk database. For Red Hat/CentOS, it is the rpm database. Each installed package is cataloged with its exact version.
Application dependencies by detecting and parsing manifest and lockfiles anywhere in the image filesystem. If there is a node_modules directory, a requirements.txt, a pom.xml, or a go.sum anywhere in any layer, Safeguard finds it and catalogs those dependencies.
Base image identification by analyzing the image's layer history and matching against known base image digests. This tells you not just that your image is based on Ubuntu 22.04, but exactly which build of Ubuntu 22.04, which matters for vulnerability tracking.
SBOM Generation
The analysis produces a CycloneDX or SPDX SBOM that includes every component found in every layer. Components are tagged with their source (OS package manager, npm, pip, etc.) and with the layer they appear in.
This layer information is valuable for remediation. If a vulnerability is in the base image, updating your application code will not fix it -- you need to update or rebuild with a newer base image. If the vulnerability is in your application dependencies, the fix is in your build process, not your Dockerfile.
Vulnerability Correlation
Once the SBOM is generated, it flows through the same vulnerability correlation engine used for source-level SBOMs. The difference is that container SBOMs include OS packages, which means correlation needs to check distribution-specific advisory databases in addition to the standard CVE sources.
Safeguard checks:
- NVD and OSV for all components
- Distribution security trackers (Debian Security Tracker, Ubuntu CVE Tracker, Alpine SecDB, Red Hat Security Data) for OS packages
- Ecosystem advisories (npm, PyPI, Maven) for application dependencies
Distribution-specific tracking is critical because distributions often backport security fixes without changing the upstream version number. Debian might ship OpenSSL 3.0.11-1~deb12u2 which includes backported fixes for CVEs that were fixed in upstream 3.0.13. Matching against NVD alone would flag this as vulnerable when it is actually patched. Checking the Debian Security Tracker gives the correct status.
Registry Monitoring
Beyond point-in-time scanning, Safeguard monitors your container registry continuously. When new images are pushed, they are automatically scanned. When new vulnerabilities are disclosed, all stored image SBOMs are re-evaluated.
This is particularly important for images that are deployed but not frequently rebuilt. A production image that was clean when it was built three months ago may have accumulated vulnerabilities as new CVEs were published. Continuous monitoring catches this drift without requiring a rebuild and rescan.
Registry monitoring supports webhook notifications. When a vulnerability is found in a deployed image, your team is notified immediately through your configured channels (Slack, PagerDuty, email, webhook).
Base Image Recommendations
One of the most impactful actions you can take for container security is choosing the right base image. Safeguard's container scanning includes base image analysis that shows:
- How many vulnerabilities are in the current base image
- Whether a newer tag of the same base image is available with fewer vulnerabilities
- How alternative base images (Alpine vs. Debian, distroless vs. standard) compare on vulnerability count and image size
This data drives concrete recommendations. If your Debian-based image has 45 OS-level vulnerabilities and the equivalent Alpine-based image has 8, that is an actionable finding. If a newer tag of your current base image fixes 20 of those 45 vulnerabilities, that is an even easier win.
Policy Integration
Container images are subject to the same policy engine as source-level projects. This means you can enforce:
- Maximum vulnerability count or severity for production images
- Required base image sources (only images from your approved base image registry)
- Prohibited packages (no curl in production containers, for example, to reduce attack surface)
- Maximum image age (images older than 90 days must be rebuilt)
- License compliance across all components in the image
Policy checks run automatically when images are pushed to a monitored registry, and they can also run as a CI/CD gate before the image is pushed.
Practical Usage
The typical workflow for container scanning integration:
# In your CI/CD pipeline, after building the image
docker build -t myapp:$VERSION .
# Scan before pushing to registry
safeguard scan --image myapp:$VERSION
# If scan passes policies, push to registry
docker push registry.example.com/myapp:$VERSION
# Upload the SBOM for continuous monitoring
safeguard sbom generate --image myapp:$VERSION --format cyclonedx \
| safeguard sbom upload --project myapp --release $VERSION
For existing images already in your registry, you can scan them in bulk:
safeguard scan --registry registry.example.com --all-tags
Getting Started
Container scanning is available on all Safeguard plans. If you are already using Safeguard for source-level scanning, adding container scanning requires no additional setup beyond providing registry credentials.
Start with your production images. Scan them, review the findings, and configure policies that enforce your risk tolerance. Then integrate the scan into your CI/CD pipeline so new images are evaluated before deployment.
The combination of source-level and container-level scanning gives you complete supply chain visibility from development through deployment. No blind spots. No separate tools to correlate.