Java (Maven): Actually fix the use of insecure protocol to download/upload artifacts #38
Comments
|
Fantastic work! |
|
Hey, stupid question maybe, but you added "The Bug Slayer" to this Issue. |
|
@intrigus-lgtm Not a stupid question at all. I didn't realize that I could do this until I spoke with the GH Security Lab team. Yes, they are allowing this kind of 'double dipping' for now. They are going to see how it goes. I think it makes sense to incentivize both the writing of the queries and the actual use of the queries to go fix the vulns in open source. Without this 'double dip' structure, it incentivizes writing queries that find vulns but it doesn't really encourage any of us to really do anything about the results of our findings. Unfortunately, in most cases, writing and submitting a CodeQL query will actually take far less time than going through the process of working with maintainers to fix their software and actually get CVEs assigned. Personally, I don't think the payouts are accurately balanced with respect to each other to match the time sink cost. That being said, perhaps it's by design and the goal is to incentivize (for the time being at least) the addition of new queries into the QL query set. This is purely a guess though. |
|
Love this! Any chance there is a Gradle version coming down the pipe? |
|
As far as I know codeql currently does not support |
Correct, but if someone can get me the data somehow on all the vulnerable repositories along with the paths of the individual files, I could probably write a bot to fix those too. |
|
Thanks @intrigus-lgtm @JLLeitschuh. For the moment, just interested in evaluating a repo's "build.gradle" file exactly as you're looking at a "pom.xml" -- flag a vuln if the build.gradle is specifying a repository without https/sftp. Exact same idea, just a different builder. Thanks again for the quick replies here! |
|
Submission acknowledged and scored.
The bounty amount will be doubled for this submission. |
|
Payment order sent 🚀 |
|
Thanks @xcorail @nicowaisman and the whole GitHub Security Lab and CodeQL Team. I really appreciate this! This was so much fun! |
Good 'ol logo for this project.
Projects Fixed
All Pull Requests (clicky)
😢 Apparently GitHub won't render 1,596 links.Here is perhaps a more reasonable way to view this. (Maybe, not sure, it's still pretty bad):
JLLeitschuh/bulk-security-pr-generator#2
Here's a third way to view the data that uses the PR search/filter logic.
Report
This project builds on top of the original query running here:
https://lgtm.com/rules/1511115648721/
And the 'All For One' submission here: #21
I developed an automated tool that used data from LGTM to automatically create 1,596 PRs against all known projects vulnerable to this security issue.
The results according to data collected while the automated PR creation bot was running was that over the 2 days it took to run, I was able to fix 4387 vulnerabilities fixed in 2320 files across 1596 projects!
So far, 252 of these PRs are in the in the 'closed' state at the time of this post.
Most of them are merges, other were closed and merged manually, or via different mechanisms, and very few were just closed outright. Most of the ones that were closed outright, the maintainers quickly archived the repository.
The automated tool used to fix this vulnerability can be found here:
https://github.com/JLLeitschuh/bulk-security-pr-generator
The
save_pointsfile contains all the data collected during the operation of this tool.Heck yea! I live streamed doing it too!
https://twitter.com/JLLeitschuh/status/1226995322825695233
The text was updated successfully, but these errors were encountered: