Public images that are intended to be executed should be evaluated in advance and run with as many restrictions as possible. The following guidelines for initial image evaluation are sorted by importance.
While Supply-chain Levels for Software Artifacts (SLSA) provides valuable build security guidance, its scope is too narrow for comprehensive container image evaluation. Software Composition Analysis of third-party images has limitations, as users often cannot properly validate reported findings.
Outlook: This checklist serves as a foundation for implementing automated quality gates to validate container images before deployment in either local development or production environments. The systematic verification of these security and quality criteria helps ensure safer container execution and reduces potential risks in your environment.
Malware Scanning
Description:
Is malware present?
Test procedure:
- Export image to local tarball (docker save
-o image.tar ) - Run Malwarescanner like clamAV against the tarball
Privilege and Permission Controls
Description:
Running containers as root gives unnecessary privileges that could enable an attacker to break out of the container and access the host system if vulnerabilities are exploited. Running as non-root automatically prevents certain types of attacks and limits the potential damage even if an application is compromised.
Test for root execution:
- Check effective runtime UID
- Verify USER instruction in Dockerfile
Check for setuid/setgid binaries:
- Scan for files with perm /6000
Image Currency and Update Frequency
Description:
A low update frequency may lead to potential vulnerabilities. Test the age of the provided image or the update frequency.
Test:
Count updates in last 3 months
- Good Frequency: At least 20 updates in last 6 months
- Acceptable Frequency: At least 9 updates in last 6 months
Attack Surface Analysis
Description:
Components, libraries, files, and file permissions may contain known vulnerabilities or misconfigurations. Therefore, unnecessary files should be removed. A minimal approach is Distroless.
Test for Distroless:
- Measure image size
- Very good: Smaller 250MB
- Acceptable: Smaller 500MB
Test for Distroless:
- Check for /bin/bash presence
Architecture Compatibility
Description:
Architecture compatibility is crucial because container images need to match the CPU architecture of the host system where they will run (like amd64 or arm64). Running containers on mismatched architectures can lead to performance issues through emulation or complete failure to execute, which is particularly important in production environments where consistent performance is required. Applications deployed across different platforms (like cloud providers, edge devices, or developer machines) need to ensure the correct image architecture is available for each target system. This is especially relevant with the growing adoption of ARM-based systems like Apple Silicon Macs and cloud providers offering ARM instances.
Test: Verify image availability for:
- amd64
- arm64
- Required architectures for deployment
Community Reception
Description:
Community Reception involves checking the negative reviews of a container image, particularly looking for any mentions of malicious code in the feedback. A high number of stars on the repository is considered a positive indicator of the image’s reliability and quality. This aspect helps gauge the trustworthiness and quality of the image based on community experiences and adoption, with special attention to security-related feedback.
Check metrics:
- Download statistics
- Star count
- Recent reviews
- Security issue reports
- Issue response time
Software Bill of Materials (SBOM)
Description:
Is a Software Bill of Materials (SBOM) available for the image? An SBOM can be provided via a URL in an image label or in the image itself, e.g., under /sbom.json.
Test:
- Check image labels
- Look for /sbom.json
- Verify SBOM URL accessibility and completeness
- Check for available attestation
Version Management
Description:
Is semantic versioning (semver) used for versions?
Test:
- Verify version tags follow semver
- Check version consistency across registries
Build Reproducibility
Description:
Build Reproducibility refers to the ability to consistently create identical container images when building from the same source code.
Test procedure:
- Does created has a fixed value for each build like 1970-01-01
- Build image multiple times
- Compare layer hashes
- Check for non-deterministic instructions
- Verify timestamp handling
- Test dependency resolution
Image Signing
Description:
Test:
- Verify signature presence
- Check: Validate signature
Dockerfile Best Practices
Description:
Is the corresponding Dockerfile findable? Are there any suspicious elements? Are best practices being followed?
Test points:
- Verify LABEL maintainer presence
- Check layer optimization:
- Package manager commands combined in single RUN
- Cleanup of package manager caches and temporary files
- Use of multi-stage builds where beneficial
- Removal of unnecessary build dependencies