Re: RFC: Adopting OSV for Vulnerability Database

I totally agree! +1

This is defined in our goal:
https://freebsdfoundation.org/blog/freebsd-ports-and-packages-security-project/

Also, the change makes strategic sense: puts FreeBSD on the radar of 
modern supply-chain tools.

I think, making the considerations and implementation on FreeBSD 
Phabricator (https://reviews.freebsd.org) is a good start to share 
ideas, backlog and (offcourse) code.


On 06/08/25 10:49, Ed Maste wrote:
> 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
>