Formally include Common Weakness Enumeration (CWE) in the schema

[andrewpollock]

Problem statement:

OSS users using OSV for vulnerability management have no standardized way to categorize vulnerabilities that they are currently or have historically been impacted by.

Researchers have no way taxonomize OSV records and produce interesting research based on OSV-provenanced data.

CWE is the industry standard way of taxonomizing vulnerabilities.

The GitHub Advisory Database, the largest publisher of OSV records by volume, is using database_specific.cwe_ids[] today, e.g. https://github.com/github/advisory-database/blob/0e3918c95bbd48455145dd8755a532e72445e05e/advisories/github-reviewed/2023/12/GHSA-45x7-px36-x8w8/GHSA-45x7-px36-x8w8.json#L578-L582

Related:

• The "CVEs" goal of the CISA Secure By Design Pledge explicitly discusses CWE
• Use Case 3 of METABUG: Potential concrete data quality improvements for 5.2.0 CVEProject/cve-schema#298
• combine-to-osv: Include the CWE(s) from the underlying CVE in the resultant OSV record google/osv.dev#2292
• https://msrc.microsoft.com/blog/2024/04/toward-greater-transparency-adopting-the-cwe-standard-for-microsoft-cves/

[andrewpollock]

@oliverchang WDYT, a straight out CWE field, or something more like severity (category)?

[andrewpollock]

Looking at CVE 5, they have problemTypes

[oliverchang]

So far, OSV has focused on being a minimal and lean schema focused on enabling vulnerability scanners to produce actionable and accurate results (and by extension, for database maintainers to be able to encode the necessary information to enable that).

CWEs primary use case appears to be for historical analysis purposes (e.g. analysing trends on types of vulnerabilities found in the past) and generally don't seem very useful for vulnerability scanners -- are there any other use cases I'm not aware of? Theoretically, someone doing analysis on vulnerabilities in open source can easily join OSV's data with another (such as NVD, CISA vuln enrichment) to collate this data.

OSV's goal is also to provide backwards compatibility with all schema changes, and as such while it's cheap in the moment to add a new field, it's expensive in the sense of never being able to remove it while adding incremental complexity to the schema as a whole. We'd have to balance the benefits of encoding this directly in OSV against that.