How to scan a Docker image for vulnerabilities
Updated
A website address tells you nothing about the packages inside a container. To find out whether an image contains known vulnerable software, scan the image itself.
Why a URL scan is not enough
An external scan sees only what a server announces. The operating system packages, the PHP runtime, OpenSSL and the CA certificate bundle live inside the image. Only an image scan can inspect them, so a responsible scanner never calls an image vulnerable based on a website URL.
Scan with Trivy
trivy image registry.example.com/company/application:1.4.2Limit the output to the findings you act on first, and fail a CI job when they appear:
trivy image --severity CRITICAL,HIGH --exit-code 1 registry.example.com/company/application:1.4.2For a private registry, authenticate first (for example docker login) or provide credentials through Trivy's environment variables.
Read the results
Results are grouped by severity: critical, high, medium, low and unknown. Look first at the PHP runtime, OpenSSL, the CA certificates bundle and the base operating system packages, then application dependencies. A fixed version column tells you whether an upgrade already exists.
Fix it
Most findings are fixed by rebuilding on a patched base image, not by editing the application:
docker build --pull -t registry.example.com/company/application:1.4.3 .
docker push registry.example.com/company/application:1.4.3Take the target version from the vendor advisory, redeploy using your normal process, then scan the new tag to confirm the finding is gone.
What an image scan does not prove
It matches installed package versions to vulnerability databases. It does not prove a flaw is reachable in your deployment, so use severity and exposure to prioritise.
Frequently asked questions
Can a website scan detect vulnerabilities inside a Docker image?
No. Only scanning the image itself reveals its packages. A website scan can only read what the running server announces.
How often should I scan images?
On every build, and again on a schedule, because new vulnerabilities are published for packages that were clean when you built.