Question: How do I find which commit fixed a CVE in a large repository?
Git bisect your way out of it
A single OSS like Hadoop has over 300+ commits, 700+ files changed between a vulnerable version and a patched version. Going over each commit to find out which commit fixed it isn’t fun.
Answer
You want to know if something was fixed, so you know a good end point and a bad
start point? In that case you can use git bisect.
This allows you to pinpoint the fix in about 8-9 steps (bisect is a binary search).
Assuming you know:
- A commit (or tag) where the CVE was still present → that’s your good
- A commit (or tag) where it was fixed → that’s your bad
git bisect start
git bisect good <point-in-time-where-cve-was-present>
git bisect bad <point-in-time-where-cve-was-fixed-or-HEAD>
Why do I flip good and bad? Well, because that is how git works. The bug is in this case the fix. You’ll need to apply an alternative term for your use case to keep your head in the right place: bad would be “fixed” and good would become “cve”, or use any other term that makes sense to you.
Now, if you know how to analyze the code and have that scripted, bisect is
becoming your besty:
git bisect run my_script arguments
See man git-bisect for more on that.
And if you know a CVE that was fixed by commit X in a project, you could use that project to test the above workflow and be confident about the approach.