cve-search
Add missing Vuln DBs from Docker Scout
List there: https://docs.docker.com/scout/deep-dive/advisory-db-sources/
Early releases
- [ ] Debian Security Bug Tracker
- Vuln show up first there, then gets a CVE ID -> See notes below
- [ ] Ubuntu CVE Tracker
- get oval files: https://ubuntu.com/security/oval - OpenSCAP format
Bundles with details and IDs (can be imported as-is)
- [ ] Oracle Linux Security
- Probably need to get the OVAL files: https://linux.oracle.com/security/oval/ - there are yearly dumps (xml)
- Each has an ID and one or more CVE
- [ ] Photon OS Security Advisories
- Need to fetch wiki pages and parse MD files: https://github.com/vmware/photon.wiki.git
- Each has an ID and one or more CVE
Aliases
- [ ] AlmaLinux Security Advisory
- Alias for RHSA, see notes below
- [ ] Amazon Linux Security Center
- List of AlmaLinux/RH advisories, also possibly bundles?
- [ ] Bitnami Vulnerability Database
- Copy of NVD json, only for Bitnami packages, no other details, but an ID
BIT-cassandra-<CVEID>
- Copy of NVD json, only for Bitnami packages, no other details, but an ID
- [ ] Chainguard Security Feed
- list of IDs and update time with no context (?) - related to https://images.chainguard.dev/security/ - Seems to be just another alias for a CVE
- [ ] Golang VulnDB
- CVE5 format, ref to CVE https://github.com/golang/vulndb/tree/master/data/cve/v5
- Looks like another alias to CVE
- [ ] RustSec Advisory Database
- Advisories are there: https://github.com/rustsec/advisory-db/tree/main/crates - it says it's imported in the GitHub Advisory Database (which we already have)
- the content seem to be a subset of what we have in a GHSA
Bundles without details or proper IDs (cannot be imported as-is)
- [ ] Alpine secdb
- No ID, no details, see notes below
- [ ] Wolfi Security Feed
- Very similar to Alpine secdb, bundles?
Unclear
- [ ] GitLab Advisory Database
- This is the repository to load, contains info for some packaging systems (see readme), in YAML
- Duplicate of other databases (at least CVE, Github, OSVDB) - no dedicated ID
- probably not usable as-is
- [ ] Rocky Linux Security Advisory
- The RSS only contains some of the entries https://errata.rockylinux.org/api/v2/advisories:rss
- No Ref to the other sources for a while, and only on the HTML pages of the IDs
- Would need to fetch and parse all the pages manually
- [ ] inTheWild, a community-driven open database of vulnerability exploitation
- a full DB dump seems available, not sure how to get the entries out of it.
Done
- [x] CISA Known Exploited Vulnerability Catalog
- [x] SUSE Security CVRF
- Has CSAF files, but no provider, see below
- [x] RedHat Security Data
- [x] Python Packaging Advisory Database
- [x] CISA Vulnrichment
- [x] GitHub Advisory Database
- [x] National Vulnerability Database
- [X] Exploit Prediction Scoring System (EPSS)
AlmaLinux Security Advisory
This DB looks like a straight clone of the RedHat database: https://errata.almalinux.org/9/ALSA-2025-2679.html
Bottom of the page says it's auto generated and and reference to the vuln is ALSA-2025:2679 when the one from RH is RHSA-2025:2679.
Se we could just add an alias to ALSA-<YYYY>:<ID> for each RHSA vuln, but I'm not sure it's that useful (?).
Alpine secdb
This DB is more a set of bundles:
packages:
- pkg:
name: aom
secfixes:
3.1.1-r0:
- CVE-2021-30473
- CVE-2021-30474
- CVE-2021-30475
3.9.1-r0:
- CVE-2024-5171
Should we import that as bundles? Instead of a normal source (also they don't have unique IDs, so that's not really doable as a source)
Debian Security Bug Tracker
Source to import: https://salsa.debian.org/security-tracker-team/security-tracker/tree/master/data - DLA ans DSA are the ones we want, probably to make bundles?
The most recent ones have Debian IDs without the CVE ID, and are updated later.
SUSE Security CVRF
New: https://www.suse.com/support/security/csaf/
Doesn't seem to be having a real metadata file and act as a proper provider.
I also think that it is not necessary to import this as classical sources.
Concering AlmaLinux I think we do not need to add an alias "ALSA-<YYYY>:<ID>". What would be the added value of having this alias for all RHSA advisories. Maybe as bundle why not, I must think more about that. It's seems various things.
For ALSA-, the only use-case I see is if someone search with that ID instead of the RH one. Definitely not a high priority.
regarding Ubuntu, not only the OVAL files are available but if you would like to work with JSON instead we also have OSV and OpenVEX data. You can find both in https://github.com/canonical/ubuntu-security-notices
If there's any interests on getting those into the database, let me know, we can work together.
@dodys thank you for reaching out!
I'm 99% sure it makes sense to import the USN, because (if I get it right):
- they will be in the repo before they have a CVE assigned
- they contain extra information comparing to the CVE entry
@dodys thank you for reaching out!
I'm 99% sure it makes sense to import the USN, because (if I get it right):
When you say import USN, do you mean what exactly?
Because the USN data there (under usn/) is just what we use to push into the website: ubuntu.com/security/notices/
It is not a rich data in terms of information. That's where having USNs in OSV or OpenVEX format enters.
So I would recommend using one of the two instead of the "pure" USN JSON, Also because it is not a standardized format and we can change at any point.
1. they will be in the repo before they have a CVE assigned
USNs are just advisories for things we fixed. For that we either need a CVE ID or a launchpad bug ticket. Therefore it might be that one of those bug reports still don't have a CVE assigned, but this is rather an exception usually.
2. they contain extra information comparing to the CVE entry
Depends on what you would want to achieve, if you only care about things that were fixed, then that's when USNs enter. If you would like to know what you are vulnerable to, then that's the CVE data.
Does that help clarify it a bit?
vulnerability-lookup already loads the CVEs entries from CVEListv5, so the main reason to add a feed is if it brings vendor-specific information that aren't in the CVE entry from NVD, or if they relate to a group of CVEs, creating some sort of a bundle (typically when a vulnerability requires multiple software to be exploited).
The other reason (more rare) is if they release a vulnerability that doesn't have a CVE associated (yet, or ever), but that's not your case.
What do you think is the most useful datasource to import?
Just as an example, this is how a Red Hat Security Advisory with multiple CVEs will be rendered: https://vulnerability.circl.lu/vuln/rhsa-2025:3501
vulnerability-lookup already loads the CVEs entries from CVEListv5, so the main reason to add a feed is if it brings vendor-specific information that aren't in the CVE entry from NVD, or if they relate to a group of CVEs, creating some sort of a bundle (typically when a vulnerability requires multiple software to be exploited).
That's exactly what the Ubuntu CVEs are. The downstream/vendor-specific information that are not present in any form in Mitre's database. See for example: https://ubuntu.com/security/CVE-2024-34156
The other reason (more rare) is if they release a vulnerability that doesn't have a CVE associated (yet, or ever), but that's not your case.
What do you think is the most useful datasource to import?
Probably OSV, for both USN and CVE, if you already plan to use the same format for other ecosystems.
Just as an example, this is how a Red Hat Security Advisory with multiple CVEs will be rendered: https://vulnerability.circl.lu/vuln/rhsa-2025:3501
RHSAs are similar to USNs or DSAs (from Debian), they only will give you what was fixed in a ecosystem, it won't tell you the full picture of what is still unfixed. That's why downstream vendors have always two different sets of data:
- An advisory to announce the fixed things
- A downstream specific information about a CVE
For example redhat publishes their CVE data here: https://security.access.redhat.com/data/csaf/v2/vex/2025/
Moodle vulnerability feed is in RSS with their own ID (without CVE reference)
- https://moodle.org/rss/file.php/154821/7b2ff11e6e02355092ed94ccb5227412/mod_forum/996/rss.xml
How should we import it? Should allocate a GNA via GCVE for Moodle and do the mapping from the RSS?
They have IDs, so I'd say we use that (MSA-YY-<ID>): https://moodle.org/security/
Some notes regarding RedHat VEX
- https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-0014.json
- I was expecting to see those like cve-2025-0014 in our RedHat CSAF source but it's not the case
- I suppose the VEX source is vulnerabilities which can be on RedHat system but not packaged by RedHat or release by them but could affect their software. CVE-2025-0014 includes stuff like
"product_status": { "known_not_affected": [ "red_hat_products" ]
So importing the VEX seems interesting but now the question, are all the vendors using VEX in that way?
https://cyclonedx.org/capabilities/vex/
So we might need to find a way to store and query VEX in vulnerability-lookup.
I added a specific VEX issue #161 to not pollute this issue which is more about sources.