Container vulnerability analysis

[andreasmihm]

Hi,

when I want to monitor the vulns for a image like traefik, I would create a sbom from it with
docker sbom --format cyclonedx-json traefik > traefik-sbom.json
Then I would import that into dependencyTrack. I see 24 vulnerabiliuties

If I use
docker scan traefik
to check the vulnerabilities for this image with docker tooling it gives me:

Testing traefik...

Package manager:   apk
Project name:      docker-image|traefik
Docker image:      traefik
Platform:          linux/arm64

✔ Tested 16 dependencies for known vulnerabilities, no vulnerable paths found.

What is the reason for this totally different result?

[andreasmihm]

PS: An even better way would be to add the used images into dependencyTrack just with their package url/CPE/SWID.
But I was not able to find a cpe/swid or construct a packageurl for an image from docker hub.
Is that possible/availabe?

Dependency Track has a component classifier 'Container'. How would I add/create a container component?

[syalioune]

Hello @andreasmihm

My two cents.
The principal reason for the results to be so different is that docker also use completely different tools depending on which command you issue,

sbom use syft which walk through the container layer FS and detect many thing ranging from OS Packages, JAR files to Golang packages hence why the SBOM generated by docker sbom ... has more than 250 components (most of them are Golang libs which is normal because Traefik is implemented with go).

scan use snyk . Even though I don't know the details on how it works, you can clearly see using the command below that it doesn't detect as much components in the image as syft does (16 vs 274) hence the severe difference between DT and scan

docker scan --dependency-tree traefik
docker-image|traefik @ latest
   ├─ alpine-baselayout/alpine-baselayout @ 3.2.0-r18
   │  ├─ busybox/busybox @ 1.34.1-r7
   │  └─ musl/musl @ 1.2.2-r7
   ├─ alpine-keys/alpine-keys @ 2.4-r1
   ├─ apk-tools/apk-tools @ 2.12.7-r3
   │  ├─ ca-certificates/ca-certificates-bundle @ 20220614-r0
   │  ├─ musl/musl @ 1.2.2-r7
   │  ├─ openssl/libcrypto1.1 @ 1.1.1q-r0
   │  ├─ openssl/libssl1.1 @ 1.1.1q-r0
   │  └─ zlib/zlib @ 1.2.12-r3
   ├─ busybox/busybox @ 1.34.1-r7
   │  └─ musl/musl @ 1.2.2-r7
   ├─ busybox/ssl_client @ 1.34.1-r7
   │  ├─ libretls/libretls @ 3.3.4-r3
   │  └─ musl/musl @ 1.2.2-r7
   ├─ ca-certificates/ca-certificates @ 20220614-r0
   │  ├─ busybox/busybox @ 1.34.1-r7
   │  ├─ musl/musl @ 1.2.2-r7
   │  └─ openssl/libcrypto1.1 @ 1.1.1q-r0
   ├─ ca-certificates/ca-certificates-bundle @ 20220614-r0
   ├─ libc-dev/libc-utils @ 0.7.2-r3
   │  └─ musl/musl-utils @ 1.2.2-r7
   ├─ libretls/libretls @ 3.3.4-r3
   │  ├─ ca-certificates/ca-certificates-bundle @ 20220614-r0
   │  ├─ musl/musl @ 1.2.2-r7
   │  ├─ openssl/libcrypto1.1 @ 1.1.1q-r0
   │  └─ openssl/libssl1.1 @ 1.1.1q-r0
   ├─ musl/musl @ 1.2.2-r7
   ├─ musl/musl-utils @ 1.2.2-r7
   │  ├─ musl/musl @ 1.2.2-r7
   │  └─ pax-utils/scanelf @ 1.3.3-r0
   ├─ openssl/libcrypto1.1 @ 1.1.1q-r0
   │  └─ musl/musl @ 1.2.2-r7
   ├─ openssl/libssl1.1 @ 1.1.1q-r0
   │  ├─ musl/musl @ 1.2.2-r7
   │  └─ openssl/libcrypto1.1 @ 1.1.1q-r0
   ├─ pax-utils/scanelf @ 1.3.3-r0
   │  └─ musl/musl @ 1.2.2-r7
   ├─ tzdata/tzdata @ 2022a-r0
   │  └─ musl/musl @ 1.2.2-r7
   └─ zlib/zlib @ 1.2.12-r3
      └─ musl/musl @ 1.2.2-r7

None of the golang libs are detected.

AFAIK it's not possible to represent a docker image with purl/cpe nor there is any vulnerability database supporting this use case. You'll have to generate a SBOM with the most accurate content of your Docker image.