Scanning images and the SBOM

Key points

• Most findings in a Java image come from base OS packages, not your code. Rebuilding on a fresh base fixes them.
• docker scout cves myapp:1.0 or trivy image myapp:1.0 lists every package it can see and its known CVEs.
• An SBOM is the ingredient list of the image. Produce it at build time so "are we affected" takes seconds, not a day.
• Fail CI on HIGH or CRITICAL that has a fix. Failing on unfixable findings only teaches people to skip the gate.
• Pinning by digest is what makes an upgrade deliberate. Add a scheduled job that bumps the base image and re-scans.

Example

# what is in there, and what is known to be wrong with it
docker scout cves myapp:1.0
docker scout recommendations myapp:1.0     # suggests a newer base

# same job, different tool
trivy image --severity HIGH,CRITICAL --ignore-unfixed myapp:1.0

# write the ingredient list next to the image
docker buildx build --sbom=true --provenance=true -t ghcr.io/acme/myapp:1.0 --push .
docker sbom myapp:1.0 > sbom.json

# the usual fix is one line, then rebuild
#   FROM eclipse-temurin:21.0.4_7-jre  (was 21.0.1_12)

You cannot patch what you cannot list. Generate the SBOM, scan every build.