The frequency and scope of security breaches continues to grow. The most recent, involving the Equifax credit bureau, is larger in scale and likely more damaging, than any we have seen in the past. The recent Equifax data breach involved thieves making off with highly sensitive personal information including the Social Security and credit card numbers of at least 143 million people.

The most troubling aspect of this data breach is that it was likely to have been easily preventable. While Equifax is not sharing specific information about the specific breach, except to say it was Apache Struts-related, the most likely culprit was a vulnerability known to exist since March 2017.

So, why are all of these preventable breaches occurring, and what can be done?

Today, open source code components can be found in approximately 90% of the software applications, services and device firmware. It is truly a testament to the value placed on open source by the organizations that are developing essential every day and cutting-edge technologies.

Whether software code is proprietary or open source, there are security vulnerabilities. Open source software (OSS) tends to have more of these vulnerabilities because of its transparency, making it easier for hackers to hone their skills.

Known Open Source Vulnerabilities Hide in the Code

Fortunately, the open source community rallies to address vulnerability issues. Once open source vulnerabilities are discovered, they are quickly and publicly catalogued and patched within a short period of time. However, there are a number of factors that can lead to applications, platforms and devices that leverage open source code to contain numerous known security vulnerabilities.

In-house software development teams leverage third-party libraries that almost always contain OSS components. Often these libraries are only available in binary format. This either lowers the cost for the purchaser or is explicitly written into the software development contract to safeguard the third-party developers’ intellectual property.

To compound the issue, it is not uncommon for the source code components listed as part of the software app, platform or firmware – that are delivered to the final customer – to not accurately correspond with the shipping binary code.

Accurately tracking open source vulnerabilities in these code mash-ups ranges from merely challenging to impossible.

So, it is difficult to track these vulnerabilities, but not impossible to find them. The answer lies in using the right tool. Leveraging the binary code scanners, software developers can effectively uncover and patch known security vulnerabilities. Given the prevalence of open source components in today’s software, it is deficient, and some might go so far as to say negligent, if the code delivered to a customer contains known security vulnerabilities.

Why Source Code Analyzers Are Not Enough

There are a number of great source code software analyzers on the market. They are great tools to leverage during the software development process.

Static code analyzers and dynamic code analyzers have value at different times in the development process. Static code analyzers, whether they are examining source code or disassembled binary code, are looking common programing errors. They are effective at finding common problems such as buffer overflows and SQL injection flaws, but these are only a small percentage of security flaws.

Dynamic code analyzers actually execute in real or simulated environments, examining for unintended outcomes based on numerous input permutations. Unfortunately, they are costly to set up and execute, and are challenging to integrate into an automated testing process.

For these reasons, neither are suitable as a first line of security vulnerability defense – finding as many known security vulnerabilities as possible in the product.

Scan the Binary

Given all of these factors, scanning binary code before it is shipped to a customer is the first, best and most cost-effective line of software security.

For some time, there have been checksum and hash-based binary code scanners. While they have been reasonably effective, they have been constrained by limited databases of pre-compiled binaries of the most commonly used open source components.

Today, there are binary code scanners that use code fingerprinting. They extract “fingerprints” from a binary to be examined and then compare them to the fingerprints collected from open source components posted in well-known open source repositories. Once a component and its version is identified through this fingerprints matching, finding known security vulnerabilities associated with the component from vulnerability databases such as NVD is straightforward. Unlike checksum or hash-based binary scanners, they don’t need to keep separate databases of checksums or hash values for different CPU architectures. This significantly increases fingerprint-based scanners’ flexibility and accuracy in comparison to legacy binary code scanners.

Had Equifax scanned their development team’s or their vendors’ binary code for known open source vulnerabilities, prior to the code going live on their site, it is unlikely that they would be facing billions of dollars in potential lawsuits and brand impairments.

Software is becoming ever more sophisticated and powerful. Its advance and innovation can be tied directly to the proliferation of open source. As more open source components find their way into published software, it is critical that known security vulnerabilities within the software are uncovered and patched. Failure to do so will either significantly increase the number and cost of attacks or impair the adoption of new technologies powered by the software.

The first and best line of securing software from vulnerabilities is to leverage fingerprint binary code scanners and implementing the correct patches prior to distribution to a customer. CIOs watching the Equifax data breach unfold should take note.