Trivy: Trivy 0.2.0, run under docker-dind - gitlabCI - scan always ends with 'null' result

Created on 14 Nov 2019  路  24Comments  路  Source: aquasecurity/trivy

Trivy 0.2.0, run under docker-dind - gitlabCI - scan always ends with 'null' result

What did you expect to happen?
Conduct a scan

What happened instead?
Trivy does something, reports success and exits after 1 second

Output of run with -debug:

2019-11-14T18:51:04.070Z    DEBUG   cache dir:  /root/.cache/trivy
2019-11-14T18:51:04.074Z    DEBUG   This is the first run
[                    ] Downloading Lightweight DB file... 
[=>                  ] Downloading Lightweight DB file... 
[===>                ] Downloading Lightweight DB file... 2019-11-14T18:51:04.362Z  DEBUG   release name: v1-2019111418
2019-11-14T18:51:04.362Z    DEBUG   asset name: trivy-light.db.gz
[=====>              ] Downloading Lightweight DB file... 
[======>             ] Downloading Lightweight DB file... 2019-11-14T18:51:04.534Z  DEBUG   asset URL: https://github-production-release-asset-2e65be.s3.amazonaws.com/216830441/fa14f900-0709-11ea-9b7f-1f882f72ad9e?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20191114%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20191114T185104Z&X-Amz-Expires=300&X-Amz-Signature=4ae948a4ce0501f0edb9eb5585d397ef276d725f95f8ea2af8ade4659264494d&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dtrivy-light.db.gz&response-content-type=application%2Foctet-stream
[========>           ] 
Downloading Lightweight DB file... 
[==========>         ]
Downloading Lightweight DB file... [============>       ] 
Downloading Lightweight DB file... [==============>     ] 
Downloading Lightweight DB file... [================>   ] 
Downloading Lightweight DB file... ==================> ] 
Downloading Lightweight DB file... [===================>] 
Downloading Lightweight DB file... [                    ] 
Downloading Lightweight DB file... [=>                  ] 
Downloading Lightweight DB file... [===>                ]
 Downloading Lightweight DB file... [=====>              ] 
Downloading Lightweight DB file... [======>             ]
 Downloading Lightweight DB file... [========>           ] 
Downloading Lightweight DB file... 019-11-14T18:51:05.858Z  INFO    Reopening vulnerability DB
2019-11-14T18:51:05.858Z    DEBUG   Vulnerability type:  [os library]
2019-11-14T18:51:08.814Z    DEBUG   OS family: alpine, OS version: 3.8.4
2019-11-14T18:51:08.814Z    DEBUG   the number of packages: 36
2019-11-14T18:51:09.612Z    DEBUG   the number of packages from commands: 26
2019-11-14T18:51:09.612Z    DEBUG   the number of packages: 36
2019-11-14T18:51:09.612Z    INFO    Detecting Alpine vulnerabilities...
2019-11-14T18:51:09.612Z    DEBUG   alpine: os version: 3.8
2019-11-14T18:51:09.612Z    DEBUG   alpine: the number of packages: 36

Output of trivy -v:

trivy version 0.2.0

Additional details (base image name, container registry info...):
checked image trivy --light alpine:3.8.4 -debug
dind image - docker:19.03-dind

result:

[
  {
    "Target": "myimage(alpine 3.8.4)",
    "Vulnerabilities": null
  }
]

scan outside gitlabci

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+---------+------------------+----------+-------------------+---------------+
| musl    | CVE-2019-14697   | HIGH     | 1.1.19-r10        | 1.1.19-r11    |
+---------+------------------+----------+-------------------+---------------+
kinbug

All 24 comments

What's the musl version in your image?

$ docker run -it --rm your_image apk info -v | grep musl

Hi @knqyf263
For to ease the test i am running trivy check in gitlabci against public image:
So, when running localy (ubuntu) or test using docker-dind localy I am using:

sudo trivy alpine:3.8.4
2019-11-15T07:30:39.433+0100    INFO    Reopening vulnerability DB
2019-11-15T07:30:39.887+0100    INFO    Detecting Alpine vulnerabilities...

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| musl    | CVE-2019-14697   | HIGH     | 1.1.19-r10        | 1.1.19-r11    | musl libc through 1.1.23       |
|         |                  |          |                   |               | has an x87 floating-point      |
|         |                  |          |                   |               | stack adjustment imbalance,    |
|         |                  |          |                   |               | related...                     |
+---------+------------------+----------+-------------------+---------------+--------------------------------+

as you can see, this image has musl problems.

Running trivy inside gitlab ci against THE SAME image gives this one second scan then exits with 'null'

docker run -it --rm alpine:3.8.4 apk info -v | grep musl
Unable to find image 'alpine:3.8.4' locally
3.8.4: Pulling from library/alpine
c87736221ed0: Pulling fs layer
c87736221ed0: Download complete
c87736221ed0: Pull complete
Digest: sha256:04696b491e0cc3c58a75bace8941c14c924b9f313b03ce5029ebbc040ed9dcd9
Status: Downloaded newer image for alpine:3.8.4
musl-1.1.19-r10
musl-utils-1.1.19-r10

can you paste your gitlab-ci.yaml file. It is strange because i am running 0.2.0 in gitlab I have dozens of builds with this version already and it is working pretty well.

Well, there is nothing strange there.
Trivy downloads, runs, scans, but result is 'null'.
DB is there, same size as runnin manually

 DOCKER_HOST: tcp://docker:2375
 DOCKER_DRIVER: overlay2
 DOCKER_TLS_CERTDIR: ""
 GIT_SUBMODULE_STRATEGY: recursive
docker_retag:
  retry: 2
  stage: docker_retag
  image: docker:stable
  services:
    - docker:$DOCKER_DIND
  before_script:
    - docker info
    - export IMAGE_VER=$(cat data/image)
    - export TAG_VER=$(cat data/tag)
    - export IMAGE_BASENAME=$(cat data/image_basename)
    - sh ./pipeline/trivy_init.sh
  script:
    - docker login xxx
    - docker login yyy
    - docker pull $IMAGE_VER:$TAG_VER
    - sh ./pipeline/trivy_run.sh
# if no failure - push
    - docker tag xxx
    - docker push yyy
  artifacts:
    expire_in: 1d
    paths:
      - data/
  only:
    - web
    - trigger

Another sets of test 0.1.7 vs 0.2.0

docker_retag:
  retry: 2
  stage: docker_retag
  image: docker:stable
  services:
    - docker:$DOCKER_DIND
  script:
    - apk add --no-cache --update curl wget grep sed git
    - wget -q https://github.com/aquasecurity/trivy/releases/download/v0.1.7/trivy_0.1.7_Linux-64bit.tar.gz
    - tar zxf trivy_0.1.7_Linux-64bit.tar.gz
    - mv trivy /usr/local/bin
    - chmod +x /usr/local/bin/trivy
    - docker pull alpine:3.8.4
    - docker image ls
    - /usr/local/bin/trivy -debug alpine:3.8.4
  artifacts:
    expire_in: 1d
    paths:
      - data/
  only:
    - web
    - trigger

and 0.1.7 result

2019-11-15T15:09:14.227Z    DEBUG   Vulnerability type:  [os library]
2019-11-15T15:09:14.332Z    DEBUG   OS family: alpine, OS version: 3.8.4
2019-11-15T15:09:14.332Z    DEBUG   the number of packages: 16
2019-11-15T15:09:15.523Z    DEBUG   the number of packages from commands: 0
2019-11-15T15:09:15.523Z    DEBUG   the number of packages: 16
2019-11-15T15:09:15.523Z    INFO    Detecting Alpine vulnerabilities...
2019-11-15T15:09:15.523Z    DEBUG   alpine: os version: 3.8
2019-11-15T15:09:15.523Z    DEBUG   alpine: the number of packages: 16

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| musl    | CVE-2019-14697   | HIGH     | 1.1.19-r10        | 1.1.19-r11    | musl libc through 1.1.23       |
|         |                  |          |                   |               | has an x87 floating-point      |
|         |                  |          |                   |               | stack adjustment imbalance,    |
|         |                  |          |                   |               | related...                     |
+---------+------------------+----------+-------------------+---------------+--------------------------------+

0.2.0

docker_retag:
  retry: 2
  stage: docker_retag
  image: docker:stable
  services:
    - docker:$DOCKER_DIND
  script:
    - apk add --no-cache --update curl wget grep sed git
    - wget -q https://github.com/aquasecurity/trivy/releases/download/v0.2.0/trivy_0.2.0_Linux-64bit.tar.gz
    - tar zxf trivy_0.2.0_Linux-64bit.tar.gz
    - mv trivy /usr/local/bin
    - chmod +x /usr/local/bin/trivy
    - docker pull alpine:3.8.4
    - docker image ls
    - /usr/local/bin/trivy -debug alpine:3.8.4
  artifacts:
    expire_in: 1d
    paths:
      - data/
  only:
    - web
    - trigger

and 0.2.0 result

2019-11-15T15:14:44.248Z    DEBUG   Vulnerability type:  [os library]
2019-11-15T15:14:44.363Z    DEBUG   OS family: alpine, OS version: 3.8.4
2019-11-15T15:14:44.363Z    DEBUG   the number of packages: 16
2019-11-15T15:14:45.176Z    DEBUG   the number of packages from commands: 0
2019-11-15T15:14:45.176Z    DEBUG   the number of packages: 16
2019-11-15T15:14:45.176Z    INFO    Detecting Alpine vulnerabilities...
2019-11-15T15:14:45.176Z    DEBUG   alpine: os version: 3.8
2019-11-15T15:14:45.176Z    DEBUG   alpine: the number of packages: 16

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

Hmm... in my environment, it works. I have no idea. What's your digest of the image in CI? Please paste the result of docker image ls.

Just in case, would you try the following?

    - docker image ls
    - docker run --rm alpine:3.8.4 apk info -v 
    - /usr/local/bin/trivy --reset
    - /usr/local/bin/trivy -debug alpine:3.8.4

for 0.2.0 digest is

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              3.8.4               dac705114996        8 months ago        4.41MB

for 0.1.7 digest is

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              3.8.4               dac705114996        8 months ago        4.41MB

I am stuck, can't find any other test to conduct

$ apk add --no-cache --update curl wget grep sed git
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/10) Installing nghttp2-libs (1.39.2-r0)
(2/10) Installing libcurl (7.66.0-r0)
(3/10) Installing curl (7.66.0-r0)
(4/10) Installing expat (2.2.8-r0)
(5/10) Installing pcre2 (10.33-r0)
(6/10) Installing git (2.22.0-r0)
(7/10) Installing pcre (8.43-r0)
(8/10) Installing grep (3.3-r0)
(9/10) Installing sed (4.7-r0)
(10/10) Installing wget (1.20.3-r0)
Executing busybox-1.30.1-r2.trigger
OK: 22 MiB in 25 packages
$ wget -q https://github.com/aquasecurity/trivy/releases/download/v0.2.0/trivy_0.2.0_Linux-64bit.tar.gz
$ tar zxf trivy_0.2.0_Linux-64bit.tar.gz
$ mv trivy /usr/local/bin
$ chmod +x /usr/local/bin/trivy
$ docker pull alpine:3.8.4
3.8.4: Pulling from library/alpine
c87736221ed0: Pulling fs layer
c87736221ed0: Verifying Checksum
c87736221ed0: Download complete
c87736221ed0: Pull complete
Digest: sha256:04696b491e0cc3c58a75bace8941c14c924b9f313b03ce5029ebbc040ed9dcd9
Status: Downloaded newer image for alpine:3.8.4
docker.io/library/alpine:3.8.4
$ docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              3.8.4               dac705114996        8 months ago        4.41MB
$ docker run --rm alpine:3.8.4 apk info -v
musl-1.1.19-r10
WARNING: Ignoring APKINDEX.adfa7ceb.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.efaa1f73.tar.gz: No such file or directory
busybox-1.28.4-r3
alpine-baselayout-3.1.0-r0
alpine-keys-2.1-r1
libressl2.7-libcrypto-2.7.5-r0
libressl2.7-libssl-2.7.5-r0
libressl2.7-libtls-2.7.5-r0
ssl_client-1.28.4-r3
zlib-1.2.11-r1
apk-tools-2.10.1-r0
scanelf-1.2.3-r0
musl-utils-1.1.19-r10
libc-utils-0.7.1-r0
$ /usr/local/bin/trivy --reset
2019-11-15T16:06:25.515Z    DEBUG   cache dir:  /root/.cache/trivy
2019-11-15T16:06:25.622Z    DEBUG   This is the first run
[                    ] Downloading Full DB file... [=>                  ] Downloading Full DB file... [===>                ] Downloading Full DB file... [=====>              ] Downloading Full DB file... 2019-11-15T16:06:25.928Z    DEBUG   release name: v1-2019111515
2019-11-15T16:06:25.928Z    DEBUG   asset name: trivy-light.db.gz
2019-11-15T16:06:25.928Z    DEBUG   file name doesn't match
2019-11-15T16:06:25.928Z    DEBUG   asset name: trivy.db.gz
[======>             ] Downloading Full DB file... 2019-11-15T16:06:26.105Z DEBUG   asset URL: https://github-production-release-asset-2e65be.s3.amazonaws.com/216830441/08bae900-07ba-11ea-98d3-341d413eecce?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20191115%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20191115T160626Z&X-Amz-Expires=300&X-Amz-Signature=6d3514b8a2e891f9dcc5215fb97c59629767c42ff2eb89134d1d912a2ba61ee7&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dtrivy.db.gz&response-content-type=application%2Foctet-stream
2019-11-15T16:06:39.740Z    DEBUG   Vulnerability type:  [os library]
2019-11-15T16:06:39.845Z    DEBUG   OS family: alpine, OS version: 3.8.4
2019-11-15T16:06:39.845Z    DEBUG   the number of packages: 16
2019-11-15T16:06:40.413Z    DEBUG   the number of packages from commands: 0
2019-11-15T16:06:40.413Z    DEBUG   the number of packages: 16
2019-11-15T16:06:40.413Z    INFO    Detecting Alpine vulnerabilities...
2019-11-15T16:06:40.413Z    DEBUG   alpine: os version: 3.8
2019-11-15T16:06:40.413Z    DEBUG   alpine: the number of packages: 16

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

I cannot reproduce it... What's $DOCKER_DIND?

Oh, sorry I found. docker:19.03-dind

Sorry, it's: 19.03-dind
I am using tagged version instead of stable/latest

Yeah, I understand. These kinds of errors are the worst.
As a base I am using Centos7 (gitlab runners)
https://app.vagrantup.com/marcinbojko/boxes/centos7

$ docker run --rm --privileged --name dind docker:19.03-dind
$ docker exec -it dind sh
/ # wget -q https://github.com/aquasecurity/trivy/releases/download/v0.2.0/trivy_0.2.0_Linux-64bit.tar.gz
/ # tar zxf trivy_0.2.0_Linux-64bit.tar.gz
/ # mv trivy /usr/local/bin
/ # chmod +x /usr/local/bin/trivy
/ # docker pull alpine:3.8.4
3.8.4: Pulling from library/alpine
c87736221ed0: Pull complete
Digest: sha256:04696b491e0cc3c58a75bace8941c14c924b9f313b03ce5029ebbc040ed9dcd9
Status: Downloaded newer image for alpine:3.8.4
docker.io/library/alpine:3.8.4
/ # docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              3.8.4               dac705114996        8 months ago        4.41MB
/ # /usr/local/bin/trivy -debug alpine:3.8.4
...

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| musl    | CVE-2019-14697   | HIGH     | 1.1.19-r10        | 1.1.19-r11    | musl libc through 1.1.23       |
|         |                  |          |                   |               | has an x87 floating-point      |
|         |                  |          |                   |               | stack adjustment imbalance,    |
|         |                  |          |                   |               | related...                     |
+---------+------------------+----------+-------------------+---------------+--------------------------------+

I tested on docker:19.03-dind, but the vulnerability was detected. Is my test wrong?

Your test was perfect. Even on the same node (gitlab runner) doing THE SAME test, they are success. But through gitlab-ci it does zero.
So I suppose there is something related with gitlab/gitlab runner or it's settings which are blocking this.

Well, for a time being I am back to 0.1.7, lightning fast scans will have to wait.
If I could provide extra-super-duper-debug info - let me know, and BIG thanks for support and Trivy!

@knqyf263 sorry for spam, but I think I've found the reason ;)
So, for some reason, when using just defaults:

trivy -debug  alpine:3.8.4

under anything which is not dind at gitlab-ci, it works. I began to think, why 2 scans have almost everything in common, and I've found out- for SOME reason, severity default value is not casted/rendered properly in that env.
So, replacing 'get the default, i don't care setting' with:

trivy -debug -s "UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL" alpine:3.8.4

when WE decide what's default - works.

alpine:3.8.4 (alpine 3.8.4)
===========================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| musl    | CVE-2019-14697   | HIGH     | 1.1.19-r10        | 1.1.19-r11    | musl libc through 1.1.23       |
|         |                  |          |                   |               | has an x87 floating-point      |
|         |                  |          |                   |               | stack adjustment imbalance,    |
|         |                  |          |                   |               | related...                     |
+---------+------------------+----------+-------------------+---------------+--------------------------------+

Oh, what is the reason?

Beats me, I am only a user here ;)

No problem馃槃
If it is helpful for other users, it would be appreciated if you write down the detail. If no, let me close this one.

It's up to you - but, just maybe - if we can keep this open for a week or so, to check if there will be some others with cases like this, it can save some time - especially when scan passes in CI and it can be discovered after several days.
Details are here: https://github.com/aquasecurity/trivy/issues/271#issuecomment-554460890

Oh, I saw your comment before updating and overlooked the detail. Thank you for the explanation!

I think it's better to display target severities in a debug log. I'll work on it later.

Thanks for the update. Dind is super buggy... its a pain. That is why i now build with kaniko.

I have trivy -s always set.
Ill try to remove it and see if i get the same

Was this page helpful?
0 / 5 - 0 ratings

Related issues

abedra picture abedra  路  4Comments

adel-s picture adel-s  路  4Comments

knqyf263 picture knqyf263  路  3Comments

lizrice picture lizrice  路  5Comments

okazaki-hajime-ca picture okazaki-hajime-ca  路  6Comments