Vulnerability Scanning

Scanning with Trivy

Trivy inspects OS packages and language dependencies from a vulnerability database it updates on first run:

trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:1.4
trivy image --format json -o report.json myapp:1.4

--exit-code 1 turns findings into a CI failure; pair it with --severity so informational noise does not block merges. Beyond images, trivy fs . finds secrets and trivy config . lints Dockerfiles and IaC — catching RUN curl | sh and root users before the image is even built.

Snyk, Docker Scout, and Reporting

Tools differ in where analysis runs and what they add:

snyk container test myapp:1.4 --severity-threshold=high
docker scout quickview myapp:1.4

Snyk and Scout additionally rank fixes: they tell you that jumping node:20 to a patched digest clears a list of CVEs — the remediation data Trivy's table view lacks.

Pipeline Strategy and Pitfalls

Scan the artifact, not just the Dockerfile. The image contains the final dependency tree; a lockfile scan misses OS packages installed by apt-get.

Gate on what you can fix. Failing CI on every HIGH with no available fix freezes the pipeline; fail on fixable criticals, ticket the rest, and re-scan on a schedule against the registry so aging images get re-evaluated as new CVEs appear.

Provenance of a finding. trivy image --debug-packages-style views and docker history attribute a vulnerable package to the layer that installed it — usually the base tag, which is why digest-pinning and regular base bumps are the highest-leverage fix.

Interview: place scanning in the pipeline (build → scan → push), defend your severity gate, and explain how you would handle a CVE with no upstream fix.