CVE-2021-44228 (log4shell) suggesting 2.15 instead of 2.16, it's preferable

Gemnasium provides a vuln source, which could be utilized by trivy as well: https://gitlab.com/gitlab-org/security-products/gemnasium-db

Hi,

At the moment we are running Trivy 0.19.2 in our CI. We are not able to update this version due to how Trivy changes they way it scans yarn.lock files. I noticed that these scans are not find CVE-2022-22965 (GHSA-36p3-wjmg-h94x).
However, if I scan locally using the latest version of Trivy, it does pick up that CVE.

From digging around I noticed that the trivy-db schema has changed with Trivy 0.23.0 from 1 to 2.

Why is Trivy not finding these CVEs when using the older DB schema?

Please let me know what additional information you require.

Description

OSV also has GHSA-IDs. But Trivy DB already stores them via GHSA. We should skip them to avoid duplication.

PRs

• #161

The DB assets should include metadata.json file after merged #47

Red Hat and Debian have rejected vulnerabilities.
https://github.com/aquasecurity/vuln-list/blob/87adb4be299639a338664e235ee975f978f8471d/redhat/2013/CVE-2013-0341.json#L47
https://github.com/aquasecurity/vuln-list/blob/844881957e39b6f8a3d8fbbe61d5f7bf298184df/ubuntu/2013/CVE-2013-5575.json#L11

We should not store these vulnerabilities in trivy-db as it introduces false positives.

Description

GitHub may have a different CVSS score from NVD. Trivy DB should store it.
https://nvd.nist.gov/vuln/detail/CVE-2022-21667

Why the generated trivy.db file is 1.2G and the official one is only <30M

Add CPE information to the vulnerability bucket.
https://github.com/aquasecurity/vuln-list/blob/main/nvd/2021/CVE-2021-0109.json#L6-L24

We can replace this step with the golangci-lint-action.

I shall submit a PR if this a valid issue.

safety-db sometimes has multiple CVE-IDs.

• https://github.com/pyupio/safety-db/blob/9cb84541a691044512dab8422dc2a36383e0fff3/data/insecure_full.json#L14132
• https://github.com/pyupio/safety-db/blob/9cb84541a691044512dab8422dc2a36383e0fff3/data/insecure_full.json#L15651

They should be stored separately.

Trivy (the docker container) appears to be incorrectly reporting issues in almost everything it's scanning on debian. A scan yesterday reported no issues, today it shows 132 High and 22 Critical.

Looking at just one part for example, curl. Trivy reports this:

+---------------------+------------------+----------+-----------------------+---------------+
| curl                | CVE-2016-4606    | CRITICAL | 7.64.0-4+deb10u2      |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2016-9953    |          |                       |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2017-2628    |          |                       |               |
+                     +------------------+----------+                       +---------------+
|                     | CVE-2016-4802    | HIGH     |                       |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2016-9594    |          |                       |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2016-9952    |          |                       |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2019-5443    |          |                       |               |
+                     +------------------+          +                       +---------------+
|                     | CVE-2021-22901   |          |                       |               |
+---------------------+------------------+          +-----------------------+---------------+

Checking all of these CVE's on security-tracker.debian.org show that they are all fixed in the specified version 7.64.0-4+deb10u2

This change seems to have been after the the most recent commit 485692c

We are using the docker container aquasec/trivy:0.19.2@sha256:dea76d4b50c75125cada676a87ac23de2b7ba4374752c6f908253c3b839201d9 for scanning with the command options --light --exit-code 1 --ignorefile .trivyignore --severity HIGH,CRITICAL

Is there any more information that would be helpful?

Currently downloading the latest trivy-offline-db and using these assets in an air gapped environment raises the following error:

2022-02-01T11:06:40.539Z        ERROR   The local DB has an old schema version which is not supported by the current version of Trivy CLI. It
needs to be updated.
2022-02-01T11:06:40.539Z        FATAL   DB error: database error: validate error: --skip-update cannot be specified with the old DB schema

Replicate with these cmds:

wget https://github.com/aquasecurity/trivy-db/releases/latest/download/trivy-offline.db.tgz
mkdir -p trivy/db
cd trivy/db
tar xvf trivy-offline.db.tgz

# verify the matadata
cat metadata.json
# File: metadata.json 
# {"Version":1,"Type":1,"NextUpdate":"2022-02-01T12:39:57.229393312Z","UpdatedAt":"2022-02-01T06:39:57.229393912Z","DownloadedAt":"0001-01-01T00:00:00Z"}

# run trivy
cd ..
TRIVY_CACHE_DIR=$(pwd) trivy image --skip-update alpine:latest

# see above error

As a dirty hack you can supress the error with:

sed -i 's/\"Version\"\:1/"Version":2/g' db/metadata.json

and then rerun the above trivy command.

Although this obviously isn't ideal.

Can we get a fix for this ASAP as removing the --skip-update from from our air gapped enviroment isn't possible.

Thanks

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.324

There 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

Hi @simar7 any reason why the trivy-db binary is part of the repo - https://github.com/aquasecurity/trivy-db/blob/master/cmd/trivy-db/trivy-db? I have a PR to remove it, please feel free to close it, if it's irrelevant. Thanks!

In the trivi.db "vulnerabity" bucket, the CVE-yyyy-id is collecting "VendorSeverity", vendor specific "CVSS" scores and url "References" data from redhat, oracle, ubuntu, ... but not from SUSE.

For SUSE, this data is instead stored only into a specific SUSE-SU-... or òpenSUSE-SU-...` entry.

The corresponding fields are available in the testing data pkg/vulnsrc/suse-cvrf/testdata. The SUSE specific CVSSScoreSets are empty here, but they are populated in more recent files, like cvrf/suse/opensuse/2015/openSUSE-SU-2015-0225-1.json

Is this a feature or a bug?

Should the SUSE VendorSeverity, CVSS and References from the be added to the CVE from the SUSE-*.json data? instead of creating a SUSE-SU item? or in addition?

Hi all,

As the mention above, how should i open the two files downloaded from the site?
I want to see the difference between them.
Any suggestions?
The main reason is that when i use trivy scan the same image, but with --light will not encountered vulnerability report and without --light will.
But the "--light" was only different from not showing the description and the CVE reference ?

Thanks,

the maven vulns source is use snyk/vulnerabilitydb ?

Looks like they nodejs/security-wg migrated master to main
https://github.com/nodejs/security-wg/commits/main

What is the purpose of the update interval? I don't really understand

You will see the following error when you build the database with Go 1.14.

$ make db-build
./trivy-db build  --cache-dir cache --update-interval 12h
2020/03/31 14:53:09 Updating vulnerability database...
2020/03/31 14:53:09 Updating alpine data...
2020/03/31 14:53:11 Saving Alpine DB
2020/03/31 14:53:38 Updating redhat data...
2020/03/31 14:53:42 Saving RedHat DB
2020/03/31 14:55:15 Updating php-security-advisories data...
2020/03/31 14:55:16 Updating debian-oval data...
2020/03/31 14:55:28 Saving Debian OVAL
2020/03/31 14:55:40 Updating ruby-advisory-db data...
2020/03/31 14:55:40 Updating nodejs-security-wg data...
2020/03/31 14:55:40 error in nodejs-security-wg update: failed to update node vulnerabilities: batch update failed: error in batch update: failed to walk node advisories: json: invalid number literal, trying to unmarshal "\"4.8 (Medium)\"" into Number
make: *** [db-build] Error 1

This is caused by this change.
golang/go#34272

nodejs-security-wg has both float like 5.2 and string like "4.8 (Medium)" in the same key. But "4.8 (Medium)" is an invalid number and json.Number no longer accepts it after Go 1.14.

I think we have to implement our original type as suggested here.
https://go.googlesource.com/go/+/master/doc/go1.14.html?autodive=0%2F%2F%2F%2F%2F#602

In the case of CVE-2018-10754, Red Hat doesn't say it is rejected.
https://access.redhat.com/security/cve/CVE-2018-10754

But NVD describes it is rejected.
https://nvd.nist.gov/vuln/detail/CVE-2018-10754

In this case, we have to skip this vulnerability even if Red Hat doesn't say so.

tried on different machines
I get

$ docker pull ghcr.io/aquasecurity/trivy-db:2
2: Pulling from aquasecurity/trivy-db
2201a50a2e17: Pulling fs layer
unexpected end of JSON input

RustSec/advisory-db has changed their format and it is failing to parse TOML.
rustsec/advisory-db@64c17ac

Note that they have unaffected now.
https://github.com/RustSec/advisory-db/blob/64c17acfe3c7e4c57973d54c69d879abf1763154/crates/arrayfire/RUSTSEC-2018-0011.toml#L24

Currently this happens:

2019/11/13 14:27:12 Updating vulnerability database...
2019/11/13 14:27:12 Updating php-security-advisories data...
2019/11/13 14:27:12 error in php-security-advisories update: failed to update compose vulnerabilities: batch update failed: error in batch update: failed to walk compose advisories: lstat /Users/simar/Library/Caches/trivy-db/php-security-advisories: no such file or directory
➜

The error could be improved as it stands, it's not quite clear what's going on.

2020/10/04 00:37:32 Updating python-safety-db data...
2020/10/04 00:37:32 error in python-safety-db update: failed to update python vulnerabilities: failed to decode JSON: json: cannot unmarshal object into Go value of type []python.RawAdvisory
make: *** [db-build] Error 1
Error: Makefile:77: recipe for target 'db-build' failed
Error: Process completed with exit code 2.

https://github.com/aquasecurity/trivy-db/actions/runs/287205703

The root case is:

• pyupio/safety-db@b412631 changed the format of insecure_full.json .
• rustsec/advisory-db#414 changed the format of advisory-db.

Hi Team,

I have 2 question on the latest trivyDB update.

1. Where does Trivy DB download the database in latest release. Is that /root/.cache/trivy?
2. If we want to override the DB location what are the options available in latest release?

Thanks for help. Appreciate it.

ISSUE

starboard find vulns deployment/some_deployment --namespace default -v 3
I0708 14:43:53.094626    3804 scanner.go:55] Getting Pod template for workload: {Deployment core-scanandpay-failover-v2 default}
I0708 14:43:53.117105    3804 scanner.go:70] Scanning with options: {ScanJobTimeout:0s DeleteScanJob:true}
I0708 14:43:53.118220    3804 runner.go:79] Running task and waiting forever
I0708 14:43:53.118288    3804 runnable_job.go:47] Creating runnable job: starboard/2e7c4482-df93-4057-a5b1-dbc1a18ce353
I0708 14:43:53.137715    3804 reflector.go:207] Starting reflector *v1.Job (30m0s) from pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:156
I0708 14:43:53.138252    3804 reflector.go:243] Listing and watching *v1.Job from pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:156
I0708 14:43:55.586801    3804 runnable_job.go:73] Stopping runnable job on task failure with status: Failed
I0708 14:43:55.587514    3804 runner.go:83] Stopping runner on task completion with error: job failed: BackoffLimitExceeded: Job has reached the specified backoff limit
E0708 14:43:55.723818    3804 manager.go:177] Container 2e7c4482-df93-4057-a5b1-dbc1a18ce353 terminated with Error: 2020-07-08T12:43:54.563Z                                                                       INFO     Need to update DB
2020-07-08T12:43:54.564Z        INFO    Downloading DB...
2020-07-08T12:43:54.730Z        FATAL   failed to download vulnerability DB: failed to download vulnerability DB: failed to list releases: Get https://api.github.com/repos/aquasecurity/trivy-db/releases: x509: certificate signed by unknown authority
error: running scan job: job failed: BackoffLimitExceeded: Job has reached the specified backoff limit

TECHNICAL DETAILS

• K8S version: 1.14.6
• starboard version: 0.2.5
• K8S runs on a VMWare platform on-prem
  • Behind a corporate FW and proxy.
• kubectl version: 1.17.3

EXPECTATIONS

To be able to execute starboard find vulns deployment/some_deployment without this issue

DEBUGGING - TRIED

• Tried using: --insecure-skip-tls-verify the issue remained
• Tried removing the certificate-authority-data sections from the kubeconfig file. The issue remained
  • Tried with and without the --insecure-skip-tls-verify parameter. Same issue

OTHER

I'm posting this issue in this repo as the challenge seems to be related to specifically trivy-db. As that is being called via starboard.

Looking forward to any tips and pointers. Let me know if more info is needed.

Thank you very much.

Oracle sometimes issues multiple ELSAs for a single CVE. One may be for the "normal flavor", and one for the "FIPS flavor".

See for example ELSA-2021-4451 and ELSA-2022-9221

Both these ELSAs address CVE-2021-20231 for gnutls, but note that ELSA-2022-9221 contains fix versions for the FIPS flavor (gnutls-3.6.16-4.0.1.el8_fips), while ELSA-2021-4451 is for the normal flavor (gnutls-3.6.16-4.el8).

It appears that the database only supports one advisory per vulnerability ID. When trivy-db populates the database advisories via PutAdvisoryDetail() (with the CVE ID as the key), this will result in a "last one wins" situation. In this specific case, the normal advisory is processed first, and then the FIPS advisory, meaning the database only contains the advisory for the FIPS version.

I believe I have confirmed this through a simple bbolt traversal of the cached trivy database -

b := tx.Bucket([]byte("Oracle Linux 8")).Bucket([]byte("gnutls"))
b.ForEach(func(k, v []byte) error {
    fmt.Printf("%s - %s\n", string(k), v)
    return nil
})

Gives the output:

CVE-2019-3829 - {"FixedVersion":"3.6.8-8.el8"}
CVE-2019-3836 - {"FixedVersion":"3.6.8-8.el8"}
CVE-2020-11501 - {"FixedVersion":"3.6.8-10.el8_2"}
CVE-2020-13777 - {"FixedVersion":"3.6.8-11.el8_2"}
CVE-2020-24659 - {"FixedVersion":"3.6.14-7.el8_3"}
CVE-2021-20231 - {"FixedVersion":"10:3.6.16-4.0.1.el8_fips"}
CVE-2021-20232 - {"FixedVersion":"10:3.6.16-4.0.1.el8_fips"}
CVE-2021-20305 - {"FixedVersion":"3.6.14-8.el8_3"}
CVE-2021-3580 - {"FixedVersion":"10:3.6.16-4.0.1.el8_fips"}

This may also be a problem with ksplice flavors as well.

The trivy scanner has related issues differentiating between the flavors (see aquasecurity/trivy#1967 most recently), but if the database only contains 1 of the 1-3 advisories, then addressing the flavor parsing in the scanner will still result in false negatives as the other flavors are not present in the database.

Hi, we use trivy extensively for docker image scanning. Our base ubuntu docker images were found to have these CVEs:

https://ubuntu.com/security/CVE-2021-24031
https://ubuntu.com/security/CVE-2021-24032
https://ubuntu.com/security/notices/USN-4760-1

However, after upgrading to version listed as fixed for ubuntu 20.04 (1.4.4+dfsg-3ubuntu0.1) trivy still reports zstd as vulnerable. Can be tested out on the latest ubuntu:20.04 image:

~/zstd-repo{1} $ cat >Dockerfile
FROM ubuntu:20.04

RUN apt-get update && apt-get upgrade -y

~/zstd-repo{0} $ docker build --pull -t zstd-repo .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM ubuntu:20.04
20.04: Pulling from library/ubuntu
Digest: sha256:b4f9e18267eb98998f6130342baacaeb9553f136142d40959a1b46d6401f0f2b
Status: Image is up to date for ubuntu:20.04
 ---> 4dd97cefde62
Step 2/2 : RUN apt-get update && apt-get upgrade -y
 ---> Running in 8ddd82ffef9b
Get:1 http://archive.ubuntu.com/ubuntu focal InRelease [265 kB]
~snip~
Calculating upgrade...
The following packages will be upgraded:
  libzstd1
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 237 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libzstd1 amd64 1.4.4+dfsg-3ubuntu0.1 [237 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 237 kB in 0s (1094 kB/s)
(Reading database ... 4121 files and directories currently installed.)
Preparing to unpack .../libzstd1_1.4.4+dfsg-3ubuntu0.1_amd64.deb ...
Unpacking libzstd1:amd64 (1.4.4+dfsg-3ubuntu0.1) over (1.4.4+dfsg-3) ...
Setting up libzstd1:amd64 (1.4.4+dfsg-3ubuntu0.1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Removing intermediate container 8ddd82ffef9b
 ---> 6e38dda7cccd
Successfully built 6e38dda7cccd
Successfully tagged zstd-repo:latest

~/zstd-repo{1} $ GITHUB_TOKEN= trivy zstd-repo
2021-03-09T18:30:59.079Z	WARN	You should avoid using the :latest tag as it is cached. You need to specify '--clear-cache' option when :latest image is changed
2021-03-09T18:30:59.097Z	INFO	Need to update DB
2021-03-09T18:30:59.097Z	INFO	Downloading DB...
20.40 MiB / 20.40 MiB [----------------------------------------------------------------------------------------------------------------------------------------] 100.00% 1.53 MiB p/s 13s
2021-03-09T18:31:18.130Z	INFO	Detecting Ubuntu vulnerabilities...

zstd-repo (ubuntu 20.04)
========================
Total: 24 (UNKNOWN: 0, LOW: 20, MEDIUM: 4, HIGH: 0, CRITICAL: 0)

+-------------+------------------+----------+------------------------+---------------+--------------------------------+
|   LIBRARY   | VULNERABILITY ID | SEVERITY |   INSTALLED VERSION    | FIXED VERSION |             TITLE              |
+-------------+------------------+----------+------------------------+---------------+--------------------------------+
~snip~
+-------------+------------------+          +------------------------+---------------+--------------------------------+
| libzstd1    | CVE-2021-24031   |          | 1.4.4+dfsg-3ubuntu0.1  |               | zstd: adds read permissions to |
|             |                  |          |                        |               | files while being compressed   |
|             |                  |          |                        |               | or uncompressed                |
+             +------------------+          +                        +---------------+--------------------------------+
|             | CVE-2021-24032   |          |                        |               | zstd: Race condition           |
|             |                  |          |                        |               | allows attacker to access      |
|             |                  |          |                        |               | world-readable destination     |
|             |                  |          |                        |               | file                           |
+-------------+------------------+----------+------------------------+---------------+--------------------------------+

This version should not be marked as vulnerable, and trivy-db has been released a few times since this was updated by Canonical. Has something gone wrong?

Hi, I tested trivy with several distros and checking Ubuntu 18.04 that 'sudo' vulnerability is not detected. Checking the Trivy DB it appears the Debian package that fixes it but not the Ubuntu one yet (https://ubuntu.com/security/CVE-2021-3156). I cleaned the cache to make sure I have the DB up-to-date. Would be possible that the Ubuntu feed is not updated in the Trivy DB?

trivy-offline.db.tgz metadata.json contains Version=1, but that causes the CLI to fail with following error.

2022-03-21T17:22:55.834Z	ERROR	The local DB has an old schema version which is not supported by the current version of Trivy CLI. DB needs to be updated.
2022-03-21T17:22:55.834Z	FATAL	DB error: database error: validate error: --skip-update cannot be specified with the old DB schema. Local DB: 1, Expected: 2

Changing the value fixes the issue.
Furthermore, the db that is automatically downloaded from the cli says Version=2.

PS: A collegue reported other schema errors with v0.23.x and above but I don't have the exact details, could be the same thing.

Currently, we have both flags and command for help.

trivy-db  
NAME:
   trivy-db - Trivy DB builder

USAGE:
   trivy-db [global options] command [command options] image_name

VERSION:
   0.0.1

COMMANDS:
   build    build a database file
   upload   upload database files to GitHub Release
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --help, -h     show help
   --version, -v  print the version

We may want to have one, not both.

Issues downloading offilne db...

$ wget https://github.com/aquasecurity/trivy-db/releases/latest/download/trivy-offline.db.tgz

--2021-09-12 21:57:24-- https://github.com/aquasecurity/trivy-db/releases/latest/download/trivy-offline.db.tgz
Resolving github.com (github.com)... 140.82.114.3
Connecting to github.com (github.com)|140.82.114.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github.com/aquasecurity/trivy-db/releases/download/v1-2021091218/trivy-offline.db.tgz [following]
--2021-09-12 21:57:24-- https://github.com/aquasecurity/trivy-db/releases/download/v1-2021091218/trivy-offline.db.tgz
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://github-releases.githubusercontent.com/216830441/2215ba84-a5cf-4da9-bc67-37d5e96b10d2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210912T215548Z&X-Amz-Expires=300&X-Amz-Signature=684903f16b84cce33c66e0b06325f5638962606893839bec6f01b1ed84798218&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=216830441&response-content-disposition=attachment%3B%20filename%3Dtrivy-offline.db.tgz&response-content-type=application%2Foctet-stream [following]
--2021-09-12 21:57:24-- https://github-releases.githubusercontent.com/216830441/2215ba84-a5cf-4da9-bc67-37d5e96b10d2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210912T215548Z&X-Amz-Expires=300&X-Amz-Signature=684903f16b84cce33c66e0b06325f5638962606893839bec6f01b1ed84798218&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=216830441&response-content-disposition=attachment%3B%20filename%3Dtrivy-offline.db.tgz&response-content-type=application%2Foctet-stream
Resolving github-releases.githubusercontent.com (github-releases.githubusercontent.com)... 2606:50c0:8001::154, 2606:50c0:8000::154, 2606:50c0:8003::154, ...
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|2606:50c0:8001::154|:443... failed: Connection timed out.
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|2606:50c0:8000::154|:443... failed: Connection timed out.
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|2606:50c0:8003::154|:443... failed: Connection timed out.
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|2606:50c0:8002::154|:443... failed: Connection timed out.
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|185.199.108.154|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2021-09-12 22:06:08 ERROR 403: Forbidden.

Interestingly enough:
curl -LJO https://github.com/aquasecurity/trivy-db/releases/latest/download/trivy-offline.db.tgz
Works.

Please, share doc for build offline db.

I'd like to request

• Automated builds of trivy and trivy-light db with Github
• Automated pushes of the db to dockerhub or another registry

This would allow users to start including the container image in trivy.

Description

Trivy DB has Python security advisories from GHSA and OSV. Safety DB is no longer needed.

I got an alert that our trivy vulndb wasn't fresh anymore. Seems like the last release was three days ago, when they'd normally be every 12 hours.

Looking at the github actions history, it looks like they've just started failing:

Run make db-fetch
make: *** No rule to make target 'db-fetch'.  Stop.
Error: Process completed with exit code 2.

It seems the db-fetch Makefile target was changed in @simar7's PR here: https://github.com/aquasecurity/trivy-db/pull/65/files#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52L60

Sounds like we probably want to update the github actions script to use the new make db-fetch-langs and possibly db-fetch-vuln-list-master too??

Debian 11 was just released. :)

Need update vulsrc with mapping code.

The CVE-2021-3177 is listed as Critical in the DB and in the scan with DB-ligth as UNKNOWN.

| libpython3.7-stdlib | CVE-2021-3177 | CRITICAL |

scan with --ligth
| libpython3.7-stdlib | CVE-2021-3177 | UNKNOWN |

Description

This package takes advisories from Rustsec/advisory-db. Trivy DB currently supports OSV. As far as I understand, they should be the same and duplicated now. We no longer need rust-advisory-db.

Note

We have to make sure OSV and rust-advisory-db are actually the same.

I'm using harbor v2.5.1 and download latest trivy-db. I have to use offline version both of them and it show me "The local DB has an old schema version which is not supported by the current version of Trivy CLI. DB needs to be updated.", "--skip-update cannot be specified with the old DB schema."

Offline db worked until harbor v2.4.1, any suggestion?

Thanks.

Currently trivy db being generated inside "db" directory.

func Dir(cacheDir string) string {
	return filepath.Join(cacheDir, "db")
}

Can we create a db at cacheDir level instead of "db"

Should https://hub.docker.com/r/aquasec/trivy-db/ not be the same as https://ghcr.io/aquasecurity/trivy-db? The image on Docker Hub is regularly updated but seems to be empty (32 Byte). Or is this on purpose?

For highly regulated clients there's an interest in the DB image being signed. This could be done on GHCR with cosign.

Hi,

I am using docker.elastic.co/elasticsearch/elasticsearch:7.9.2 as an image and when I run trivy image on it the first returned row is this:

CVE-2015-5186 says "Audit before 2.4.4 in Linux", but the installed version is 2.8.5-4.el7, which is newer than 2.4.4. Is there a wrong detection, or am I missing something?

Being able to consistently (&air-gapped) check against same db can be quite useful. With a separate process to update the db of course.
Current setup rotates old trivy-db releases on github very fast, which could be mitigated by having some other persistence layer for trivy-db than github releases, but would be nice if github releases were kept forever.

this db put on harbor which docment,thank you

Related code:

Because the severity value from NVD sometimes is too high to used as severity of vulnerability ID.

For example, the severity of CVE-2019-18276 at different srouce:

• https://nvd.nist.gov/vuln/detail/CVE-2019-18276: CRITICAL
• https://security-tracker.debian.org/tracker/CVE-2019-18276: LOW
• https://access.redhat.com/security/cve/CVE-2019-18276: LOW

IMO, there are many CVEs (CVE-2005-2541,CVE-2015-5224,...) show that maybe put NVD to end instead of at first is better, or when get severity for an vulnerability ID maybe use data from OS which is same as the OS of docker image which is scanned is better.