Containerization brought real speed and consistency to modern software delivery. Still, Docker images can become risky without proper attention — vulnerabilities can stay hidden inside layers and dependencies.
The solution is to build security directly into the CI/CD workflow. This approach catches issues during build, testing, and release stages. Below are several practical techniques that help keep container images secure from the very beginning.
Why Security Belongs in CI/CD
Traditional security scans that only run after deployment are usually too late and quite expensive. Shifting security left — into the early development and CI/CD stages — helps you fix issues much cheaper and prevents many breaches before they happen.
Every Docker image built from an untrusted base, with outdated packages, or with unnecessary ports open creates a real entry point for attackers.
Automating security checks inside your pipeline lets you maintain consistent standards without slowing the development team down.
1. Choose Minimal and Trusted Base Images
Start with a minimal base image. This is one of the simplest ways to improve Docker security.
Alpine, Distroless, and UBI remove shells, package managers, and extra binaries. That means a smaller attack surface.
Compare the sizes: Ubuntu: the latest is over 70 MB. alpine:3.19 is only around 7 MB. The smaller image gets rid of hundreds of unnecessary tools.
Finally, avoid using the latest. Pin your base image to a specific digest instead. This gives you reproducible builds and stops surprise vulnerabilities from updates.
2. Scan Images for Vulnerabilities Early
Integrating vulnerability scanning right after the image build prevents issues from moving further down the pipeline. The tools examine each layer, check packages against CVE databases, and assign severity scores.
Teams often compare two popular options: Snyk and Trivy. Each has clear strengths:
- Snyk brings great IDE integration, detailed fix suggestions, and dependency graphs (though advanced use needs a license).
- Trivy is fully open-source, super quick in pipelines, and also scans IaC files.
If you’re trying to decide, read a detailed Snyk vs Trivy comparison. Both produce SARIF reports, so they work with GitHub Advanced Security or GitLab SAST dashboards without hassle.
In practice, run scans on every pull request and block merges when critical vulnerabilities turn up. Set clear fail thresholds.
For example, fail the build if any vulnerability with a CVSS score of 7.0 or higher shows up and doesn’t have a fix available yet.
3. Enforce Least Privilege in Dockerfiles
Many Docker images run as root by default, violating the principle of least privilege. Add a non-root user early in your Dockerfile:
dockerfile
FROM node:20-alpine
RUN addgroup -g 1001 -S appgroup && \
adduser -u 1001 -S appuser -G appgroup
USER appuser
Another important step is removing unnecessary tools. Production images should not include utilities such as curl, wget, or git. Multi-stage builds make this easy to achieve by separating the build environment from the runtime one.
dockerfile
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM alpine:3.19
COPY –from=builder /app/myapp /myapp
CMD [“/myapp”]
The resulting image contains only the compiled binary and nothing else — no compilers, no package managers, no extra shells.
4. Scan for Secrets and Sensitive Data
Exposed secrets in Docker images create serious risks. API keys, tokens, or private keys accidentally baked into an image can leak as soon as someone pulls it from a registry.
That’s why adding secret scanning early in the pipeline makes a big difference. Tools like TruffleHog, GitLeaks, and Trivy’s built-in secret scanner work well for this.
Here’s a practical setup most teams use in CI/CD — run it right before pushing the image:
yaml
– name: Scan for secrets
run: trivy image –severity HIGH, CRITICAL –scanners secret myapp: latest
If the scan finds anything, the pipeline should fail immediately. Then rotate any exposed credentials right away.
Also, avoid broad commands like COPY… Instead, create a .dockerignore file to keep sensitive folders out of the image from the start — things like .env, .git, and .aws/.
5. Sign and Verify Images
Image signing prevents tampering and ensures that only authorized builds reach production. Docker Content Trust (DCT) and Sigstore’s Cosign provide cryptographic signatures. Enable DCT in your CI pipeline:
bash
export DOCKER_CONTENT_TRUST=1
docker push myapp: latest
Alternatively, use Cosign to generate key pairs and sign images:
bash
cosign generate-key-pair
cosign sign –key cosign.key myapp: latest
In your deployment stage, verify signatures before pulling: cosign verify –key cosign.pub myapp: latest. This blocks compromised images from entering Kubernetes or ECS clusters.
6. Regular Base Image Updates
New vulnerabilities come out all the time. So automate weekly base image rebuilds with tools like Dependabot or Renovate. Set your CI to re-scan whenever base images update.
Example in GitHub Actions:
yaml
name: Weekly Security Rebuild
on:
schedule:
– cron: ‘0 0 * * 0’ # Every Sunday
jobs:
rebuild:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Rebuild and scan
run: |
docker build -t myapp: latest.
trivy image –exit-code 1 –severity CRITICAL myapp:latest
7. Implement Admission Control in Orchestrators
CI/CD security goes beyond the registry. Strong admission controllers add one last safety net before anything runs in the cluster.
Kubernetes tools like OPA Gatekeeper or Kyverno let teams enforce strict runtime rules. They can block root containers, require read-only root filesystems, and reject images that are older than 30 days without a recent scan. This final check stops risky pods from starting.
Common Pitfalls to Avoid
Only scanning the finished image — vulnerabilities often hide in intermediate layers. Scan after every RUN with –scan-all-layers.
Skipping OS updates — packages from apt, apk, or yum age fast. Add upgrade commands like apk upgrade –no-cache.
Saving scan reports without enforcement — always connect SBOMs and scan results to blocking policies.
Conclusion
A defense-in-depth approach works well for Docker images in CI/CD. Focus on minimal base images, automated scans, secret detection, image signing, and admission control. Start with just one scanner, then gradually tighten the rest.
Each secured image reduces exposure to supply chain attacks and zero-day threats. Security is ongoing, so review your policies as new risks come up.