Page History

...

Automated testing can also identify so many individual vulnerabilities that human-oriented case handling processes cannot scale to treat each one individually. Here's an extreme example of this phenomenon: although the CERT/CC published only a single Vulnerability Note for Android apps that failed to validate SSL certificates, in the end it covered 23,667 vulnerable apps [6] [, 7]. Should each get its own identifier? Yes, and we did assign individual VU# identifiers to each vulnerable app. But this highlights the distinction between the vulnerability and the document that describes it.

As of this writing, work is underway within the Vulnerability Report Data Exchange special interest group (VRDX-SIG) within FIRST [8] on a vulnerability report cross-reference data model that will allow for the expression of relationships between vulnerability reports. The current work in progress can be found at [https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip|, https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip]. In order to make it easier to relate vulnerability reports and records to each other, the VRDX work represents the following concepts: "possibly related," "related," "not equal," "equal," "superset," "subset," and "overlap."

...

Because of the prevalence and popular use of CVE IDs in the vulnerability response space, many people assume that vulnerability identity is synonymous with Common Vulnerabilities and Exposures (CVE) [9\]. However, let's briefly look at some ways in which that assumption is inaccurate:

...

• Selection bias. Not all products receive equal scrutiny. Not all vul reports are included in VDBs.
• Publication bias. Not all results get published. Some vuls are found but never reported to anyone.
• Abstraction bias. This bias is an artifact of the process that VDBs use to assign identifiers to vulnerabilities. (Is it 1 vul or 3?, 23,667 or 1?)
• Measurement bias. This bias encompasses errors in how a vulnerability is analyzed, verified, and catalogued.

...