RFC: Adopting OSV for Vulnerability Database

Hello everyone,

The Foundation has been evaluating the benefits of migrating FreeBSD
vulnerability data from our bespoke VuXML format to an
industry-recognized format. Such a migration would involve some new
workflows, tools, processes, and documentation, so I'm sharing this
proposal for comments.

Adopting an industry-recognized format offers significant benefits as
it simplifies how external parties can consume and utilize FreeBSD
vulnerability data, and allows us to manage data with a broader range
of existing upstream tools, reducing the need for custom development.

Providing vulnerability data in a standard format increases the
security of the FreeBSD ecosystem by facilitating seamless consumption
by a wider array of security tools and services, which will accelerate
the detection and mitigation of threats for all users of FreeBSD and
its derivatives.

Proposed Standard: OSV (Open Source Vulnerability)[1]

After evaluating available vulnerability standards, we recommend
adopting OSV for the following reasons:
- Broad Industry Support: OSV is supported by organizations of all
sizes, including AlmaLinux, Android, Debian, GIT, Go, PyPI, and Red
Hat.
- Existing OSV Databases: Several organizations already generate
OSV-compatible vulnerability databases.
- Independent Adoption: Organizations don't need to be under the Open
Source Vulnerability Database (OSV) umbrella, though there may be
future benefits to joining.
- Seamless Data Conversion: Bidirectional conversion is possible
between VuXML and OSV, without loss of metadata.

Implementation Considerations

Proof of Concept

A proof-of-concept implementation is underway, showcasing various
ID-tag examples and potential database arrangements. Ideas for
database structure are drawn from projects like the PYPI (Python
Package Index) vulnerability database and the openSUSE OSV index.

Repository [2]: You can explore the implementation and different ideas
in the README.md of this repository:
https://github.com/illuusio/vuln-test. This is intended to spark
discussion.

Alternative Standards Considered

We considered other standards but did not pursue them due to their
limitations in meeting our expected needs:

- CSAF (Common Security Advisory Framework): While backed by OASIS and
entities like CISA and Red Hat, CSAF is more complex to implement
(e.g., file signing requirements) and has less mature tooling. While
OSV and CSAF aren't mutually exclusive, implementing an OSV database
first is significantly easier.
- OpenVEX (simplified Vulnerability Exploitability eXchange
implementation): Different purpose - used to indicate that a
vulnerability does not apply in a certain configuration (for example,
a feature that is not enabled at compile time).

Next Steps

We've opened a pull request adding an OSV parser to FreeBSD pkg [3].
We would appreciate your feedback and questions on the following:
- The choice of OSV as the standard for FreeBSD vulnerability data.
- The current proof-of-concept implementation approach.
- Any concerns or suggestions for the proposed migration.

Your input will help us refine the implementation before submitting
the necessary changes to the FreeBSD tree.

Thanks in advance for your time and consideration.

Ed Maste

[1] OSV Schema: https://ossf.github.io/osv-schema/
[2] OSV FreeBSD POC repo https://github.com/illuusio/vuln-test
[3] pkg(8) Parser PR: There's an existing pkg(8) parser pull request:
https://github.com/freebsd/pkg/pull/2453