Create a provider for Julia advisories

[westonsteimel]

What would you like to be added:

Add a new provider to support vulnerability matching for Julia packages. There are security advisories available at https://github.com/JuliaLang/SecurityAdvisories.jl and in OSV format in https://github.com/JuliaLang/SecurityAdvisories.jl/tree/generated/osv

Why is this needed:

Enable improved vulnerability matching for the Julia language ecosystem

[westonsteimel]

Okay, I guess we'd need to implement a cataloger for julia packages in syft first

[westonsteimel]

Okay, I guess we'd need to implement a cataloger for julia packages in syft first

Actually, this isn't strictly true. It is perfectly acceptable to build a vunnel provider to start pulling in the data and implement the syft cataloger at a later stage, particularly when it is an already well-defined OSV data shape since vunnel is mostly just caching the data it is given and all of the transformation logic that needs syft package names and grype ecosystems to align happens in grype-db

[willmurphyscode]

Some of these will be missing severities, right now, for example GHSA-4g68-4pxg-mw93 is not in the global GHSA set, and https://nvd.nist.gov/vuln/detail/CVE-2025-52479 is not reviewed yet, so right now we need to either:

1. Accept that it is unknown when pulling from the Julia OSV data
2. Make the vunnel provider also fetch the repo-specific GHSA e.g. from https://github.com/JuliaLang/SecurityAdvisories.jl/blob/generated/osv/2025/JLSEC-2025-1.json#L62 ;

@westonsteimel maybe option 2 is worth it? It would make the Julia provider probably need GH token, but that's not a huge deal. We would also need to make sure that we can pick the right source URL from the OSV data base specific, and interpret whatever it returns.

[westonsteimel]

Yeah, I think that sounds reasonable

[willmurphyscode]

Actually @westonsteimel it looks like GHSA-4g68-4pxg-mw93 doesn't have a CVSS vector; it just has "severity": "medium". Is that still worth capturing?

[willmurphyscode]

Based on taking a look at this, most (97%) of Julia vulns don't have a severity we can pull from NVD (CVE isn't analyzed yet), and grype-db currently wouldn't put severities on the 3% of Julia vulns where we do have it: https://github.com/anchore/grype-db/blob/8fb5e3be99582f8fcb8487f16b4731dee0b62405/pkg/process/v6/writer.go#L217

@westonsteimel let me know how you'd like to proceed - I don't know whether we consider unknown severity a big enough drawback to blog on merging a provider or not.

[westonsteimel]

I don't consider it a blocker, much better to have matches than not. People can use the severity filters to get rid of things they don't want to see

[westonsteimel]

But also, this is the future, as NVD continues to slow down on analysis.