Most organizations do everything they can to manage third-party risks associated with their vendors, agents, resellers and partners. However, a couple of supply chain components are often left unmanaged: software applications a company purchases for use by its employees and third-party code used in applications created in-house. Until now, the digital supply chain was difficult, if not impossible, to monitor for compliance.
Many companies use hundreds or even thousands of these applications — for things like video conferencing, collaboration, enterprise resource planning and personal productivity — as well as so-called second-tier applications that are used by a select number of employees.
The growth in commercial software usage is being driven by numerous factors: digitization initiatives, software to support work-from-home requirements and the need among departments and business units for specialized software to streamline operations. This is pressuring IT departments to get a handle on their risk exposure. Especially in regulated industries like insurance, oil and gas, pharmaceuticals and financial services where both industry/government mandates and maintaining trust with customers and business partners is critical.
Vulnerabilities in commercial off-the-shelf (COTS) software have become more common with the increased use of open-source software (OSS) components as building blocks for these business applications. Hackers have recognized that they can exploit vulnerabilities in embedded OSS components to compromise widely used applications.
- Hope. Simply deploy software applications without any checks and balances, leaving security entirely up to the vendor. Although this is the least secure method, this is the most practical approach for some companies.
- Trust. A more secure approach is to require suppliers to demonstrate that they are making the best efforts to protect their software from vulnerabilities. This could include requesting documented results from their internal security tests. In this scenario, the IT department typically controls what software is deployed to what employees.
- Trust but verify. The most secure way to control the security of the software your employees use is to not only trust but also verify — by testing applications to assess whether they contain any vulnerabilities. This approach enables you to determine how much risk you are willing to accept for each application you deploy.
Since application providers typically do not share their source code, the only way to verify the security of COTS products has been via manual penetration testing. Unfortunately, penetration testing techniques have limitations. Manually testing hundreds of applications can be time-consuming, expensive and labor-intensive. In many cases, it can take weeks to validate just one piece of commercial software. During this time, a business unit might be stuck waiting for a new and presumably better application. This can undermine productivity and leave workers frustrated.
But there is a secondary problem. The effectiveness of this testing is often an open question. While the technique can detect vulnerabilities and an array of problems, it also can miss problems and lag behind changes in open-source code and the entire commercial software marketplace.
To avoid the pitfalls associated with the manual approach, several companies, including mine, have created a new class of tools that automate this process. Called binary software composition analysis (BSCA), the tools use binary analysis to identify known vulnerabilities and create a software bill of materials (SBOM).
If you and your leadership team are exploring changes to your security tools, consider the following when assessing BSCA options:
- Look for products that do not require access to source code.
- Assess whether they provide high precision and recall, which will result in fewer missed vulnerabilities and reduce false positives.
- Make sure the tool can perform binary-level analysis for both open-source software and third-party software.
- Look for the ability to inspect run-time code that is either deployed or in development.
- Determine what sources are used to monitor for vulnerabilities: open source or private? A mix of both will discover more security flaws.
Once you have scanned each application to create an SBOM, take steps to address any vulnerabilities that you discover.
As we have learned from recent cyberattacks that have been in the news, we can no longer inherently trust that our software supply chain is free from security vulnerabilities. Fortunately, advances in code testing and analysis make it possible for you to take back control over the software you use to run your business. With this visibility, you can take a proactive approach to assess and remediate security risks that may be lurking below the surface.
