A silly prank, but it makes me wonder: has anyone implemented an antivirus/anti-problem scanner for open source code? i.e. scan the source code on a git repository and report any suspicious code that matches known malicious patterns? Lint, but targeted at detecting likely security flaws and code injections.
Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution. I guess you could try to limit the tool to a list of established projects but that of course limits the effectiveness of what you're trying to do. Established projects may be more attractive as a delivery vector due to widespread adoption, but there's also more eyes looking at the code giving a potentially higher chance of discovery of any exploits. And new projects have less-deployment and potentially more active contributors who might more easily catch some exploit slipped in.
Then there's the problem that you've got how many languages you need to scan against? And no quick way to determine what language a project is implemented in? Sure, you could add some sort of language detection in there but then you're adding to the overhead.
Finally, if the project has any sort of real complexity, some of the best areas to exploit would be in the integrations between two technology surfaces. Writing a tool to look for problems in a single contained module is one thing, writing a tool that can find problems in the interfaces between modules is quite a bit more complicated.
I think your "anti-problem" scanning tool would be the best avenue to pursue though. Maybe some sort of tool that would run on "checkin/pull-request" and look for issues like introduced buffer-overflow potential and things like that.
I think it's just easier to rely on solid projects with "known" contributors to police themselves and hope for the best, as bad as that may sound. Still, if you could create such a tool you'd make a fortune and improve the world immensely, so don't let my nay-saying stop you.
> Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution.
You should totally tell that to TravisCI, I bet they'd like to know. =)
Comments
A silly prank, but it makes me wonder: has anyone implemented an antivirus/anti-problem scanner for open source code? i.e. scan the source code on a git repository and report any suspicious code that matches known malicious patterns? Lint, but targeted at detecting likely security flaws and code injections.
Coverity regularly scan open-source C/C++ projects and email contributors reports.
I've received a few such emails. Its a good way to market developer tools.
Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution. I guess you could try to limit the tool to a list of established projects but that of course limits the effectiveness of what you're trying to do. Established projects may be more attractive as a delivery vector due to widespread adoption, but there's also more eyes looking at the code giving a potentially higher chance of discovery of any exploits. And new projects have less-deployment and potentially more active contributors who might more easily catch some exploit slipped in.
Then there's the problem that you've got how many languages you need to scan against? And no quick way to determine what language a project is implemented in? Sure, you could add some sort of language detection in there but then you're adding to the overhead.
Finally, if the project has any sort of real complexity, some of the best areas to exploit would be in the integrations between two technology surfaces. Writing a tool to look for problems in a single contained module is one thing, writing a tool that can find problems in the interfaces between modules is quite a bit more complicated.
I think your "anti-problem" scanning tool would be the best avenue to pursue though. Maybe some sort of tool that would run on "checkin/pull-request" and look for issues like introduced buffer-overflow potential and things like that.
I think it's just easier to rely on solid projects with "known" contributors to police themselves and hope for the best, as bad as that may sound. Still, if you could create such a tool you'd make a fortune and improve the world immensely, so don't let my nay-saying stop you.
> Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution.
You should totally tell that to TravisCI, I bet they'd like to know. =)