import cve's automatically with a queue where CVe's can be reviewed

[jelly]

It would be nice to import CVE's automatically using an API maybe such as https://cve.circl.lu/api/ or https://nvd.nist.gov/vuln/data-feeds and add a review / queue to the security tracker to review these issues.

An idea is to create a new view /todo/cve and show a list of CVE's who don't have at least two signoffs and show the following information:

CVE-XXX-XX-XX (a link) product and version, description and links. If the product can be found in our Package model show the package and version or do a fuzzy match on our Packages and show a list? There should be a button to create an AVG with this CVE pre-filled in.

The CVE signoffs should be a table cve_signoff that stores the CVE id, team member, signoff time

Open questions:

• How do we map the CVE type from the CVE feed to our CVE type?
• We lack the package name and package version in the CVE model which we could extract from the CVE feed?

[jelly]

@ysf can you take a look at this?

[ysf]

It would be great to have a sanitized dump to get a feel of how the data has to look later on and generally work with the tracker.

[shibumi]

Hi @ysf, sad that we didn't met on 36C3 :)
You can find dumps of our data via putting .json in your URL bar.
For example for a CVE:
https://security.archlinux.org/CVE-2019-6474.json

{
  "name": "CVE-2019-6474",
  "type": "denial of service",
  "severity": "High",
  "vector": "Remote",
  "description": "An issue has been found in the Kea DHCPv6 server before 1.6.0 or 1.5.0-P1, where a missing check on incoming client requests can be exploited to cause a situation where the Kea server's lease storage contains leases which are rejected as invalid when the server tries to load leases from storage on restart. If the number of such leases exceeds a hard-coded limit in the Kea code, a server trying to restart will conclude that there is a problem with its lease store and give up.",
  "groups": [
    "AVG-1032"
  ],
  "packages": [
    "kea"
  ],
  "advisories": [],
  "references": [
    "https://kb.isc.org/docs/cve-2019-6474"
  ],
  "notes": "CVE-2019-6474 can only affect servers which are using memfile for lease storage"
}

For an AVG:
https://security.archlinux.org/AVG-1032.json

{
  "name": "AVG-1032",
  "packages": [
    "kea"
  ],
  "status": "Vulnerable",
  "severity": "High",
  "type": "denial of service",
  "affected": "1.5.0-10",
  "fixed": null,
  "ticket": null,
  "issues": [
    "CVE-2019-6474",
    "CVE-2019-6473",
    "CVE-2019-6472"
  ],
  "advisories": [],
  "references": [
    "https://marc.info/?l=oss-security&m=156706528412669"
  ],
  "notes": null
}

and so on. Hope this helps.

[ysf]

Yeah, but I don't want to scrape those and add them under an anonymous user into my local database if those could be easily sanitized to get a realistic working environment. Actually it's a time issue, if it's quicker to scrape and import than to sanitize and share I'll gladly do it.

[Foxboron]

I think there should be two views on the tracker for this data.

• One view that parses the recent/modified list and contains the following data
  • CVE
  • pkgname
  • version
  • severity

Obviously the entries needs to be as few false positives as possible. We should also enable easy creation of an AVG group and do some basic matching on pkgname and version to find existing AVGs.

• One view to search CVEs which are reserved, and not public, so we can have a todolist when details are filled from the recently modified list