Proposal: detecting silent (no-CVE) security fixes in PyPI releases, NLnet CodeSupply, building on #1721

[csuvikv]

Hi AboutCode team @ziadhany @TG1999

I'm Viktor Csuvik. I run MALI Labs, a small AI and software engineering company in Serbia, and I have a PhD in computer science / AI. I'm preparing a proposal for the NLnet CodeSupply open call (deadline 3 November). Before I submit, I'd like to check that it fits what you are building and that it extends your work rather than duplicating it.

The idea comes from your GSoC 2026 list ("Process unstructured data sources for vulnerabilities"). I've read #1721 and its sub-issues #2000–#2003, so I know you already collect fix commits that reference a CVE from commit logs, changelogs, issues and PRs. My proposal would focus on fixes that have no CVE or GHSA reference:

• for PyPI releases, read changelogs, release notes and linked issues/PRs, and use an open-weight model running locally to flag likely security fixes that have no advisory, each with the source passage and a rationale;
• resolve each candidate to the fix commit, a PURL and a VERS fixed range;
• feed the candidates into your curation flow (#1717) for human review, never straight into published data;
• build an open, human-validated benchmark of recent silent fixes and "hard negatives" (non-security fixes that read like security fixes);
• write everything as VulnerableCode importer/improver code, in line with #2318 and #2319, so it can be merged upstream.

A few questions before I finalise the plan:

1. Does #2002 ("security fix indicators" in issues and PRs) already go beyond CVE matching? If so, where would the gap be?
2. Should candidates without a CVE come in as draft advisories through an importer, or go straight into the #1717 curation flow?
3. Would you rather our component consume the VCS collector's output and add security annotations, or run as a separate pre-filter that emits VulnerableCode-format records?
4. When the commit that introduced a vulnerability can't be identified, what lower bound do you want for the affected VERS range?
5. Would you be open to hosting the benchmark under aboutcode-org? And does anything in your own CodeSupply work plan already cover this?

If you think it's useful, a short note saying you'd welcome the work would help the proposal a lot. If it overlaps with your plans or should be scoped differently, I'd rather hear that now and adjust. I'm happy to join a community call this week.

Thanks for your time and for VulnerableCode.

Best regards,
Viktor Csuvik
viktor.csuvik@malilabs.com