Hi! Hoping to coordinate on a new vunnel provider that introduces Echo OSV advisories.

Our PR: anchore/vunnel#1174 — echo-osv, which ingests Echo's OSV feed (https://advisory.echohq.com/osv/all.zip) for the Echo:PyPi and Echo:npm language ecosystems. Echo ships patched builds of upstream PyPI/npm packages (e.g. pip at 25.2+echo.1 for CVE-2026-1703), so we mark records as advisories so grype routes them through the unaffected store — that way the patched build clears the upstream CVE instead of false-positiving on every Echo image.

We're in the same boat as the OSV PRs already listed in #3252 (CRAN #1043, BellSoft #924, openEuler #839):

• Echo's feed uses OSV 1.7's upstream field, which the pre-feat: enhanced OSV transformer #3252
  unmarshaller doesn't read. We merge it into aliases on the vunnel side
  as a backstop, but feat: enhanced OSV transformer #3252 is the proper home.
• Our records exercise the same unaffected-store path that feat: enhanced OSV transformer #3252 fixes
  (nil-CPE qualifier, ECOSYSTEM-range constraint normalization).
• Our quality gate runs through grype-db/grype, so we'll have the same
  green-against-branch / red-on-main shape until feat: enhanced OSV transformer #3252 merges.

A question:

Anything specific our records should include for #3252 to handle Echo:PyPi / Echo:npm cleanly via the unaffected store? Records carry PURLs (pkg:pypi/..., pkg:npm/...) so PURL-based detection should work, but want to confirm.