If software supply chains consisted solely of open source code, securing them would be easy. Effective tools and methodologies exist for discovering and remediating software supply chain security risks that arise from open source components.
But supply chains also can, and typically do, contain closed-source code derived from third-party sources. Securing this part of the supply chain often proves much more challenging because software supply chain security tools often don’t focus on closed-source code. When you add software-as-a-service (SaaS) apps to the mix, securing the supply chain becomes even more complicated.
These challenges can be solved, but they require a more extensive approach to software supply chain security than some businesses take. Here’s why securing open source alone is not enough and how organizations can do better.
The three categories of software supply chains
Broadly speaking, three types of software can exist within a software supply chain (which means the set of third-party software resources a business uses):
- Open source libraries, modules, and other code that developers integrate into applications they build or leverage as dependencies
- Closed-source products from external vendors that businesses deploy and manage on their infrastructure
- SaaS applications that are developed, hosted, and managed by an external vendor but used by the business
Most organizations use a combination of these types of software resources. For example, IDC found that 66.7% of businesses identified open source as “critical” or “important” to their organizations (IDC’s Five Open Source Software Themes to Embrace, November 2023). At the same time, approximately one-third of businesses depend on SaaS applications to power core business functions, a figure that IDC expects to rise over time (IDC’s SaaSPath 2023 Executive Summary: Examining the SaaS Buyer’s Journey, June 2023). Other business functions are likely addressed using third-party closed-source applications that organizations operate themselves, since few companies build business software totally from scratch.
The awkward role of closed-source code in supply chain security
Despite the diverse types of software that exist in most supply chains, software supply chain security tools and strategies have tended to focus largely on risks associated with open source.
For example, a key category of software supply chain security tooling is software composition analysis (SCA). Typically, SCA solutions work by scanning applications to identify components that resemble open source code, then flagging any such components that are subject to known security vulnerabilities. This approach doesn’t work well for uncovering flaws linked to closed-source code because that code is secret. As a result, SCA scanners cannot typically identify vulnerable closed-source components unless they have access to private code repositories and vulnerability databases — which is very rarely the case.
Likewise, creating a software bill of materials (SBOM), which tracks third-party software components and dependency, has become a best practice for securing the software supply chain. But SBOMs are designed mainly to catalog open source software. Documenting closed-source components using SBOMs may be technically possible, but many of the assumptions made by SBOM formatting standards don’t make sense in the context of closed-source code. As a result, few SBOMs track closed-source components.
In short, third-party closed-source code fits awkwardly, at best, within modern approaches to software supply chain security. Given the lack of effective tools and tracking methods, it is easy for businesses to neglect this part of their supply chains.
Why closed-source and SaaS apps must be tracked
Such oversights can result in enormous risks. Some of the highest-profile software supply chain attacks to date — like the SolarWinds breach — have involved closed-source code, not open source products. When incidents like these occur, businesses that fail to track which third-party closed-source apps they use risk not knowing that they are vulnerable or being able to confirm that patches have been installed.
On balance, it’s worth noting that the risk surrounding closed-source security vulnerabilities are a bit different from open source flaws. With closed-source apps, it’s more likely that a vendor will automatically install a patch — although this doesn’t necessarily happen. In addition, because open source vulnerabilities are publicly documented, and sometimes accompanied by exploit code, it’s relatively easy for threat actors to take advantage of them. Exploiting vulnerabilities in closed-source code can be more challenging because information about them is often not as readily available.
But just because closed-source apps are somewhat less ripe for attack in certain respects doesn’t mean businesses can simply ignore non-open source software when securing their supply chains. The fallout of an attack against closed-source applications can be quite serious, as many businesses that were using SolarWinds circa 2020 know.
Integrating closed source into software supply chain security
Given the lack of software supply chain security tools designed for closed-source apps, how can businesses gain visibility into these resources and their potential security risks?
Part of the answer is to use enterprise architecture (EA) tools to document which applications the business has deployed. In this context, these tools can serve a purpose akin to SBOMs for open source.
Using SBOMs to track SaaS applications would also be a wise practice. The idea has been proposed, but is not currently in widespread use.
More generally, IT and cybersecurity leaders should make clear that managing third-party closed-source code within the context of supply chain security is just as much of a priority as protecting open source components. The process is complicated and not as straightforward as finding and fixing open source vulnerabilities, but it’s an imperative for businesses that want to make a comprehensive commitment to software supply chain security.
Learn more about IDC’s research for technology leaders.
International Data Corporation (IDC) is the premier global provider of market intelligence, advisory services, and events for the technology markets. IDC is a wholly owned subsidiary of International Data Group (IDG Inc.), the world’s leading tech media, data, and marketing services company. Recently voted Analyst Firm of the Year for the third consecutive time, IDC’s Technology Leader Solutions provide you with expert guidance backed by our industry-leading research and advisory services, robust leadership and development programs, and best-in-class benchmarking and sourcing intelligence data from the industry’s most experienced advisors. Contact us today to learn more.
Christopher Tozzi, an adjunct research advisor for IDC, is senior lecturer in IT and society at Rensselaer Polytechnic Institute. He is also the author of thousands of blog posts and articles for a variety of technology media sites, as well as a number of scholarly publications. Prior to pivoting to his current focus on researching and writing about technology, Christopher worked full-time as a tenured history professor and as an analyst for a San Francisco Bay area technology startup. He is also a longtime Linux geek, and he has held roles in Linux system administration. This unusual combination of “hard” technical skills with a focus on social and political matters helps Christopher think in unique ways about how technology impacts business and society.
