feat: support wildcard package name '*' in schema and linter

[another-rex]

This PR introduces support for a special wildcard package name * to the OSV schema and the osv-linter validation tool.

Changes

• Update the schema.md to document the wildcard package name * which allows an advisory to affect all packages within a specified ecosystem (e.g. to denote EOL).
• Also updated the linter and jsonschema

This fixes #519 by providing a mechanism to represent End-of-Life (EOL) for an entire ecosystem without having to list every individual package. By using a wildcard package name *, data providers can publish a single advisory for the EOL ecosystem version (e.g. Ubuntu:18.04). Any query for a package within that ecosystem will then match this advisory, alerting users that the ecosystem itself is no longer supported, so the results might not be complete / up to date.

Definitely looking for feedback on this approach!

[dodys]

@jasnow @DmitriyLewen fyi

[DmitriyLewen]

Hello all
@dodys Thanks for ping.

Correct me if I'm wrong:

The idea behind this change is to mark a release as EOL — i.e. a package entry with name: "*" means the advisory applies to the whole ecosystem, and here it's used to signal that the release has reached EOL.

This helps with the problem of records simply "disappearing" after EOL, but it doesn't really help scanners.

From a scanner's point of view, we now at least know that the release is EOL, rather than it being missing from the data for some unknown (for scanner) reason. (Worth noting: Ubuntu's OSV records only list affected packages/releases — there is no "not-affected" representation, so today a missing release is ambiguous: it could be not-affected, or just no longer loaded because it's EOL. The wildcard removes that ambiguity.)

But we still don't know the affected packages: we don't know whether all known vulnerabilities were fixed before EOL, or whether something was found after EOL that will never be fixed, and so on.

[another-rex]

Yes, that's mostly correct.

we don't know whether all known vulnerabilities were fixed before EOL

If a known vulnerability is fixed before EOL, the advisory for that vulnerability should contain a fixed version that's released within that ecosystem.

or whether something was found after EOL that will never be fixed,

This it doesn't show this information, but from what I understand, that's what EOL is describing - this ecosystem/release is no longer maintained, so no one is processing or publishing any vulnerability reports, and you should move off this release, as packages used within will be a blind spot for any scanners.

[DmitriyLewen]

Am I understanding correctly that you are proposing to always keep a record for a specific release?

• Keep the correct package name for an Release entry with:
  • a fixed version before EOL;
  • Confirmed vuln, but there is no fix and the release going EOL;
  • if the bug was found after EOL (for example, the same component version is installed in both a newer and an older OS version; a vulnerability was found in the newer OS and the component in the older OS was marked as vulnerable — if I understand https://ubuntu.com/security/CVE-2024-0564 (Ignored end of standard support, was needed) correctly, this is that case; @dodys please correct me if I'm wrong).
• Use the wildcard for:
  • unconfirmed vulnerabilities.

If that's the case, then this is a solution for scanners, but this PR isn't really related to the solution, because these changes only extend the information (EOL, or the package is not vulnerable).

If you do think that the past records (with fixed versions, etc.) should be replaced with a wildcard, then the wildcard solution will not help scanners. At the moment of EOL (a day or two after the records are replaced), users will stop receiving advisories for that OS.
Upgrading the OS is a long and complex process for many (the "bigger" the user, the harder it is).
But until they upgrade, users need to know that their OS is vulnerable (e.g. if they are not yet on the latest version). This serves as an additional motivator for users to upgrade the OS.

[another-rex]

I'm not quite sure I understand your comment. This proposal does not apply to existing records. This is the rough timeline I'm imagining,

1. Vulnerability Found: A vulnerability for pkg: foo in ecosystem abc:12 is found.
2. Fix Developed: A fix for pkg: foo in abc:12 is made.
3. Advisory Published: An advisory for pkg: foo in abc:12 is published with the fix version.
4. Ecosystem Goes EOL: abc:12 goes End-of-Life (existing advisories still exist).
5. EOL Blanket Advisory Published: An EOL advisory is published for abc:12, which matches all packages in the ecosystem. (What this proposal enables)
6. New Vulnerability Found: A new vulnerability is later found for pkg: foo in ecosystem abc:12.
7. No New Advisories Published: No new specific advisories are published for this vulnerability because the ecosystem is EOL.

Currently the same flow is happening, but step 5 is missing.

Upgrading the OS is a long and complex process for many (the "bigger" the user, the harder it is).

Could adding a date help with this? An advisory that's time bound, to let the user know that the EOL is coming up, and they should look at starting to migrate off e.g. 6 months earlier.

[DmitriyLewen]

Since the problem started with the removal of records from Ubuntu, a lot of my reasoning is based specifically on that experience.
Thanks a lot for the detailed example.

Currently the same flow is happening, but step 5 is missing.

Now I understand your logic, and this works for us.
@dodys, does this approach work for you?

Could adding a date help with this?

A date can definitely be useful for scanners — but I'd argue it belongs in a separate, machine-readable source maintained by the vendor with the official EOL dates.

The key reason is that these dates aren't static: some vendors revise them over time (Amazon Linux, for example, has pushed its EOL dates back more than once). Keeping them in one authoritative, machine-readable source means scanners always read the current value, and OSV stays focused on the vulnerability data — while the wildcard advisory still carries the present-tense "this release is EOL now" signal.

[dodys]

I think my biggest question is, where would this blank advisory just for the EOL would live?
Should we create under our repo something like: osv/eol/UBUNTU-EOL-25.10.JSON ? And would we need a new ID for it (like the example before)?
For the date, we could add to the same blank advisory, under ecosystem_specific.

[another-rex]

I think my biggest question is, where would this blank advisory just for the EOL would live?
Should we create under our repo something like: osv/eol/UBUNTU-EOL-25.10.JSON ? And would we need a new ID for it (like the example before)?
For the date, we could add to the same blank advisory, under ecosystem_specific.

Yes it would need to be a new ID, as for where it will live, from the scanner / ingestors perspective this shouldn't matter too much.