P1ng-W1n
commented
2 years ago Something definitely happened.. Comparing the current state of v1 and v2 databases you can see that v2 does contain way less vulnerabilities when it comes to SLES:
Preparation:
user@localhost:/tmp$ cd trivy-db-check/
user@localhost:/tmp/trivy-db-check$ curl -LO https://github.com/oras-project/oras/releases/download/v0.12.0/oras_0.12.0_linux_amd64.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 669 100 669 0 0 1817 0 --:--:-- --:--:-- --:--:-- 1817
100 4067k 100 4067k 0 0 1641k 0 0:00:02 0:00:02 --:--:-- 2939k
user@localhost:/tmp/trivy-db-check$ tar -xzf oras_0.12.0_linux_amd64.tar.gz
user@localhost:/tmp/trivy-db-check$ ./oras pull ghcr.io/aquasecurity/trivy-db:1 -a
Downloaded b31b6f3a3ef4 db.tar.gz
Pulled ghcr.io/aquasecurity/trivy-db:1
Digest: sha256:cc7cd6d1d872f33e84db39f5ac38208e79b9f4155302ddbd226576a50ac1e23a
user@localhost:/tmp/trivy-db-check$ mkdir v1
user@localhost:/tmp/trivy-db-check$ mv db.tar.gz v1
user@localhost:/tmp/trivy-db-check$ ./oras pull ghcr.io/aquasecurity/trivy-db:2 -a
Downloaded dfb7282d4261 db.tar.gz
Pulled ghcr.io/aquasecurity/trivy-db:2
Digest: sha256:c4a175053535d27b6ea7f3da2916d375144faf69f8e843367bea463050fd5b76
user@localhost:/tmp/trivy-db-check$ mkdir v2
user@localhost:/tmp/trivy-db-check$ mv db.tar.gz v2
user@localhost:/tmp/trivy-db-check$ cd v1
user@localhost:/tmp/trivy-db-check/v1$ tar -xzf db.tar.gz
user@localhost:/tmp/trivy-db-check/v1$ cd ../v2
user@localhost:/tmp/trivy-db-check/v2$ tar -xzf db.tar.gz
user@localhost:/tmp/trivy-db-check/v2$ cd ..
user@localhost:/tmp/trivy-db-check$ ls -l {v1,v2}/trivy.db
-rw------- 1 user user 210743296 jan 4 19:06 v1/trivy.db
-rw------- 1 user user 244178944 febr 25 07:06 v2/trivy.dbCheck:
user@localhost:/tmp/trivy-db-check$ while read -r BUCKET
> do
> echo -n "Number of keys in ${DB} - ${BUCKET}: "
> /data/go/bin/bbolt keys "${DB}" "${BUCKET}" |wc -l
> done < <( /data/go/bin/bbolt buckets "${DB}" |grep SUSE )
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11: 43
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11-PUBCLOUD: 2
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11.1: 130
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11.2: 279
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11.3: 935
Number of keys in v1/trivy.db - SUSE Linux Enterprise 11.4: 1586
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12: 2235
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12.1: 1709
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12.2: 1986
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12.3: 2089
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12.4: 1827
Number of keys in v1/trivy.db - SUSE Linux Enterprise 12.5: 1923
Number of keys in v1/trivy.db - SUSE Linux Enterprise 15: 3077
Number of keys in v1/trivy.db - SUSE Linux Enterprise 15-ESPOS: 1105
Number of keys in v1/trivy.db - SUSE Linux Enterprise 15.1: 3372
Number of keys in v1/trivy.db - SUSE Linux Enterprise 15.2: 2122
Number of keys in v1/trivy.db - SUSE Linux Enterprise 15.3: 1233
Number of keys in v1/trivy.db - openSUSE Leap 15.0: 2785
Number of keys in v1/trivy.db - openSUSE Leap 15.1: 3315
Number of keys in v1/trivy.db - openSUSE Leap 15.2: 2791
Number of keys in v1/trivy.db - openSUSE Leap 15.3: 1821
Number of keys in v1/trivy.db - openSUSE Leap 42.1: 2962
Number of keys in v1/trivy.db - openSUSE Leap 42.2: 2305
Number of keys in v1/trivy.db - openSUSE Leap 42.3: 2753
user@localhost:/tmp/trivy-db-check$ DB=v2/trivy.db
user@localhost:/tmp/trivy-db-check$ while read -r BUCKET
> do
> echo -n "Number of keys in ${DB} - ${BUCKET}: "
> /data/go/bin/bbolt keys "${DB}" "${BUCKET}" |wc -l
> done < <( /data/go/bin/bbolt buckets "${DB}" |grep SUSE )
Number of keys in v2/trivy.db - SUSE Linux Enterprise 12: 171
Number of keys in v2/trivy.db - SUSE Linux Enterprise 12.1: 148
Number of keys in v2/trivy.db - SUSE Linux Enterprise 12.2: 174
Number of keys in v2/trivy.db - SUSE Linux Enterprise 12.3: 81
Number of keys in v2/trivy.db - SUSE Linux Enterprise 15: 211
Number of keys in v2/trivy.db - SUSE Linux Enterprise 15.1: 76
Number of keys in v2/trivy.db - SUSE Linux Enterprise 15.2: 189
Number of keys in v2/trivy.db - SUSE Linux Enterprise 15.3: 99
Number of keys in v2/trivy.db - openSUSE Leap 15.0: 2785
Number of keys in v2/trivy.db - openSUSE Leap 15.1: 3315
Number of keys in v2/trivy.db - openSUSE Leap 15.2: 2791
Number of keys in v2/trivy.db - openSUSE Leap 15.3: 1983
Number of keys in v2/trivy.db - openSUSE Leap 15.4: 139
Number of keys in v2/trivy.db - openSUSE Leap 42.1: 2962
Number of keys in v2/trivy.db - openSUSE Leap 42.2: 2305
Number of keys in v2/trivy.db - openSUSE Leap 42.3: 2753`Although v2 doesn't contain any vulnerabilities for SLES11, The numbers are very much visible on other levels too:
SUSE Linux Enterprise 12.2: 1986 (v1) Vs 148 (v2)
SUSE Linux Enterprise 12.3: 2089 (v1) Vs 174 (v2)
SUSE Linux Enterprise 12.4: 1827 (v1) Vs 81 (v2)
SUSE Linux Enterprise 15: 3077 (v1) Vs 211 (v2)
SUSE Linux Enterprise 15.1: 3372 (v1) Vs 76 (v2)
SUSE Linux Enterprise 15.2: 2122 (v1) Vs 189 (v2)
SUSE Linux Enterprise 15.3: 1233 (v1) Vs 99 (v2)OpenSUSE DB doesn't seem to be affected
zhangyifei
knqyf263
afdesk
Hi Team,
I found one issue on the generating Trivy DB for SUSE Enterprise Server by using the latest code.
I used the latest code to generate an offline DB and use it to scan a SUSE Enterprise image registry.suse.com/suse/sles12sp3:24.324.
trivy --cache-dir cache image --skip-db-update registry.suse.com/suse/sles12sp3:24.324There is no vulnerability found from the scanning result. But this is not correct since I got some vulnerabilities previously for this image.
After rolling back the code to commit a5adda5, the scanning result we got by using the generated DB is correct.
Can you please check which kind of changes make the different results? I'm using Trivy 0.23 on my local to test.
Thanks