Not long after T-Mobile and HTC released the very first Android handset, news broke that a flaw had been discovered in the Android code base. Though the flaw has since been corrected, representatives at Palamida, an application security software provider, say it highlights the very reason companies like theirs exist.

Earlier this month, I spoke with Palamida's product marketing VP, Theresa Bui Friday, about the flaw and what it can teach end users about open source.

Bui Friday explained that the flaw was in an open source component known as Webkit, which runs HTML and JavaScript in a Web browser, and thus would have put at risk users who browse the Web with their Android phones, because a hacker would have been able to access usernames and passwords stored in cookies on the browser.  She also pointed out, though, that the problem arose not because Webkit is a poorly maintained project, but because a developer had included an out-of-date version of Webkit in the Android code:

The issue was that this Webkit version was about four months out of date. If you go onto the Webkit project homepage, you'll see that they allow you to download nightly builds, even. That's more for the development community, and not every nightly build is stable, but the project is very current and up to date.

And similar things happen all the time, in all kinds of companies, Bui Friday said. For example:

Picture an insurance company that has 2,000 developers around the world. If that company is getting ready to launch a new site, its leaders want to know every piece of inventory that's on it and that has gone live. The problem arises when you've got a dispersed global development team and no policy or process in place to manage open source procurement. In that case, any developer, whether he or she is in San Jose or in India, can download code like Webkit and include it, and the security team doesn't even know if no one tells them. Often the manager doesn't know, and certainly the product manager, or the person who owns the business of that site, doesn't know.

And if the person who owns the Web site doesn't know it includes a particular open source component, he or she won't know that the vulnerability alert that just came out about that component is something to be concerned about.

That's why open source procurement and audit policies are so important. Through them, companies can keep track of the code that's used in their infrastructure and make sure it's up to date.  What those policies and procedures look like, though, can be different depending on the company. Smaller ones can get away with a procurement policy that requires a developer to e-mail a team lead before including third-party code, and an audit process that involves those developers going through the code manually to make sure the components are up to date. Larger companies whose infrastructure includes millions of lines of code will have no choice but to invest time and money in training on procurement policies and technology to aid in the audit process.

No matter how you do it, know what's in your code. One of Bui Friday's analogies usually "hits home with CIOs," she said.

Imagine if you were the CIO of a company and I reported to you. Say I managed the databases. All year long I've been telling you, "We have 40 Oracle databases that run our Web site. My team is properly assigned to it, we have the contract, Oracle is giving us support," etc. Then imagine me walking in and saying, "You know what? I was wrong. We actually have 100 databases, and I don't know where the other 60 came from. I don't know who the vendor is, and no one on my team is assigned to monitor them, but they're running our Web site: They're processing credit card information from us, they're housing user names and passwords, but I didn't know they existed until today." In an IT context, I'd be fired.