Re: RFC: Adopting OSV for Vulnerability Database

From: Steffen Nurpmeso <steffen_at_sdaoden.eu>
Date: Wed, 06 Aug 2025 19:36:51 UTC
Ed Maste wrote in
 <CAAeFWmkbBjMP1Dt70kdvxFVSpGzZW48_y6UiLHosiDQrUigbWA@mail.gmail.com>:
 |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/

This web page is completely broken.  If you look at web page
source code, at line 790 ff., (and it may be your graphical mailer
interprets those tags and entities as HTML even though we are in
a plain text part, you know, more source code, more distress)

        <td colspan="2"><a href="https://github.com/ossf/osv-schema/compare">Send us a PR</a></td>
      </tr>
    &lt;/tbody&gt;
  &lt;/table&gt;

And then it's borked.  I will not send a PR.  Line 2049 is again
funny.

I have no voice nor even an opinion.  Except that i wonder why
that distress if lossless conversion in between the used (XML,
what a decision) and the new (JSON, what a decision; hey, libyaml
now in FreeBSD base, still have those emails around for further
looking, though no cloud never here

 OL  21 Baptiste Daroussin                2025-06-24 09:28    80/   4089 YAML parser in base (cloudinit support)
 ...
 OL  23 Baptiste Daroussin                2025-06-26 09:05  1066/  32803 git: 0f5c86ddb025 - main - libyaml: import libyaml vendor version 0.2.5
 OL  24 Baptiste Daroussin                2025-06-26 09:15   598/  22492 git: 2bc180ef045e - main - lyaml: vendor import lua bindings for libyaml
 OL  25 Baptiste Daroussin                2025-06-26 09:24   796/  24066 git: 40dafa08b2e7 - main - nuageinit: use lyaml to parse yaml files

) is possible.  I mean, more source code, more distress, in
those millions line of interdependent code something is borked.
(And i also mean, hey!, that is Russ Cox!  No parachute, just
borked it is.)

 |[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
 |
 --End of <CAAeFWmkbBjMP1Dt70kdvxFVSpGzZW48_y6UiLHosiDQrUigbWA@mail.gmail\
 .com>

Mostly it is then just a little nit, and the whole picture is
great again.

 |- Seamless Data Conversion: Bidirectional conversion is possible
 |between VuXML and OSV, without loss of metadata.

So i do not know -- if you get heavily improved internal tooling,
i would surely go for it.  If it is only the interface to some
global interchange of vulnerabilities (if this exists, CVEs are
now heavily divided are they) and your internal VuXML is driven
easily and as always, why the hazzle.  Imho.

Having said that, i surely would go plain text and have some awk
parser (or so) that turns this to whatever else is necessary to
sail the tide, and hoping my english gets that right.

Btw i did not understand the SPDX thing.  You tagged all the files
in large rushes in the former years, did you.  It is there??
So in short, for me interested outsider it seems there is missing
quite a lot of context to understand what this is all about, and
since some FreeBSD committers are even older than i am (sympathy!)
i wonder whether they know it, halfway interested read it, or are
simply silent because they are just as helpless as i am.

Greetings and Ciao! from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear,          The black bear,
|blithely holds his own   holds himself at leisure
|beating it, up and down  tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear