google
new datasource: Alpaquita Linux
Our security team has prepared Alpaquita Linux security data in OSV-schema format. The CLA is submitted. Please help with the futher process. Thanks.
We also have a few questions. According to the docs there are three ways to push data: 1. a public Git repository; 2. a public GCS bucket; 3. to REST API endpoints.
- Our probably most preferable way is (1) a public Git repository. Is there an example repo for that? I found https://github.com/google/oss-fuzz-vulns/ but really not sure it is that.
- We'd want our data to be checked for quality beforehand. Where/who should we ask about it?
/label datasource
Hi @i-bs, how exciting! Thanks for considering contributing to OSV.dev!
Credit to @andrewpollock for this: OSV.dev's onboarding process in a nutshell (actionable feedback welcome):
-
[ ] Decide if you're going to publish records via a Git repository, GCS bucket or REST endpoint, which you have - off the top of my head, an example of a public Git repository is AlmaLinux: https://github.com/AlmaLinux/osv-database.
-
[ ] Create a PR to reserve a prefix in the OSV-Schema (worked examples: https://github.com/ossf/osv-schema/pull/235 https://github.com/ossf/osv-schema/pull/223 https://github.com/ossf/osv-schema/pull/219)
- [ ] We review the records you start publishing for OSV Schema correctness and quality (the work happening under the OSV Data Quality Program is also relevant here, as an FYI) as part of reviewing and merging that PR
-
[ ] Create a PR to extend purl_helpers.py (if appropriate)
-
[ ] Create a PR to start importing the records you are publishing into our test instance of OSV.dev and validate everything is working as intended there (worked example: https://github.com/google/osv.dev/pull/2086)
-
[ ] Create a PR to start importing the records you are publishing into our production environment (worked example: https://github.com/google/osv.dev/pull/2105)
Known onboarding rough edges:
- the format of the source{,_test}.yaml files (hopefully the example PRs plus other existing entries will make this reasonably self-evident). Specifically, FYI, the value for type corresponds with those defined at https://github.com/google/osv.dev/blob/381f459de12e181447731beee9ba4b06a513c586/osv/models.py#L783-L787
We're working on better aggregating all this information into our docs to make it easier in the future, and would love to receive feedback on what information we might have missed, or any pain points we could make clearer.
We're here to help
If you have any questions, please feel free to reach out.
Greetings, ppl, @jess-lowe ,
thank you and Andrew for the detailed plan above. We have prepared the git repo with data and two PRs according the plan. Could you please take a look at them and maybe start the quality checks? Thanks
Greetings, @jess-lowe , both of my PRs are stuck. Could you please advice how to move them further? Thanks
Sorry for the late response, many folks on our team are travelling at this time. I added some comments to both both PRs.
Greetings! One PR is merged (thank you, team!). Another is kinda hung (https://github.com/ossf/osv-schema/pull/347). All checks seem to pass. Any advise? Thank you.
thank you @team for merging the PRs. Yet data isn't as it should be.
E.g. https://test.osv.dev/vulnerability/BELL-CVE-2025-6965 (and all BELL- entries) has no "affected.package"-s.
Could you please take a look why this happens? The input data seems correct per scheme.
It's in now :D! https://test.osv.dev/list?q=&ecosystem=Alpaquita
There was an issue with it not being in _ecosystems.py, but it's fixed now in #3705 .