Add support for purl

[stevespringett]

OSV supports Package URL, however, the OSV feeds in this repo do not appear to have purls. This request is to enhance all OSV files to include purl.

[greysteil]

Definitely supportive of PURL, but this repo is a data source, and one that we want contributors to be able to edit directly. (We have some formatting improvements to make that easy, but that's the direction).

I'd be nervous about the duplication that adding PURLs here would create. The obvious concern is that the PURL could get out of sync and other (mandatory) package information. We could fix that with linting etc., but any duplication could make contributing harder. I imagine that's part of the reason the OSV spec calls out the schema is only designed for serving data, not storing it:

Again, this document is only about the JSON encoding the database serves to consumers, which could be applications or other databases. A database might store its entries in an entirely different format, or it might store them using this schema but in a more human-editable encoding, such as TOML or YAML.

I wonder if ☝️ speaks to a larger issue about the extent we are serialising the data in this repo for consumption vs. making it easy to edit it. We don't currently have a REST API for the data in this database (it's only available via GraphQL), but we plan to add one relatively soon. When we do it would allow us to separate the consumption concern from the contributing one a much more cleanly. This conversation would be trivial there - there would be no downside to us serialising PURLs in the API for anyone who wanted them.

[KateCatlin]

For everyone who 👍'd @stevespringett's comment, thank you for chiming in and upvoting!

Would love to hear more about the use case here. Is there something specific you would do differently if PURLs were part of this spec? What would you use them for? Would love to hear more about your specific "user story."

[stevespringett]

Hi @KateCatlin. The two primary use cases are 1) inventory management, and 2) vulnerability management.

Inventory Management

Many systems use purl (with and without qualifiers) as a primary key for managing open source components across the enterprise. Some SCA products do this, systems my employer (ServiceNow) has built do this, and multiple sources of vulnerability intelligence do this.

Vulnerability Management

As stated above, many sources of vulnerability intelligence use purl as the primary field for component identity. Examples include Sonatype OSS Index and Snyk. By supporting purl, GitHub Advisories will be better positioned to be used as a source of vulnerability intelligence in external systems.

Also note, the SBOM Forum has published and distributed a paper on the "naming problem" and has formally recommended purl as one of its solutions. As a result of that paper, I've had multiple conversations with researchers at MITRE who will be publishing a paper (possibly distributed by CISA) which discuss the issues with CPE and provide some possible solutions, purl being one of them.

Currently OSV has support for ecosystem. I believe this to be a serious design flaw in OSV as the ecosystem doesn't have any formal registration process and is specific to OSV. Use of the value of ecosystem has no meaning outside of OSV which limits its utility. See https://ossf.github.io/osv-schema/#affectedpackage-field

By adopting purl (also supported by OSV), GitHub Advisories will be using formally registered purl types which not only provide additional ecosystem support, but have defined meaning and acceptance across a wide array of specifications including Vulnerability Disclosure Reports, Software Bill of Materials, and inventory and vulnerability management systems.