Container Image Security
Container image security ensures that the images used to run containers are free from known vulnerabilities, malicious code, and unnecessary attack surface. It covers scanning, provenance verification, minimal base images, and policies that prevent untrusted images from reaching production.
itSoftware supply chain security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Container Image Security
A container image is the parcel your application travels in: filesystem, libraries, startup settings, and occasionally a surprise that nobody meant to mail. It makes an application portable because the same package can move from a build system to a registry and then to a container runtime. It also means a package, credential, or unsafe default can make the same journey with it.
The trick is to stop treating the image as a mysterious black box with a tag
attached. A tag is a handy nickname. A digest is the exact content
identifier. If a deployment says app:release, someone can later move that
nickname. If it says app@sha256:..., it has selected one manifest. This is
less glamorous than it sounds, which is fortunate: reliable delivery depends
heavily on dull precision.
Three companions make that precision useful. An SBOM, or software bill of materials, inventories the components. Provenance records how the build was made and which inputs it resolved. A signature lets a verifier check an expected identity against the artifact. These are different receipts for different questions. None turns an image into a magical safety certificate.
That last point is the surprise. A clean scan is not a permanent approval. The image can stay byte-for-byte unchanged while new advisory information changes the assessment. The sensible response is not to perform surgery on a running container like an anxious mechanic. Change the source or build, create a new digest, produce new evidence, then replace the deployment.
Security also begins before scanning. The base image is an upstream dependency, not decorative scaffolding. Build only what needs to ship, keep secrets out of layers, and run as a non-root user when the application supports it. Smaller helps only when it leaves an explainable result. A tiny image from an unknown publisher remains tiny and unknown, which is not a security program.
The course material fills in the machinery. Start with the Intro for image anatomy and the lifecycle. Use Slides for the evidence chain. Keep the Cheatsheet nearby when comparing a digest, SBOM, provenance, signature, scan, and policy decision. The Practice Reference and exercise turn the ideas into observable checks. Field Notes covers the joins and exceptions that make a pipeline behave differently from a reassuring diagram.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://doi.org/10.6028/NIST.SP.800-190
Supports
- Container images as portable application packages and the relationship among images, registries, orchestrators, containers, and hosts
- Image risks from vulnerable software, configuration defects, malware, embedded clear-text secrets, and untrusted images
- Registry risks involving insecure connections, stale images, and insufficient authentication and authorization
- Need to update images upstream and redeploy when vulnerabilities are discovered after creation
- https://github.com/opencontainers/image-spec/blob/main/manifest.md
Supports
- Image manifest structure with configuration and ordered filesystem layer descriptors
- Content-addressable image model and digest-referenced components
- Image indexes for platform-specific manifests
- https://github.com/opencontainers/image-spec/blob/main/descriptor.md
Supports
- Digest as a content identifier using a cryptographic hash
- Descriptor fields that identify media type, digest, and content size
- https://github.com/opencontainers/image-spec/blob/main/layer.md
Supports
- Filesystem layer change sets and ordered application of changes
- Deletion markers in later layers rather than mutation of prior layer content
- https://docs.docker.com/build/building/best-practices/
Supports
- Maintained and trusted base image selection
- Digest pinning for repeatable inputs and its update tradeoff
- Multi-stage builds, minimal final content, and non-root USER guidance
- https://docs.docker.com/build/building/multi-stage/
Supports
- Multiple FROM stages and selective COPY from a build stage into a final image
- Separation of build tools from runtime output
- https://docs.docker.com/build/building/secrets/
Supports
- Build arguments and environment variables as unsuitable secret channels because values can persist
- Secret mounts and SSH mounts for temporary build-step access
- https://docs.docker.com/scout/explore/analysis/
Supports
- Image analysis that extracts an SBOM and compares components with vulnerability advisory data
- Recalculation of results when vulnerability data changes
- Advisory-source differences in severity information and final-image analysis commands
- https://www.cisa.gov/topics/cyber-threats-and-advisories/sbom/sbomresourceslibrary
Supports
- SBOM as a formal record of software components and supply-chain relationships
- Minimum elements, SBOM document types, generation guidance, and consumption guidance
- https://slsa.dev/spec/v1.2/provenance
Supports
- Provenance as verifiable information about where, when, and how artifacts were produced
- Build definition, resolved dependencies, builder identity, run details, and artifact subjects
- Consumer verification of artifacts against expected build information
- https://docs.sigstore.dev/cosign/verifying/verify/
Supports
- Cosign verification with a key or keyless certificate identity and OpenID Connect issuer
- Default validation that a signature payload's image digest matches the image
- Need to constrain claims and expected signing identity during verification
- https://kubernetes.io/docs/concepts/containers/images/
Supports
- Difference between image tags and digests in workload references
- Digest pinning for consistent deployed content when tags change
- Image pull policy behavior and private registry authentication context
- https://docs.docker.com/engine/release-notes/prior-releases/
Supports
- Docker Engine 1.0 production support in June 2014
- Trusted pull, push, and build in Docker Engine 1.8 in August 2015
- Content-addressable storage for images and layers in Docker Engine 1.10 in February 2016
- https://opencontainers.org/posts/announcements/2015-06-20-industry-leaders-unite-to-create-project-for-open-container-standard/
Supports
- June 2015 announcement of the Open Container Project and its open container format and runtime standards work
- https://github.com/opencontainers/image-spec/releases/tag/v1.0.1
Supports
- OCI Image Specification version 1.0.1 release in November 2017
- https://www.whitehouse.gov/wp-content/uploads/2021/05/Executive-Order-on-Improving-the-Nations-Cybersecurity.pdf
Supports
- Executive Order 14028 direction to publish minimum elements for an SBOM in May 2021
- https://opensource.googleblog.com/2021/05/introducing-sigstore-easy-code-signing.html
Supports
- May 2021 introduction of Sigstore as a public-good software signing service
- https://slsa.dev/blog/2023/04/slsa-v1-final
Supports
- SLSA version 1.0 final release in April 2023
- https://docs.docker.com/scout/
Supports
- Docker Scout image SBOM inventory, vulnerability analysis, policy evaluation, and integrations
- https://docs.snyk.io/scan-with-snyk/snyk-container/how-snyk-container-works
Supports
- Snyk Container support for OCI-compliant and Docker v2-compliant images and its final-image package analysis
- https://docs.anchore.com/current/docs/overview/
Supports
- Anchore Enterprise SBOM-based continuous visibility, vulnerability detection, policy enforcement, and compliance management
