Docker Image Security: Scanning and Best Practices for Java
Fast recall
Quick revision
Core answer
Security awareness in container image lifecycle — a growing interview topic as container security audits become standard
Thinking application security is enough — base image CVEs are a real attack vector and many teams ship images with hundreds of known vulnerabilities from outdated base images
Mention specific tools (Trivy, Grype, Docker Scout), discuss distroless images for zero shell attack surface, and explain why secrets in image layers (even deleted) are extractable
Interview-ready guide
Interview answer
Container image scanning catches known CVEs in your base image, installed packages, and application dependencies before the image reaches production. Scanning is a quality gate, not just a reporting tool.
Where vulnerabilities come from
- Base image vulnerabilities: an
ubuntu:22.04ordebian:bullseyebase image includes hundreds of packages, each a potential CVE surface — a 6-month-old base image often carries critical CVEs in OpenSSL, glibc, or curl that patches have already fixed - Application dependency vulnerabilities: Trivy and Grype scan JAR files inside the image, reading the Maven/Gradle dependency tree embedded in the manifest — a vulnerable Jackson or Log4j version surfaces here even if the OS is clean
- Language runtime vulnerabilities: the JVM itself has CVEs; pinning to a specific JRE base image tag means you miss security patches; use a floating minor-version tag (
eclipse-temurin:21-jre) and rebuild regularly
Tooling
- Trivy is the current standard for CI integration —
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latestfails the CI build on any high or critical CVE;--severity MEDIUMis too noisy for a quality gate - GitHub Container Registry and AWS ECR both have built-in scanning; configure automated scanning on push and block deployment from registries with unfixed critical CVEs
docker scout cves myapp:latest(Docker Scout) provides CVE information directly in the Docker CLI — useful for local investigation but Trivy's CI integration is more configurable
Minimizing the attack surface
- Use distroless or Alpine base images for production —
gcr.io/distroless/java21-debian12contains only the JRE and necessary runtime libraries; no shell, no package manager, no curl; fewer installed components means fewer CVE targets - Distroless images trade debugging ease for security:
docker exec -itinto a distroless container gives you no shell; use ephemeral debug containers in Kubernetes or add a Busybox sidecar for troubleshooting in non-production environments - Multi-stage builds ensure the build tooling (Maven, JDK, source code) never enters the final scanned image — the scanner only sees the minimal runtime artifact
Docker Image Security: Scanning and Best Practices for Java
Direct Answer
Key practices: use minimal base images (Alpine/distroless) to reduce attack surface, scan images with Trivy/Snyk for known CVEs, never embed secrets in images, run as non-root, keep base images updated, and use multi-stage builds to exclude build tools from the final image. CI/CD should fail on critical CVEs before pushing to registry.
Common Mistakes & Pitfalls
Thinking application security is enough — base image CVEs are a real attack vector and many teams ship images with hundreds of known vulnerabilities from outdated base images
Check your understanding
Answer these without looking back at the article.
- What is the difference between Trivy and Snyk for container image scanning?
- How does a distroless image differ from a minimal Alpine-based image?
- How do you inject secrets into a Docker container at runtime securely?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.