On May 17th, eWeek's Darryl Taft did a Q&A with Chris DiBona, Google's open source programs manager that marked a significant moment in the life of code level risk mitigation (read it here).
2007 is truly the first year in which collectively, organizations are coming forward to say they not only understand the importance of knowing what's in their code they want to protect themselves from the risk — today. By questioning Google on their use (or not) of a comprehensive code audit solution, Taft introduced the notion that code level risk mitigation is de rigueur.
Everybody's doing it — right? Well, certainly, Palamida thinks that managing the intellectual property risks and vulnerabilities associated with using OSS should be an organic part of every build process. What's fantastic about Taft's question is not so much the fact that he asks whether Google uses Palamida (which is indeed fantastic), but that he thought to ask whether Google was using any solution to manage their OSS code level risks. This is a huge step forward in expanding on the notion that hey, who doesn't want to know what's in their code base and whether or not they're infringing on anyone's rights?
However, Mr. Di Bona's comments raised some eyebrows around here in regards to the "tightly controlled process" (his words) surrounding open source use at Google. The most brilliant of developers can, and regularly do, bring in OSS from unknown origins harboring unknown components. Palamida's experience has shown time and again that the more emphatic a company is about their OSS process, the more infringement and vulnerabilities we will find. Our non-scientific formula is that for every "We have x amount of OSS" we'll find 5 —10x more than that. This rarely comes from malicious intent on the part of the developers, but more from process complacence (or lack of process altogether). Inferring that they are immune to intellectual property infringement is a mighty claim, but more worrisome is the evidence that Google feels it is beyond vetting the code base. Beyond IP concerns, Google should be ensuring that their open source code is free from known vulnerabilities, a process that should be done consistently, with every build. Failing to do this leaves quite a hole in their "tightly controlled" process that would make it ripe for the hacking.
Palamida is pleased that Google mentioned our value in the acquisition process, an area that we have been quite successful in, but overlooks the great value we offer many hundreds of large companies who use us to vet their code base at various stages of the application lifecycle. The fact that Mr. Di Bona finds code audits "interesting" instead of integral is a good indication that Google may feel it's invulnerable.
Software risk management is Palamida's business first and foremost and protecting the integrity of code developed for internal and external consumption is our priority. We applaud all organizations embracing open source and taking the steps to avoid business, legal and security risks.
--Melisa LaBancz - Bleasdale
