#3453·grype

Echo OSV feed integration

Author: orizerahCreated May 19, 2026Updated Sep 6, 2026
Labelsenhancement

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-#3252 unmarshaller doesn't read. We merge it into aliases on the vunnel side as a backstop, but #3252 is the proper home.
  • Our records exercise the same unaffected-store path that #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 #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.