add chainguard osv feed

[crosleyzack]

What

Adds the ability for the chainguard provider to consume the Chainguard OSV feed in addition to the chainguard secdb feed

Why

We are trying to migrate to OSV due to the additional context and fidelity it provides. The SecDB feed is slated to be deprecated end of this year (2026)

Notes

The quality tests passed, which is to be expected as no behavior should have changed.

✦2 ❯ make validate provider=chainguard
uv run yardstick validate --result-set pr_vs_latest_via_sbom_chainguard
Loading label entries...done! 23 entries loaded
Validating with 'pr_vs_latest_via_sbom_chainguard'
2026-05-27 16:47:07,206 [INFO] only considering matches from allowed namespaces: chainguard:distro:chainguard:rolling
2026-05-27 16:47:07,206 [INFO] Testing image: 'ghcr.io/chainguard-images/scanner-test@sha256:59bddc101fba0c45d5c093575c6bc5bfee7f0e46ff127e6bb4e5acaaafb525f9' with 'syft@latest, grype@main+import-db=build/vulnerability.db, grype@main+import-db=https://grype.anchore.io/databases/v6/vulnerability-db_v6.1.4_2026-05-13T00:47:21Z_1778657102.tar.zst'
   Results used for image ghcr.io/chainguard-images/scanner-test@sha256:59bddc101fba0c45d5c093575c6bc5bfee7f0e46ff127e6bb4e5acaaafb525f9:
    ├── c9988b12-2a36-4fb4-9490-db690002220d : grype[custom-db]@v0.99.1-14-g8a04a093 (custom-db)  against ghcr.io/chainguard-images/scanner-test@sha256:59bddc101fba0c45d5c093575c6bc5bfee7f0e46ff127e6bb4e5acaaafb525f9
    └── ddec88a3-940d-47ec-b954-8541a59680e3 : grype[reference]@v0.99.1-14-g8a04a093 (reference)  against ghcr.io/chainguard-images/scanner-test@sha256:59bddc101fba0c45d5c093575c6bc5bfee7f0e46ff127e6bb4e5acaaafb525f9
--------------------------------------------------------------------------------

Quality gate passed!

Succesfully ran VUNNEL_PROVIDERS_CHAINGUARD_USE_OSV=true VUNNEL_ROOT=data_osv uv run vunnel run chainguard and GRYPE_DB_PROVIDER_ROOT=../vunnel/data_osv GRYPE_DB_BUILD_DIR=./db_osv/6 go run ./cmd/grype-db build --schema 6 to create grype-db

Part of Chainguard issue INT-520

[crosleyzack]

Is it a problem if this always reports OSSchema? I ensured the argument to writer.write below is the actual, correct schema

[crosleyzack]

This appears to be a dupe of a PR by Ville updating the vunnel provider. Humbly, I think creating a new parser is much cleaner as an approach though

[crosleyzack]

VUNNEL_PROVIDERS_CHAINGUARD_USE_OSV=true VUNNEL_ROOT=data_osv uv run vunnel run chainguard successfully creates vunnel output
GRYPE_DB_PROVIDER_ROOT=../vunnel/data_osv GRYPE_DB_BUILD_DIR=./db_osv/6 go run ./cmd/grype-db build --schema 6 successfully creates grype-db

[oss-housekeeper]

Warning

Changes github configuration or dependencies — this requires manual review from @anchore/tools

No action from the PR author is needed.

Guarded files touched in this PR:

• .github/scripts/dev-shell.sh (sha: ffc651d4e069a6d2ba96f750e0f31c87b2da595a)

This review disposition can be dismissed after manual review.

[willmurphyscode]

Why does this have a different name for Wolfi than for Chainguard?

[crosleyzack]

Because the Wolfi information is in the same OSV feed as the chainguard info, so to have wolfi use the chainguard information it would be use_osv == true in Chainguard and disabling wofli. This is part of our larger move to no longer have multiple namespaces for our OS

[willmurphyscode]

What should the distro field be? I think some images have wolfi in /etc/os-release and some have chainguard. Is that going to stop happening?

[willmurphyscode]

My understanding is this: at some point, Wolfi will stop being it's own namespace (all the data will be in the chainguard feed), and this gives us a config-only switch to turn off the wolfi feed when that happens. makes sense and looks good.

[crosleyzack]

We still have both. If you look at https://packages.cgr.dev/chainguard/v3/osv/CGA-27xx-xp52-rjpm.json as an example, we have two affected entries: one for Chainguard and one for Wolfi

Dismissing review because replacing pip with uv pip in dev shell seems like a correct change.