No objections. This is a good idea. Jonathan Vasquez PGP: 34DA 858C 1447 509E C77A D49F FB85 90B7 C4CA 5279 Sent with ProtonMail Secure Email
-------- Original Message -------- On Wednesday, 08/06/25 at 10:57 Ed Maste <ema...@freebsdfoundation.org> 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
