Container Image SBOMs: Why Your Docker Base Image Is Your Biggest Hidden Risk

When developers think about the security of their containerized application, they focus on their application code and its direct dependencies. But a typical Docker image contains far more software than the application alone — the OS packages in the base image, the language runtime, system libraries, and utilities. The average production container image contains 200-400 OS packages, many with known vulnerabilities, that most development teams have never examined.

What Is Actually Inside Your Container Image

A typical Node.js application container built from node:18 as a base image contains: the Debian or Alpine Linux OS layer (100-300 packages depending on the variant), the Node.js runtime and npm, your application's npm dependencies (which your team manages), and your application code (which your team wrote). Most vulnerability scanning focuses on the last two layers. The first two — the OS and runtime — often contain the majority of the vulnerabilities in the image.

Anchore's Container Security Report found that the average container image contains 10 critical vulnerabilities, with over half originating in the OS layer of the base image rather than the application code.

Generating a Complete Container SBOM

Tools like Syft and Trivy can generate SBOMs that cover all layers of a container image — both the OS packages and the application dependencies:

syft your-image:latest -o cyclonedx-json=image-sbom.json
trivy image --format cyclonedx --output image-sbom.json your-image:latest

The resulting SBOM covers OS packages (dpkg, rpm, apk), language packages (npm, pip, gem, maven), and binary artifacts that can be matched to known components. This is the complete picture that point-in-time application scanning misses.

Base Image Pinning and Update Strategies

The most common source of container OS vulnerabilities is using a floating base image tag (FROM node:18) rather than a specific digest-pinned version (FROM node:18@sha256:abc123). Floating tags mean your image silently changes when the upstream maintainer pushes a new version — sometimes introducing new packages, sometimes removing security fixes. SBOM-based analysis of each image build detects these changes and flags new vulnerabilities introduced through base image updates.

OCI Attestation for Container SBOMs

The OCI (Open Container Initiative) standard supports attaching SBOMs as signed attestations to container images in a registry. Using Cosign from the Sigstore project, you can sign and attach an SBOM to an image such that anyone pulling the image can verify the SBOM's authenticity and match it to the exact image. This creates a tamper-evident chain of custody for container supply chain verification.

// Recommended Tool

Complete Container Security with Fossity

Fossity — Fossity generates full-spectrum container SBOMs covering OS packages, language runtimes, and application dependencies — then continuously monitors your deployed container images for newly disclosed vulnerabilities. See what your base images contain.

Visit Fossity.com →
// Author: Esteban C.