Download echo OSV advisories to vuln-list by orizerah · Pull Request #436 · aquasecurity/vuln-list-update

orizerah · 2026-04-13T13:07:41Z

Add support for downloading Echo's OSV advisory

DmitriyLewen · 2026-04-14T08:17:40Z

Can you use real advisories (names, fixed version, etc) in test?

DmitriyLewen · 2026-04-14T09:08:05Z

+  "affected": [
+    {
+      "package": {
+        "ecosystem": "Echo",


What about ecosystem for language packages?

I found ECHO-7db2-03aa-5591 with "ecosystem":"PyPI","name":"pip",.
Do you want use default ecosystem for language packages?

can you also add testcase with multiple affected packages.

I'm not sure I fully understand what you mean in the question. We follow the pep440 conventions of versioning (using local versions for pypi packages).

No, I was talking about the affected[].package.ecosystem field.
You have a specific Echo ecosystem and use Echo for deb packages.
e.g.:

"package": { "ecosystem": "Echo", "name": "python-pip" },

But i see that you use "default" ecosystems for language packages
e.g.:

"package": { "ecosystem": "PyPI", "name": "pip", "purl": "pkg:pypi/pip" },

Since you have your "own" ecosystem — using "default" ecosystems is a bit confusing.
That's why I had the question — is this expected, and do you plan to "expand" the Echo ecosystem in the future (for example "Echo PyPI" or something along those lines)?

So we publish advisories both for OS packages and for language packages in OSV.
I assumed that the default ecosystem is relative to the package ecosystem, is it not how it works? For "Echo" packages it should be our versioning logic, and for PyPi I assumed that "default" means pep440.

Hey @DmitriyLewen, we changed our osv pypi records to have a new ecosystem Echo:PyPi

DmitriyLewen · 2026-04-14T09:13:28Z

+
+			ecosystems := map[string]osv.Ecosystem{
+				"echo": {
+					Dir: "",


It's better to use the original folder here to verify the file paths.

Suggested change

Dir: "",

Dir: "echo-osv",

Replace synthetic test advisories with real ones (ECHO-003f-2632-599c for openssh, ECHO-7db2-03aa-5591 for pip with multiple affected packages) to address PR review feedback. Made-with: Cursor

Rebuild osv-all.zip with real Echo advisories, update wantFiles paths to match, and use Dir: "echo-osv" to verify the full file path. Made-with: Cursor

orizerah · 2026-04-15T14:17:00Z

Hey @DmitriyLewen, I addressed you comments :)

DmitriyLewen · 2026-04-16T08:47:52Z

Hello @orizerah
Thanks!

what about this comment?

Are you planning to expand your ecosystem?
Or will you use the default ecosystems for language packages?

orizerah · 2026-04-21T07:18:44Z

We have issues with the OSV records, so I'm drafting this PR until we fix it

Update golden test files to include the upstream field added to the OSV type, fixing TestOSVUpdater_Update/happy_path failures. Co-authored-by: Cursor <cursoragent@cursor.com>

Echo now publishes Python advisories under the Echo:PyPI ecosystem namespace instead of PyPI. Update the test zip and golden file to reflect the new upstream format. Co-authored-by: Cursor <cursoragent@cursor.com>

orizerah · 2026-05-10T08:54:35Z

@DmitriyLewen we fixed the issue with OSV and I made some changes to the code.

DmitriyLewen · 2026-05-19T09:35:16Z

 	target = flag.String("target", "", "update target (nvd, alpine, alpine-unfixed, redhat, redhat-oval, "+
 		"redhat-csaf-vex, debian, ubuntu, amazon, oracle-oval, suse-cvrf, photon, arch-linux, glad, cwe, osvdev, mariner, kevc, wolfi, "+
-		"chainguard, azure, openeuler, echo, minimos, eoldates, rootio)")
+		"chainguard, azure, openeuler, echo, echo-osv, minimos, eoldates, rootio)")


We will merge this and related PRs together.
So should we save previous source (I mean echo dir)?

We need the echo dir for the os package scanning, but the OSV mostly for our Language Package advisories, should we filter them to decrease the dir size?

So the OSV package doesn't contain advisories for OS packages?
Or is the list incomplete?
I just saw a file for OS packages in the tests and thought the OSV archive contained all your advisories.

It contain all of our advisories. But we still want Trivy to work with our data.json file for advisories.

Having 2 sources complicates the code and maintenance:

we need to keep track of 2 packages

the code must exclude advisories (e.g. OS packages from OSV and language packages (if any) from data.json)

What positive aspects or necessary points do you see for using 2 databases?
Perhaps we can address them right away.

We build our OSV and data.json advisories differently. We rely on our findings from scanning our images with Trivy (using the data.json) to build the OSV advisory for other scanners.

Language packages are different, and we were asked to implement it using OSV to remain aligned with other vendors.

The data.json doesn't hold language packages (so no change is necessary), but I will filter out the OS packages from echo-osv.

We build our OSV and data.json advisories differently. We rely on our findings from scanning our images with Trivy (using the data.json) to build the OSV advisory for other scanners.

I compared the OSV source and the data.json file and found that the OSV feed does not contain all the advisories for OS packages (compared to data.json).
If I understood correctly — this is exactly what you meant.

Could you clarify how feasible it is to "populate" the OSV source with all the advisories?

In the meantime we will discuss the option of using 2 sources internally within the team.

Hey @DmitriyLewen
It's currently not very feasible to populate the OSV with the full data.json data. That's because we build it using the results we get from scanning with the data.json itself.

I changed the code here to only import the language packages advisories from OSV so it will reduce the amount of data we add to the db.

I changed the code here to only import the language packages advisories from OSV so it will reduce the amount of data we add to the db.

Hello @orizerah
Thanks!

As I mentioned earlier, I noticed that the OSV feed contains only a portion of the advisories.
Could you share information on why you only store a portion of them?
And is it possible to keep only the advisories for language packages in the OSV feed (so that the filtering is on your side)?

Hey @DmitriyLewen

The OSV feed contains only a portion of the CVEs because we build it based on CVEs we detect using other advisory sources. To be concise, we detect CVEs using our data.json as a source (which is built to contain a larger scope of CVEs), and those detections are used to feed OSV.

Unfortunately, we can't keep only language package advisories in OSV because other scanners use it to scan our images with it.

DmitriyLewen · 2026-05-19T09:36:06Z

+
+const (
+	osvURL = "https://advisory.echohq.com/osv/all.zip"
+	osvDir = "echo-osv"


same question.
osv package removes previous files, so we can use echo dir here.

osv export

e443a34

DmitriyLewen reviewed Apr 14, 2026

View reviewed changes

orizerah added 2 commits April 15, 2026 09:43

test: use real Echo advisories in OSV golden files

0a8fb78

Replace synthetic test advisories with real ones (ECHO-003f-2632-599c for openssh, ECHO-7db2-03aa-5591 for pip with multiple affected packages) to address PR review feedback. Made-with: Cursor

test: update test zip and assertions for real advisories

7e4b765

Rebuild osv-all.zip with real Echo advisories, update wantFiles paths to match, and use Dir: "echo-osv" to verify the full file path. Made-with: Cursor

This was referenced Apr 19, 2026

feat(echo): add echo language package advisories aquasecurity/trivy-db#659

Open

feat(echo): Support echo language package scanning aquasecurity/trivy#10555

Draft

orizerah marked this pull request as draft April 21, 2026 07:18

orizerah and others added 3 commits May 3, 2026 14:40

add upstream to the osv type

e8d2e1b

test: add upstream field to OSV golden fixtures

7565992

Update golden test files to include the upstream field added to the OSV type, fixing TestOSVUpdater_Update/happy_path failures. Co-authored-by: Cursor <cursoragent@cursor.com>

test: rename PyPI ecosystem to Echo:PyPI in OSV fixtures

f96ae1d

Echo now publishes Python advisories under the Echo:PyPI ecosystem namespace instead of PyPI. Update the test zip and golden file to reflect the new upstream format. Co-authored-by: Cursor <cursoragent@cursor.com>

orizerah marked this pull request as ready for review May 7, 2026 14:44

DmitriyLewen reviewed May 19, 2026

View reviewed changes

filtering out os packages from our osv advisory

d6276c3

Conversation

orizerah commented Apr 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

orizerah commented Apr 15, 2026

Uh oh!

DmitriyLewen commented Apr 16, 2026

Uh oh!

orizerah commented Apr 21, 2026

Uh oh!

orizerah commented May 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants