The concept of software supply chain security (SSCS) has taken center stage over the past few years in the wake of new federal policies, increases in the threats to open-source platforms, and the continuing struggles to patch critical vulnerabilities. However, one of the most under-addressed areas of SSCS is commercial software security.
This issue was highlighted in Verizon Business’ 2024 Data Breach Investigation Report (DBIR), which found a 68% increase in breaches stemming from third-party software development when compared to the 2023 DBIR. This increase, in conjunction with several high-profile commercial software attacks in recent years, including SolarWinds, 3CX, and Kaseya, means enterprises need to comprehensively audit their commercial software use for SSCS threats, ReversingLabs chief trust officer Saša Zdjelar said in a recent episode of "The Cyber Ranch Podcast."
Speaking with hosts Allan Alford, the CEO of Alford and Adams Consulting, and Drew Simonis, the CISO of Juniper Networks, Zdjelar called on enterprise security and risk teams to rethink everything from procurement to deployment in order to address the growing threat of software supply chain compromises.
Here are key takeaways from the security leader discussion.
[ Hear the Podcast: What Is In Your Commercial Software? with Saša Zdjelar ]
Commercial software: A black box for organizations
Zdjelar said that much of the conversation about SSCS has focused on the risks lurking within open-source software packages and efforts by cybercriminals and nation-state actors to leverage open source code and platforms to their advantage.
That is understandable — statistics have shown that open-source software can be found in the vast majority of enterprise applications, helping to speed development of critical applications and services. But, as Zdjelar noted during the podcast, enterprises actually run on closed-source, commercial software.
“I hear ..., ‘The world runs on open source.' Yeah, but your company doesn't. Your ERP systems, your order to cash, your hire to retire, your treasury management — whatever they are, they're all commercial tools, for very good reasons. ... It’s just complete fantasy that open source is what runs companies."
—Saša Zdjelar
Those "very good reasons" include superior feature sets, more timely updates, and better support — factors that are critical for enterprises and organizations in both the private and public sectors.
But practitioners of application security (AppSec) are trying to spot supply chain risks with technologies and tools such as software composition analysis (CSA) and static application security testing (SAST), both of which demand that customers have access to raw source code. That works for open-source software, but not commercial software.
CISOs: The standard of due care has shifted
Zdjelar noted to Alford and Simonis that the expectations placed upon CISOs have shifted. It was common in the past for CISOs and other executives to turn a blind eye to ambiguous security concerns and threats in the interest of maintaining smooth operations. But that changed with new U.S. Securities and Exchange Commission rules on cybersecurity material disclosure and the commission’s subsequent case against SolarWinds and its CISO.
“The standard of due care is no longer ‘Did you know?’ It’s ‘Should you have known?'”
–Saša Zdjelar
Questionnaires miss the mark
Auditing commercial software requires processes and tools that can spot the kinds of threats that cause major attacks such as the one on SolarWinds. However, Zdjelar pointed out that the vast majority of security and risk management teams within enterprises are missing the mark in spotting these threats because they currently rely on outdated third-party cyber-risk management (TPCRM) tools such as security questionnaires — static lists of questions pertaining to the software product’s security. This process is one that’s dependent on the software vendor being truthful and transparent about its product’s security — something CISOs no longer can afford to count on.
“The reality ultimately is that [questionnaires are] the only control that CISOs have had until recently.”
–Saša Zdjelar
Simonis added that such questionnaires “encourage deceit” on the part of software vendors and leave no way for CISOs to verify the product’s security.
The SBOM's limitations: An ingredients list isn’t a recipe for success
More recently, questionnaires have been supplemented by software bills of materials (SBOMs), a type of ingredients list for what can be found in a software package, whether that's open-source components, proprietary code, or third-party code. Unlike questionnaires, they can be quickly and automatically generated and distributed to customers by software producers.
Today, SBOMs are being promoted by both industry leaders and federal agencies, and their adoption by enterprises is increasing. But an ingredients list isn't a recipe, and SBOMs — while an important first step — do not completely secure enterprise software supply chains on their own, Zdjelar said.
“At ReversingLabs, we think that, directionally, [SBOM adoption] is the right thing to do. We just think it falls way short of being something that can actually be operationalized and utilized.”
–Saša Zdjelar
Zdjelar said he believes SBOMs fail to provide the comprehensive coverage that enterprises need because they omit the context for how components are being used. This context is needed to assess whether a software product contains malware, malicious tampering, secrets exposure, or other elements that could be used to carry out a commercial software supply chain attack.
A new control point for the enterprise
Zdjelar said CISOs and their teams need to run a comprehensive risk assessment to fill in the gaps of SBOMs and security questionnaires, which would allow them to verify the amount of risk a product might bring to the organization. But how can they do that without getting access to the source code of the commercial application they wish to vet? That Catch-22 leaves CISOs with no way to weigh risks beyond an SBOM and a questionnaire because they can’t identify what kinds of software supply chain risk are lurking in the commercial software product their enterprise uses.
Fortunately, as Alford mentioned, ReversingLabs' Spectra Assure software supply chain security solution is able to provide this kind of comprehensive risk assessment — without the need for source code.
“Honestly, I was shocked when I found out you existed in what you did.”
–Allan Alford
Spectra Assure is able to run a comprehensive risk assessment on any kind of commercial software product. It includes a machine-readable SBOM and provides a SAFE Report that spots malware insertion, malicious tampering, file rot, secrets exposure, and other software supply chain risks that SBOMs and questionnaires can’t pinpoint. Powered by AI-driven complex binary analysis, Spectra Assure does not require the application’s source code to identify these risks.
To hear more from Zdjelar on the situation CISOs are facing in regard to SSCS, how legacy application security testing methods aren’t enough, and why Spectra Assure is an asset to today’s CISOs, listen to the latest episode of "The Cyber Ranch Podcast" here or wherever you get your podcasts.
