The 2019 Open Source Security and Risk Analysis report noted that 60% of the code analyzed by the Black Duck Audits team in 2018 comprised open source. This finding reinforces what we already know: Companies are harnessing the power of open source software as they build applications. They’re also realizing that open source management tools are integral to ensuring software security and license compliance.
However, most open source management tools work best when they have access to source code in the build environment. In some use cases, such integration or visibility just isn’t possible. Let’s walk through three of these use cases and look at why binary code analysis is essential.
Your company procures third-party-developed software and embeds it into its products, and you need to identify potential open source security risks.
Large enterprises in industries such as automotive and financial services are typically not tech-driven. Instead, they rely on technology to drive their own portfolio of products. Take, for example, an automotive company that manufactures cars. In many cases, the company doesn’t create the technology embedded in those cars, such as GPS, Bluetooth, and heads-up displays. Instead, it procures a large portfolio of applications from vendors and contractors to make these technologies work. But just because the car manufacturer didn’t create the software doesn’t mean they’re not on the hook for it once they install it in their cars.
Typically, you don’t have access to the source code for third-party applications, even once you bring them in-house. Or you might be analyzing the health of the software as part of a buy cycle or security review before you purchase it. As we know, it’s highly likely that the application contains open source. In these situations, you need a binary code analysis tool to help you vet purchased software. After all, no one wants to be in a car that gets remotely hacked because of a vulnerable piece of software.
Your company uses third-party libraries or components, and you need to analyze them in the development pipeline.
In this use case, you’re not keeping third-party software separate from your own build. Instead, you’re integrating third-party libraries or components into your applications. As in the first use case, you don’t have access to any third-party source code. But you still need to identify, track, manage, and monitor the open source embedded in those third-party components just as you do the open source components you pull in on your own.
To do this, your open source management tool needs to scan binary code like it scans source code. It should also enhance your software bill of materials with the information it uncovers during binary code analysis. That way, you get a complete, accurate BOM that covers any third-party components in your application.
Your company is a large organization with a centralized security team that does not have access to the build environment.
Large organizations whose application portfolios are spread across multiple business units or teams may also have centralized security teams. These teams are tasked with open source risk management. But often they don’t have access to the build system for every application. In other cases, they don’t have permission to view or analyze sensitive source code.
In both cases, the security team must be able to scan binary code. With a binary code analysis tool, they can detect open source vulnerabilities without access to the build environment or the source code.
We’ve seen many more use cases where binary code scanning is a critical part of open source management. So when you’re thinking about open source management tools, consider whether a tool can scan binary code both as part of the build process and outside it.