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.

[andrewpollock]

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.

Theoretically, yes, but that is only true when an OSV record aliases a CVE record. If there are novel OSV vulnerabilities that do not have equivalent CVE IDs (this is most likely to be the case for records originating from the GitHub Advisory Database) then even that isn't possible as a workaround. And there's no first-class field in the schema for such an analyst to store this derived CWE, either.

Research like https://vulncheck.com/blog/cwe-top-25-2024 can't be performed on OSV-native data.