Feature: consider Python version when reporting a vulnerability

[jenstroeger]

Pre-submission checks

• I am not reporting a new vulnerability or requesting a new vulnerability identifier. These must be reported or managed via upstream dependency sources or services, not this repository.
• I agree to follow the PSF Code of Conduct.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

Following up one issue pypa/pip#13607

It seems to me that pip-audit doesn’t consider the Python version it runs on when reporting a vulnerability.

For example, we run pip-audit in a CI workflow on Python 3.13 which also matches our deployment environment. However, GHSA-4xh5-x5gv-qwph (CVE CVE-2025-8869) does not affect Python 3.13 (apparently) and yet it’s being reported.

Describe the solution you'd like

Would be nice that vulnerabilities that don’t apply to the actively running Python version could be ignored. Assuming the Python version itself is reported by the metadata.

Additional context

No response

[woodruffw]

Hi @jenstroeger, thanks for filing this. I agree this would be good to have, but it's unfortunately a data quality issue: I don't believe OSV provides ecosystem version information like this in a machine-readable fashion by default, so pip-audit doesn't have a straightforward way to perform these kinds of filters.

(There's the ecosystem_specific field, but that field requires OSV report creators to agree on a representation + actually use it.)

TL;DR: This is something pip-audit could do, but we need vulnerability authors (or enrichment services like OSV/PYSEC) to provide the appropriate machine-readable metadata here. To do that, they probably need to agree on an ecosystem_specific encoding for Python versions 🙂

CC @di for thoughts + I figure you might know some of the OSV folks who would have thoughts on this!

[keerthanap8898]

hmm. would something like this work?

[woodruffw]

Yes, assuming we can get consensus from vulnerability feed providers to consistently use that format. I think that won't be super hard, but it requires someone to own coordinating that.

[gcomneno]

I opened a small PR to document and add coverage for affected[*].ecosystem_specific.python_runtime in the OSV service (no filtering / no behavior change), to help future work once a stable encoding is agreed upon: #997.

[keerthanap8898]

Responding to @woodruffw -

"Yes, assuming we can get consensus from vulnerability feed providers to consistently use that format. I think that won't be super hard, but it requires someone to own coordinating that."

• Yup I'm discussing the pros and cons of pushing this filtering at the osv level vs communicating it as a feature request upstream at vendor advisory level (eg- ghsa; but note that ghsa is isn't the only provider, nor the biggest provider of relevant python CVEs).

• The alternatives afaik and verified are currently conflicting in terms of key ( imo ) plausibly necessary optimizations such as minimizing the development, maintenance, & associated provenance verification effort that comes with either:

• A. Owning the parsing automation efforts at OSV level:

• PROS:
  1. provenance is easier
• CONS:
  1. schema variations will be hard to deterministically track &/or validate since it's coming from a somewhat steady but never fixed size of the list of all potential, up-stream, py-advisory publishers (correct me if I'm wrong, that broke my brain also);
  2. adding more conditional logic in a security data verification layer like OSV increases the exploitable code surface area by much more than if it came from any 1 subset-group of or any specific advisory vendor.
• But the real question here is =>
  • Does OSV want to, and should/can they own the reliability and full scope of maintenance effort that automation like this will cost in the long-term?

versus------------------------------

• B. Owning the initial/periodic communication efforts (to ALL py advisory vendors) to collectively agree upon a schema template:

A template that we can all follow essentially;

• PROS:
  1. OSV parsing logic correctness,
     • is much more reliable since the values remain idempotent irrespective of individual upstream schema changes since the ownership of correctness can then rely on the publishing entity that actually has access to the most accurate source info.
     • The validation tests would then have a way longer validity lifespan & also be more effective long-term, in terms of pkg SLOs (hypothetical idk; PEP wtv I guess)
• CONS:
  1. If it were that easy, someone would have done it by now.
  2. Humans collectively suck at long-term reliable communication schedules, especially more so when it's:
     • niche,
     • involves a bunch of technical reading, and
     • requires one to take unpaid initiative to communicate with the industry at large - ie., something they do as a job (like most folk working in this supply chain),
       • as opposed to the idea of one having obsessive interests & curiosities- like some unpaid mega nerds practice - like everyone on this thread, lol (heed my humor pls).
  3. That's just how dopamine works I guess. 🤷🏻‍♀️
• Exit criteria with this option =>
  • We will most likely need to extend with more collective planning.

---

To conclude,

I'll next try & get more folk from OSV, &/or GHSA, etc.; to review/comment on the technical bits of the gist of pending steps, that I drafted above.

---

• Feel free to add suggestions / follow ups etc.; I'm mostly just brainstorming & thinking out loud here.
• On that note - Hi @andrewpollock, I'm inviting you to pitch in.

[gcomneno]

Proposal for expressing Python runtime applicability in OSV records for PyPI:

• Add affected[].ecosystem_specific.python.requires_python
  • type: string
  • format: PEP 440 specifier set (e.g. >=3.8,<3.13, >=3.10,!=3.11.0,!=3.11.1)
  • semantics: if present, that affected[] entry is applicable only when the target/runtime Python version matches. If absent → no runtime filter.

If constraints differ by package version range, split into multiple affected[] entries (same package, different ranges, different requires_python) instead of adding nested conditionals.

Consumers (pip-audit) can then apply package range checks + requires_python filtering to avoid false positives for unsupported runtimes.

[woodruffw]

I don't know why this repo is getting so much volume recently, but as a gentle reminder: this is not the right place to submit design proposals for OSV's schema. The OSV folks don't monitor these issues, and I don't have the experience with OSV's internals or design pressures (or the time) to intermediate a standards discussion.

If you're interested in working on this, you need to coordinate with upstream services to get a scheme adopted here. pip-audit is not the right place to shop a design around.

[keerthanap8898]

If you're interested in working on this, you need to coordinate with upstream services to get a scheme adopted here. pip-audit is not the right place to shop a design around.

Ahh I suppose the osv schema is actually the only thing I'm invested in. Not pip-audit. I'm especially trying to figure out what the false neg/pos cases look like with this schema opposed to CVE.

I would ideally never submit anything to a py pkg directly myself as of now. There's actually no other designated place to bring this up upstream either. I could just tag the upstream reps here but I'd rather see what osv has to say before that because idrk.

I spend more time planning than I do submitting PRs lol.

[woodruffw]

There's actually no other designated place to bring this up upstream either

https://github.com/google/osv.dev

Edit: the link below is even better.

[di]

Also, https://github.com/ossf/osv-schema