Repository navigation
Echo OSV feed integration #3453
Description
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
upstreamfield, which the pre-feat: enhanced OSV transformer #3252
unmarshaller doesn't read. We merge it intoaliaseson 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.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
kzantow commentedon Jun 22, 2026
We merged an update to include all current OSV models. We have added testing functionality to grype that takes vunnel output records, builds a database, and exercises the matcher with a real database. You can see some examples in the hummingbird tests with some sample data.
The best thing to do is probably run your provider locally to get some sample records to include as tests in the appropriate matcher(s) that we can add and verify they have the expected match result.
feat(db): add echo-osv OSV transformer strategy
orizerah commentedon Jul 2, 2026
Thanks @kzantow,
Turned out our ECHO-* records had no strategy in the OSV transformer, so they were dropped at build time. #3526 wires that up: an echoStrategy for our language advisories (Echo:PyPi / npm / Maven) as NAK/unaffected records, gated by a small Echo qualifier that only fires on +echo.N versions so it can't leak onto plain upstream ones. Reads from anchore/vunnel#1174.
Mostly I'd love your read on whether we're missing anything and what the PR still needs to merge. If there's a checklist for adding a provider strategy, point me at it.
LaizaAngrest commentedon Sep 6, 2026
Hi @kzantow
Wanted to ask where things stand now, and whether a review is something you could fit in soon.
If anything on our end is holding it up, just let me know and I'll sort it out.
Thanks!
kzantow commentedon Oct 13, 2026
Hi, I'm working on adding a new feature that I believe will support Echo and other similar scenarios in a data-driven way where we can identify when a package should include additional vulnerability data based on some package-level characteristics. In your case, I believe this includes some version revision including
echoin packages that you've patched -- is my understanding correct? I've added an example to that PR that would show generally how an echo package can be identified using the data-driven SearchRules. Any feedback on this approach would be great, especially if I've missed some nuance!LaizaAngrest commentedon Oct 16, 2026
Hi @kzantow, yes sounds good. One important detail: Echo packages should only match versions ending exactly with +echo.N, where N is numeric—for example, 1.2.3+echo.1. A broad check for versions containing echo could match unrelated packages.
The package name stays the same as upstream. We need this for PyPI, npm, Maven, NuGet and Go.
We’ll wait for #3751 and then rework #3526 to use it. Please let us know when #3751 is ready, or if you’d prefer a different approach.
Thanks!
LaizaAngrest commentedon Oct 21, 2026
@kzantow small clarification to my previous comment: +echo.N should be an exact version segment, but it may be followed by additional metadata.
For example, both 1.2.3+echo.1 and 1.2.3+echo.1.frntr.1 should match.
We’ll include this behavior when reworking #3526 to use SearchRules.