But how does a team recognize when a malicious insider intentionally makes a rogue modification or when an outsider does something using the legitimate credentials of a trusted developer?
At least one firm I came across a few weeks ago is looking at and trying to solve the problem. KoreLogic has been working on a DARPA project, which is determining the symptoms of malicious modifications in source code repositories and how to generate the appropriate alerts.
The project is in keeping with DARPA's mission of creating new and innovative technologies. In this case, the objective is to address the difficult problem of malicious users who have authorized access, which traditional defenses are less effective in detecting. As part of its technology transition plan, KoreLogic is exploring the level of awareness to this risk and the interest in making a code repository early-warning system to generate a product for the government and the private sector.
After just a few conversations with two KoreLogic employees, I started to realize how specialized and nefarious such attacks can be. For instance, a rogue employee or outsider could cause a previously fixed bug to reappear in the final product simply by re-arranging versioning tags. It would be difficult, unless you are specifically looking for such a move, to detect that such a change was made. Not to mention the fact that anyone accessing your source code repository would have a great road map to what vulnerabilities you were working on that were not already fixed in previously published code. I have been involved in a few APT scenarios where the bug database was downloaded for review.
Many source code repositories have little security beyond very general access control. Some have very basic file integrity monitoring and alerting built in, but KoreLogic was able to describe several valid attacks against always-changing SCM files that could not be caught with simple file monitoring. My development days are long over, but I certainly gained a deeper understanding of the challenges facing software developers and their attempts to keep their code secure. I was further surprised that I knew of only one company that was even looking into the problems, considering how widespread the potential attack space could be.
Is your source code really safe? Would you notice if someone maliciously manipulated your source code or source code repository? Your source code should be specially treated and protected.
Ken Thompson gave us the warning. Did we really listen?
This story, "Protect your source code before it's too late," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes's Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.