Question: procedure for moving from package-wise to CVE-wise advisories

[cleanstart-community-admin]

Hi

We currently publish advisories grouped by package release: one advisory per package version, listing all the CVEs fixed in that release. We're considering restructuring this so each advisory is grouped by CVE instead (one advisory per CVE, with an affected entry for each package it touches).

Before we make this change, we wanted to check with you on two things:

1. Procedure: Is there a defined process for changing how we structure/group our advisories, or would this require any changes on OSV's end to support? If a compatible structure or set of conventions already exists for CVE-grouped advisories, we'd appreciate a pointer to it.

2. Handling existing records: Since this change restructures how we group vulnerabilities rather than deleting or altering existing advisory content, how should we handle the transition on OSV.dev's side? Specifically, how does OSV.dev expect us to manage the relationship between old package-wise advisory IDs and new CVE-wise ones (e.g. via related, withdrawn, or another mechanism), so that deduplication and matching continue to work correctly?

Any guidance here would be really helpful before we start migrating.

Thanks!

--------- Related Labels ------------

• enhancement
• data quality

[cleanstart-community-admin]

Any guidance here would be really helpful. Looking forward to a response.

Regards

[another-rex]

1. There's not really a set process for this, it's up to each data provider. We generally advise not loading each advisory with too many fixes, 2 good examples of CVE grouped advisories are probably:
   1. Ubuntu-CVE like, where each entry is 1:1 matched to CVEs, e.g. https://osv.dev/vulnerability/UBUNTU-CVE-2026-46387
   2. Bitnami-like records, where every entry is still it's own advisory ID, but still mostly map to a single CVE (Using the upstream field to denote the linked CVE) https://osv.dev/list?ecosystem=Bitnami
2. The cleanest way is to just delete all the old records and for us to trigger a reimport to make all your records follow the same format. This will make all previous records be marked as withdrawn. This is what Chainguard did recently.

Ideally, you would do this manually, by publishing the records with withdrawn field fill in, and the description updated to explain why, and linking to the new records (related is an appropriate field for this). However, this (manual withdrawn and reasoning) is not 100% necessary, as the main use case for OSV is for scanning, and if the records are updated the new results the users get will still be relevant, and the exact record IDs are irrelevant.