- golang - gemnasium, trivy, grype, oss-index (have only seen results from trivy / oss-index)
- npm - gemnasium, trivy, grype, oss-index (confirmed results from all 4)
- maven - gemnasium, trivy, grype, oss-index (confirmed results from all 4)
- pypi - gemnasium, trivy, grype, oss-index (confirmed results from all 4)
- nuget - gemnasium, trivy, oss-index, grype ( no testing)
- gem - gemnasium, trivy, grype, oss-index (tested but got no results using a small bom)
- rpm - grype,trivy, oss-index (oss-index coverage seems quite poor)(see operating system distros for important information)
- deb - grype, trivy (see operating system distros for important information)
As a note the official gemnasium database has terms of service that say it can't be used in 3rd party tools without explicit permission.
The community datasource is essentially the same it is just 30 days delayed.
Tracking external sources One of the main challenges of maintaining a vulnerability database is to learn about security advisories recently published. To that goal, the GitLab team checks external sources on a regular basis. If an external source lists an advisory that is not already in gemnasium-db, they research and check the advisory, add metadata to it, and publish it to this repo following the contribution guidelines.
Tracking process and schedule Below is the list of data-sources we check for updates on a daily basis:
NVD JSON feeds
GitHub security advisory database by means of the Trivy Advisory Database
Ruby Advisory DB
Below is a list of data-sources from which we sourced data in the past. Those data-sources are checked occasionally:
FriendsOfPHP security advisories Victims CVE DB oss-security mailing list
While the advisory tracking for NVD and ruby-advisory-db is semi-automated, we check the oss-security mailing list manually. For the manual source tracking, we use the following strategy:
Look for vulnerability announcement that do not have a CVE with an announcement day not older than 4 weeks Generate an identifier (as explained in our contribution guidelines) Create an MR (according to our contribution guidelines)
It's preferred to create merge requests right away but the team member in charge of checking the source may not be immediately available to do that, and creating issues is a way to delay the task or to pass it on to another team member.
- Alpine Linux SecDB: https://secdb.alpinelinux.org/
- Amazon Linux ALAS: https://alas.aws.amazon.com/AL2/alas.rss
- RedHat RHSAs: https://www.redhat.com/security/data/oval/
- Debian Linux CVE Tracker: https://security-tracker.debian.org/tracker/data/json
- Github GHSAs: https://github.com/advisories
- National Vulnerability Database (NVD): https://nvd.nist.gov/vuln/data-feeds
- Oracle Linux OVAL: https://linux.oracle.com/security/oval/
- RedHat Linux Security Data: https://access.redhat.com/hydra/rest/securitydata/
- Suse Linux OVAL: https://ftp.suse.com/pub/projects/security/oval/
- Ubuntu Linux Security: https://people.canonical.com/~ubuntu-security/
Note the OS datasources do not seem to work with SBOM integration we should open an issue with trivy to address
| OS | Source |
|---|---|
| Arch Linux | Vulnerable Issues |
| Alpine Linux | secdb |
| Amazon Linux | Amazon Linux Security Center |
| Debian | Security Bug Tracker |
| OVAL | |
| Ubuntu | Ubuntu CVE Tracker |
| RHEL/CentOS | OVAL |
| Security Data | |
| AlmaLinux | AlmaLinux Product Errata |
| Rocky Linux | Rocky Linux UpdateInfo |
| Oracle Linux | OVAL |
| CBL-Mariner | OVAL |
| OpenSUSE/SLES | CVRF |
| Photon OS | Photon Security Advisory |
| Language | Source | Commercial Use | Delay1 |
|---|---|---|---|
| PHP | PHP Security Advisories Database | ✅ | - |
| GitHub Advisory Database (Composer) | ✅ | - | |
| Python | GitHub Advisory Database (pip) | ✅ | - |
| Open Source Vulnerabilities (PyPI) | ✅ | - | |
| Ruby | Ruby Advisory Database | ✅ | - |
| GitHub Advisory Database (RubyGems) | ✅ | - | |
| Node.js | Ecosystem Security Working Group | ✅ | - |
| GitHub Advisory Database (npm) | ✅ | - | |
| Java | GitLab Advisories Community | ✅ | 1 month |
| GitHub Advisory Database (Maven) | ✅ | - | |
| Go | GitLab Advisories Community | ✅ | 1 month |
| The Go Vulnerability Database | ✅ | - | |
| Rust | Open Source Vulnerabilities (crates.io) | ✅ | - |
| .NET | GitHub Advisory Database (NuGet) | ✅ | - |
| Name | Source |
|---|---|
| National Vulnerability Database | NVD |
Trivy only consumes security advisories from the sources listed in the following tables.
As for packages installed from OS package managers (dpkg, yum, apk, etc.), Trivy uses the advisory database from the appropriate OS vendor.
For example: for a python package installed from yum (Amazon linux), Trivy will only get advisories from [ALAS][amazon2]. But for a python package installed from another source (e.g. pip), Trivy will get advisories from the GitLab and GitHub databases.
This advisory selection is essential to avoid getting false positives because OS vendors usually backport upstream fixes, and the fixed version can be different from the upstream fixed version. The severity is from the selected data source. If the data source does not provide severity, it falls back to NVD, and if NVD does not have severity, it will be UNKNOWN.
Footnotes
-
Intentional delay between vulnerability disclosure and registration in the DB ↩