What Makes Container Scanning Different
Container image scanning differs from source code scanning in an important way: it analyzes the final artifact as built, not just the application dependencies declared in your package manifests. A container image may contain OS-level packages (installed via apt, yum, or apk), language runtimes, application libraries, and potentially build artifacts from multiple stages. A comprehensive container scan must cover all of these layers.
This distinction matters because OS-level packages — the base image's glibc, OpenSSL, curl, and similar utilities — are frequently the source of critical vulnerabilities. The base image you pulled six months ago may now contain dozens of known CVEs that have been patched in newer versions but remain in your production containers because the image was never updated.
The Two Scanning Approaches
Registry scanning: Scan container images when they are pushed to your container registry (Docker Hub, ECR, GCR, ACR). Most major registries offer built-in scanning, but their coverage and timeliness vary. Registry scanning catches issues before images are deployed but after they have been built. Runtime scanning: Continuously scan running containers for newly disclosed vulnerabilities. This catches CVEs that were not known at build time. Tools like Trivy, Grype, and commercial platforms like Fossity can scan both registry images and running containers.
SBOM Generation from Container Images
Container images are now a first-class target for SBOM generation. Syft and Trivy can both produce SBOMs directly from Docker images in SPDX or CycloneDX format, capturing all layers including OS packages, language runtimes, and application dependencies. These container SBOMs are required for FDA submissions involving medical device software that runs in containers and are increasingly required by federal agency procurement teams.
Integrating Container Scanning into CI/CD
The standard pattern is: build the image, scan it in the pipeline, gate deployment on scan results. Using Trivy in GitHub Actions, for example, you can fail the pipeline if any critical CVEs are found and block the image from being pushed to production registries. Combining this with SBOM generation on every build gives you a complete audit trail of what went into production and when.
Maintaining Base Image Freshness
The most common source of container vulnerability accumulation is using a pinned base image that is never updated. Engineering teams pin base images (FROM ubuntu:22.04 rather than FROM ubuntu:latest) for reproducibility — a good practice — but then never update the pin. The result is a base image that accumulates CVEs over time. Establish a policy and automated process for regularly rebuilding images from updated base images, and scan after each rebuild.
Scan Your Containers with Fossity
Fossity — Fossity supports container image scanning alongside source code analysis — generating SBOMs that capture every layer of your Docker images and continuously monitoring for new vulnerabilities. Integrate with your registry or CI/CD pipeline and know what is in every container you deploy.
Visit Fossity.com →