On the identification of vulnerabilities

[pombredanne]

We need to have some externally stable identifier for a vulnerability.
By stable I mean that should be there forever and immutable so it can be used reliably to reference a vulnerability.

A CVE may not exist so we have a problem with using CVE everywhere.
When there is no CVE:

1. we could request a CVE id https://cveform.mitre.org/ and that's a manual process that not straightforward and we may not have yet all the data required to get a CVE id
2. we could become our CNA which is yet another level of "ceremony"
3. we could just assign our own ids and bypass 1. and 2. for the sake of speed, practicality and automation

I suggest that we use 3. and have our own prefix (TBD, such as VULCODE-xxxx) and we assign ids to a vulnerability this way:

• a. It has a CVE, then we reuse the CVE-xxxx as its identifier
• b. It does not have a CVE, then we create the VULCODE-xxxx as its identifier
• c. later if that VULCODE-xxx vulnerability gets a CVE, we will replace the id with the CVE-xxx id and move the VULCODE-xxx id as a reference for that vulnerability.

From a usage standpoint, this means that we should be able to search a vulnerability not only based on its identifier (that may change over time) but also based on its references.

Alternatively to c. above we could have a dedicated field to store the previous VULCODE-xxx when this is replaced by an assigned CVE-xxxid.

The model could look like this

• Vulnerability
  • identifier: VULCODE-xxx or CVE-xxx
  • vc_identifier: empty or VULCODE-xxx if identifier is a CVE-xxx

Later we can have processes for 1. and/or 2. but that's completely independent

[sbs2001]

I don't know whether this is same as using hashes but here it goes :

We will use your suggested Vulnerability model. To make this work we will need the identifier to have some field to denote the importer which encountered the CVE-less vulnerability, eg VULCODE-NPM-0001 (TBD) , which tells me this vulnerability was encountered by https://github.com/nexB/vulnerablecode/blob/develop/vulnerabilities/importers/npm.py source .

So every other instance will have different IDs for the same Vulnerability, this poses the problem in referencing the Vulnerability which is what your stability point is about.

The easiest way we can fix this is :

Start a git repo where we put VulnerableCode Central's (TBD) all VULCODE-XXXX entries. The directory structure could look like (again TBD)

VULCODES/NPM/0001.json
VULCODES/PYPI/0001.json

This is same as any other data source we import our data from, eg https://github.com/RustSec/advisory-db/tree/master/crates

Have just another importer in VulnerableCode to import data from our repo. We could put the curations in this repo too.

[sbs2001]

About automating for applying CVEs

https://cve.mitre.org/cve/cna/CVE_Entry_GitHub_Submission_slides-only.pptx

[copernico]

In project KB we have an "alias" field to state that the vulnerability in a statements is also known under another ID, but this is just an idea and not yet fleshed-out in project KB.

[pombredanne]

Repasting from #259 (comment) for reference:

I revisited https://cve.mitre.org/data/refs/index.html and I suggest this instead prefixVULCOID as a prefix which is rather unique and would be short for Vulnerable Code Id.
We could have ids in this form then where the left part is an ISO-like time stamp e.g. VULCOID-YYYY-MM-DD-HH-MM-SS
The id would case insensitive with an uppercase canonical form.
Would this work?

[pombredanne]

so we are going for now with a locally unique id that is based on VULCOID-YYYY-MM-DDHHMMSS which limits the ocal creation of these ids to one per second for now.... but these are meant to be transient ids that should be eventually replaced by a CVE