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
Intro
Container Image Security
A container image is a packaged filesystem plus configuration. It carries the application, runtime libraries, and startup settings that a container runtime needs. That convenience also creates a concentrated security boundary: every included file, package, credential, and default can travel from a developer's build into production.
Container image security is the practice of controlling that package across its full lifecycle. You choose trusted inputs, build with fewer unnecessary components, record what happened, test the result, distribute it through a protected registry, and verify it before deployment. You keep reassessing published images because vulnerability knowledge changes after a build finishes.
The useful mental model is a sealed shipment with an inventory and chain of custody. The image is the shipment. Its digest identifies the exact contents. An SBOM lists components. Provenance describes how the shipment was produced. A signature links an identity to the artifact. Policy decides whether the evidence is sufficient for a destination.
None of those controls answers every question. A digest proves which content you selected, not that the content is safe. A signature proves a verification relationship, not that the signer made a secure image. An SBOM supplies inventory, not a risk verdict. A vulnerability scan compares observable components with current advisory data, so a clean result can change when new advisories appear.
What an image contains
The Open Container Initiative image format defines an image manifest with a configuration object and an ordered set of filesystem layers. Each object is referenced by a digest. A registry stores and distributes these objects. A tag gives people a convenient name, while a digest identifies content through a cryptographic hash.
This distinction changes deployment safety. A tag such as app:2.4 can be moved to different content. A digest reference such as app@sha256:... selects one exact manifest. Pinning by digest makes a deployment repeatable and prevents a later tag change from silently selecting another image.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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