COMMENTARY: We hear the phrase “the world runs on open source” often. And while it’s true and a lot of software in the world runs on open source, many enterprises don’t. The vast majority of enterprises run on commercial software, and for good reason: Companies want an organization that stands behind their ERP and other mission-critical software, one that will support, extend, and patch it.
But how do organizations gain assurance that it’s truly safe and secure? They can't always do it.
The SolarWinds, 3CX, CircleCi, Kaseya, and Ivanti security breaches contradict the notion that open source software rules. Even if we go back to one of the original breaches that put software supply chain security on our radar such as NotPetya, that involved Ukranian tax software called MeDoc, which was commercial software.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
All of these incidents were caused by software supply chain issues in commercial software, not open source, and the problem has grown. Breaches associated with third-party software development organizations were responsible for 15% of data breaches—a 68% increase over the previous year, according to the 2024 Verizon Data Breach Investigations Report.
Gartner recently reported that software supply chain attack costs will rise from $46 billion in 2023 to $138 billion by 2031, a 200% increase. These attacks include both proprietary and commercial code — presenting a critical risk and compliance issue. Those risks have led to attacks that have had devastating financial, operational, and reputational impacts for both software vendors and their enterprise customers. Unfortunately for CISOs, while it’s someone else’s software, it’s still their company’s outcome.
Every enterprise has a process in place for dealing with open source, but the process for commercial software is completely different. It’s based on trust, vendor assertions in response to questionnaires, security scores, and vendor-provided lists of the components that go into the software. Those have proven inadequate.
The tools many use to ensure that their open source code remains secure, such as software composition analysis (SCA), and static and dynamic application security testing (SAST/DAST), are useless when it comes to commercial software. The underlying code often consists of a mix of proprietary, third-party and open source software libraries that form the vendor’s software supply chain, but there’s little visibility into the source code, so teams can’t see what went into the executable they are running.
Does it contain malware? Has it been tampered with? Is it cryptographically sound? Does the version of one of the software elements contain known CVEs? Has the binary been hardened with the appropriate security measures? Does it contain sensitive information? Perhaps there's a component that’s communicating with an undocumented large language model hosted in a part of the world that’s undesirable to the business. If it does exist, the team won’t know it.
Even antivirus software doesn’t always protect against software supply chain attacks. Just consider the wave of recent software supply chain attacks noted in our report, which found that incidents of malicious packages found on popular open-source package managers have increased dramatically over the past three years. Despite that, the software industry still hasn’t woken up to the changing landscape of software supply chain security threats. Loose development practices and inattention to software supply chain risks persist.
At the same time, commercial software has become a black box for organizations, which means they must rely on tools such as questionnaires for reassurance. Questionnaires from organizations such as the Cybersecurity and Infrastructure Security Agency offer limited, point-in-time assertions, but they are not always accurate or tell the whole story. For example, Ford’s “credit score” has little or nothing to do with whether its cars run safe on the road.
SBOMs offer a “list of ingredients” of what went into the software, and it’s a great first step. But SBOMs don’t offer the recipe for how those ingredients work. They can’t tell teams what risks those individual components might present; the team as to investigate that themselves. Extracting useful security information from SBOMs is a manual, time-consuming process that requires identifying each component and manually constructing context to determine, for example, if there are any known CVEs. That’s about the best the team can hope for with the data it receives from SBOMs.
But in the real world, even that’s not always practical because large companies may deal with SBOMs for thousands of software programs, each containing hundreds, if not thousands, of libraries. Even a small application may contain hundreds of libraries, and for large enterprise programs, it’s often 10,000 or more. Even if we could review all of those SBOMs we still couldn’t tell if the code has been tampered with or contains malware.
SBOMs offer greater transparency into the software supply chain, but they don’t in themselves make the software more secure.
The risks from insecure software today fall more than ever on the CISO. The standard of due care has shifted from “did you know” to “should you have known and did you implement appropriate controls to have known,” akin to Sarbanes-Oxley in the financial world. This scares the many CISOs I’ve spoken to over the last year because when a breach occurs they can find themselves brought up in front of the SEC or other agencies and face potential fines — even jail time.
So what can CISOs do about it? Given where all of the breaches today are happening, CISOs can’t just trust that their commercial packages are secure. CISOs need technical controls they can use to ensure that the commercial software they’re using is safe. They need to identify all components in the vendor’s software supply chain, analyze all of them, and determine whether any of those present risks. Trust isn’t enough — we need new controls. Only when the team knows not just what the components are, but how they’re used and what they’re doing, can we protect the organization against hidden software supply chain threats. It’s time for controls that let CISOs buy safe, build safe, and stay safe.
Saša Zdjelar, chief trust officer, ReversingLabs
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
