A software Bill of Materials or SBOM provides transparency into an organization’s software, protecting it from supply chain risks.
Just because the component you add to your application is secure today doesn’t mean that the application will still be secure tomorrow. That’s due in large part to the complexity of the software supply chain: the mix of proprietary and open source code, APIs and user interfaces, application behavior, and deployment workflows that go into building software applications. For enterprises developing software, security issues at any point along this chain, at any time, can put your organization and your customers at risk. How can you ensure your software supply chain is secure, and prove it?
Codebase and supply chain security risk
A flaw anywhere in the supply chain cascades out from the point of origin of the vulnerability or breach, sometimes all the way to the end user, and it has the potential to have devastating impacts. Because of its complexity and connectivity, the software supply chain presents an ever-expanding attack surface. For example, threat actors can take advantage of compromised software and the frequent communication across networks to get privileged access to networks and organizations. That enables these bad actors to bypass perimeter security and appear as legitimate users or accounts, and once inside—and with permissions—they can wreak havoc.
Do you know the composition of the software in your applications—including both open source and proprietary code? Do you know which components and versions they use? Open source software is everywhere; it’s a critical component in all modern application development. Our analysis of commercial codebases in the Synopsys “Open Source Security and Risk Analysis” (OSSRA) report shows that almost all (98%) codebases contain open source software. And that number is 100% in the energy and clean tech, cybersecurity, Internet of Things, and computer hardware and semiconductor industries. The report also shows that 81% of codebases contain at least one known open source vulnerability.
As a result of the prevalence of open source software, the supply chain is more complicated and obscure, and involves more links and dependencies than ever before. The only way to mitigate the risk is to maintain visibility into the open source software in use, and address the areas of risk as they are identified.
Additionally, your proprietary code is written by developers, who tend to not have much security experience or training. Similar to open source software, the risks of proprietary code are complex and can be difficult to identify, even by seasoned security experts. However, these vulnerabilities in your own code can serve as entry points to sensitive data and systems. This is why it’s so important to secure proprietary software alongside third-party code in an application.
Software supply chain attacks
Hackers are increasingly targeting the supply chain because there is a high return on investment. And because hackers are getting what they want, these attacks are becoming more mainstream. Gartner predicts that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chain. And because of the dependencies and connectivity, flaws and vulnerabilities in applications create risk for organizations several degrees away from the initial attack vector. Some example of this include
SolarWinds. In 2019, hackers inserted malicious code into the SolarWinds Orion platform, an IT monitoring system used by more than 30,000 organizations around the world. The code created a backdoor into thousands of systems, and the systems connected to those systems, giving the hacker access to accounts and users without detection. Victims included many organizations and U.S. government departments.
Heartbleed. In 2014, a bug in the widely used OpenSSL encryption software tricked computers into transmitting the content of a server’s RAM, giving the hackers access to data including passwords and personally identifiable information. Any company using OpenSSL was at risk, including Google, Dropbox, Reddit, Facebook, the Canadian Revenue Agency, along with many gaming services and numerous smaller entities.
Equifax. In 2017, hackers got into Equifax through its customer complaint portal, using a known vulnerability in the Apache Struts framework that had not been patched yet.
Log4J. In December 2021, a critical vulnerability was identified in one of the most popular open source components, Apache Log4J, which can affect Java-based enterprise applications, embedded systems, and their subcomponents. It is also a dependency in more than 7,000 other open source projects. The vulnerability allowed attackers to execute arbitrary code on vulnerable servers, which made it dangerous enough to earn the highest score possible on the NVD CVSS severity scale—a 10 out of 10. Although not a specific attack, it’s nevertheless a clear example of the software supply chain risk facing organizations around the world.
Building trust with a software Bill of Materials
The way to secure the software supply chain and build trust with your customers and suppliers is to take a proactive approach to securing the software supply chain with a software Bill of Materials (SBOM). An SBOM, often generated by a software composition analysis tool, is a comprehensive inventory of the components used to make up a piece of software. It lists all the open source and proprietary code, associated licenses, versions in use, and patch status. A more complete SBOM also includes download locations for components and dependencies, and any subdependencies the dependencies link to. The specific items and amount of detail included in an SBOM depend on the organization and its clients and partners, any relevant regulatory agencies, and what information they need. This data is intended to be shared across companies and communities, to enable other organizations to create their own complete software Bill of Materials.