Posted by Phil Odence on October 20, 2016
I occasionally get the question about when a code base really really needs an audit. Biased though I am, I sincerely believe that in anticipation of an M&A transaction whenever software assets are a significant part of the valuation of a company, someone ought to perform a detailed audit. Here I have provided some preliminary questions to a software due diligence checklist for both buyers and sellers.
First, everyone uses open source. Everyone. If a company tells you they don’t, be 99% sure they are naïve or lying. Second, there is a lot of open source code out there that is risky. There’s plenty of good stuff too, but if a company is not sorting through and making good decisions, there are likely problems in the code base. More often than not, our audits turn up problems that need to be addressed.
Third and fundamentally, we’ve seen evidence time and time again that code owners rarely know what is in their code. In a study we did earlier this year, less than half of code owners actually can produce a list of known open source. And those who do, on average, are aware of only half of the open source in their code. So, not only do they not know, but they actually think they do know, a dangerous combination.
I use the term “code owner” like it’s a person. It isn’t; in fact, the code owner is a company comprising many people. The ones involved in the M&A who are weighing in on this point are typically the CTO or VP of Engineering, and usually they are not writing the code anymore. The developers are from a generation who grew up assembling code from any pieces they could beg, borrow or “steal” (maybe literally, though without knowing). Downloading open source is a one-person operation, a brief encounter between person and repository and code that just looks like any other code. Without being extremely well organized, a software development organization (for example, the managers) really can’t know what their developers have been downloading.
I said “someone” should do a code scan; that someone could be either the buyer or the seller. As a seller, if I am going to represent that the company is “all good” with respect to licensed third party code, if I am going to sign something that says that, I want to know what’s in the code. And, as a buyer, even if I trust that the guys signing the papers know what they are talking about, I want to verify. So, either way, I want that code audited.
Yes, in my opinion there should be an audit every time. But, I will acknowledge there are times when you need a code audit and there are times when you really need a code audit. The latter scenario is when the company that developed the code does not practice even a reasonable level of open source management. To aid business people in making this assessment, we’ve assembled a due diligence checklist to provide some guidelines for assessing a company’s software. Whether within your company or with a target, if you get weak answers to these questions, do yourself a favor and get an audit.
Get the latest Software Integrity news, thought leadership, and more.