You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fedcode-next: Code pipeline and models to continuously automatically collect fix commits #1721
We should have a code pipeline and models to continuously automatically collect commits and patches that introduce or fix a vulnerability to support reachability analysis. There is already some base that analyses references. Here we need to dig deeper and scout the commits logs, changelogs and issues logs to discover and bisect if needed to find the subset of the code changes that we care for.
Today we can detect fix commits based some explicit references to commits, these are not always correct. We could validate the fix commits we have already
We have multiples issues that need to be triaged and "defragmented".
We need one issue with only the usable research/projects to:
IMO we should treat fix commit data as advisory, but special advisory. As brought up by @keshav-space we can accomodate the changes in impacted package data model as well. Thanks!
I agree with that we should treat fix commits as advisory and may be avoid creating Codefixv2 entries directly relying on the CollectFixCommitsPipeline to create a Codefixv2 and associate them with the impacted package data model.
but this will limit our abilities to detect/store fix commit that is no related to any aliases as some developer just fix a vulnerabilities without creating a CVE but I think this is out of scope for now, especially since many of these cases are false positives.
IMO we should start with simple pipeline that parse git logs from key repositories linux / django
using regular expression searching for CVE-xx, GHSA-xx or XSA-xx and store them as advisory with some references
Activity
ArkaprabhaChakraborty commentedon Jan 20, 2025
Hi @pombredanne! as discussed over the call I want to work on this.
ArkaprabhaChakraborty commentedon Jan 20, 2025
but before diving into this I want to contribute to a quickie good first issue on the similar track.
pombredanne commentedon Jul 18, 2025
Some issues of interest:
TG1999 commentedon Oct 11, 2025
IMO we should treat fix commit data as advisory, but special advisory. As brought up by @keshav-space we can accomodate the changes in impacted package data model as well. Thanks!
ziadhany commentedon Oct 11, 2025
I agree with that we should treat fix commits as advisory and may be avoid creating Codefixv2 entries directly relying on the CollectFixCommitsPipeline to create a
Codefixv2and associate them with the impacted package data model.but this will limit our abilities to detect/store fix commit that is no related to any
aliasesas some developer just fix a vulnerabilities without creating a CVE but I think this is out of scope for now, especially since many of these cases are false positives.IMO we should start with simple pipeline that parse git logs from key repositories
linux/djangousing regular expression searching for CVE-xx, GHSA-xx or XSA-xx and store them as advisory with some references
For example:
this will generate a really interested fix commits we are really missing vulnerablecode
pombredanne commentedon Oct 15, 2025
This PR is ready for review:
ziadhany commentedon Apr 14, 2026
To close this issue, we need to merge these PRs in sequence:
ziadhany commentedon May 14, 2026
These are also some PRs we need to merge:
More data collection for code commits:
Collect GitHub PoCs:
ziadhany commentedon May 15, 2026
This is done now. This will continuously and automatically collect fix commits to track introduction or fix of a vulnerability.
see:
And the four main tracking issues have also been completed: