A container image carries far more than your code: a base operating system, language runtime and every transitive package. Any of them can ship with a published vulnerability. The cheapest place to find out is the pipeline, before the image reaches a cluster.
Know what is inside: an SBOM
A software bill of materials lists every package in the image with its version. Generate it on every build and keep it with the release, so when a new vulnerability is announced you can answer “are we affected?” by searching files instead of rebuilding images.
Scan and fail the build
# GitHub Actions, after the image is built
- name: SBOM
run: syft "$IMAGE" -o spdx-json > sbom.json
- name: Scan SBOM
run: grype sbom:sbom.json --fail-on high
- name: Scan image
run: trivy image --exit-code 1 --severity CRITICAL "$IMAGE"A high or critical finding stops the deploy. The developer sees it in the same pull request that introduced it, while the change is still fresh.
Keep the noise down
- Start from small, maintained base images; fewer packages means fewer findings.
- Rebuild images on a schedule, not only on code changes, so base-image fixes land without waiting for a feature.
- Record accepted risks in an ignore file with a reason and an expiry date, so exceptions are reviewed rather than forgotten.
None of this replaces runtime security, but it moves a whole class of problems to the cheapest point to fix them: before deploy.
TechSea engineering team