close search bar

Sorry, not available in this language yet

close language selection

Equifax reminds us: Open source audits are only a first step

On-demand open source audits aren’t enough. The Equifax data breach highlights the need for post-audit vigilance, particularly for security vulnerabilities.

Equifax reminds us: Open source audits are only a first step

The Equifax disaster underscores the importance of vigilance even after completing open source audits, particularly with respect to security vulnerabilities.

Much has been written about the recent breach. Here’s a good overview. In a nutshell, germane to this discussion, the exploited vulnerability was in a popular open source component, Apache Struts, that was made public in March, prior to the Equifax attacks. A patch was made available along with the disclosure; Equifax just didn’t apply it.

RELATED: Equifax, Apache Struts, and CVE-2017-5638 vulnerability

Identifying and managing open source

One can only speculate as to why, but it is the case that most companies can’t effectively identify let alone manage the open source components in their codebase. This is why companies perform audits, the purpose being to identify all of the open source in a code base and to highlight current risks. Given most companies don’t do this very well on their own, such audits have become an important tool in M&A transactions, giving the parties an understanding of potential problems that can be addressed in pre-close.

Open source audits: a snapshot in time

But an audit is a snapshot in time and security vulnerabilities are dynamic in nature. They may lay latent in code for years before being discovered (often by good actors, sometimes by bad). That’s why just knowing about the composition of a codebase isn’t enough. Let’s say a private equity firm had acquired Equifax in December and performed an audit as part of the acquisition. They would have been learned that Struts 2 was being used—probably among a hundred or more other open source components—but would not have been aware of CVE-2017-5638, the exploited vulnerability, which was not discovered and publicly disclosed until March.

The audit is an important first step, but after identifying the components of a code base, those responsible for a codebase need to monitor for newly identified security vulnerabilities. Unlike with commercial code, no one is pushing patches at users. Someone needs to be paying attention. The fictional Equifax acquirer would have done well to put a monitoring process in place soon after close.

Daily vulnerability disclosures

Every day about 10 new open source vulnerabilities are disclosed. The average codebase contains about 150 open source components. So it can be nontrivial to stay on top of manually. Tools like Black Duck automate monitoring and track remediation. At minimum, a company needs a process to flag relevant new vulnerabilities.

Open source audits should be part of due diligence whenever software assets represent a significant part of the value of an acquired company. But Equifax reminds us that companies must remain vigilant post-close as well.

Thinking about acquiring a company? Don’t forget to audit the codebase.

Get an open source audit now

Phil Odence

Posted by

Phil Odence

Phil Odence

Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.

More from Open source and software supply chain risks