Dependencies of Dependencies: The Critical Challenge of Managing Software Supply Chain Risk
Table Of Contents:
Software runs the world. It keeps aircraft in the sky, hospitals running and ensures the global financial system never misses a beat. But increasingly, these applications are built using open-source code components from various disparate sources. Complexity is the new normal, whether it’s proprietary software or bespoke homegrown apps. And complexity is the enemy of security.
The complex relationships between components, and the ease with which threat actors can insert malware into upstream code, should be a cause of concern to security managers. Wake-up calls have come thick and fast over recent years. It’s time to find an effective way to manage software supply chain risk.
How the Software Supply Chain Works
Supply chains are the critical pathways via which raw materials and components are directed before being assembled, sold and used. In the digital world, such components are often better thought of as services provided from supplier to client. As we discussed in a previous article, these service providers are an increasingly popular target for attack because threat actors can generate a good RoI. Attack one business process outsourcer or IT services giant, and they have the opportunity to steal data from and/or extort a potentially large pool of downstream customers.
A software supply chain is similar, but in this case, the system comprises the components, code libraries, tools and processes required to build software. By compromising a single component, or even an entire application, attackers can potentially impact any developer or organisation using that software/component.
Where’s the Risk?
Software may be running the world, but what exactly goes into building the applications that power everything from e-commerce platforms to critical business ERP systems? Increasingly it is open source components. A Sonatype report estimates that in 2022 alone, developers made 3.1 trillion requests for such components from the top four open-source ecosystems: Java, JavaScript, Python and .NET. The draw is that by downloading these pre-built packages, developers can accelerate time-to-market and help the business respond more quickly to fast-changing market demand. It’s claimed that 80% of code in modern applications comes from pre-existing open-source software.
The challenge is that these components—or open-source “dependencies”—often contain vulnerabilities. According to Sonatype, 1.2 billion vulnerable dependencies were downloaded every month last year. If unwittingly downloaded, they could introduce the risk of being exploited by threat actors at a later date. According to the Linux Foundation, the average application development project contains 49 vulnerabilities across 80 direct dependencies.
Even worse are indirect or transitive dependencies, which Sonatype claims account for six in every seven project vulnerabilities. These dependencies are harder to track, as they’re effectively the libraries and packages that direct dependencies call—in other words, dependencies of dependencies. As a result, it’s not immediately obvious a particular application is using them. That can hide vulnerabilities under an additional layer of obfuscation.
A case in point is the infamous Log4j vulnerabilities. Log4j is a little-known but popular logging tool used by over 35,000 Java software packages. A patch for a critical (CVSSS 10.0) vulnerability in the tool was released in late December 2021. But because of its widespread use across the Java open-source ecosystem, it was extremely difficult for many organisations to definitively find and patch all instances of Log4j in their environment. According to Google, most impacted Java packages were vulnerable because Log4j was a hard-to-find transitive dependency.
“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed,” it added.
Unfortunately, threat actors wasted no time in exploiting the bug. According to Verizon, a third (32%) of scanning for the vulnerability in exposed systems last year came during the first 30 days after its publication.
Alongside the challenge of finding and patching vulnerabilities in open-source components, organisations have the additional headache of malicious packages posted to open-source repositories by threat actors. Sonatype claims to have recorded a 633% annual increase in such packages in 2022, to over 88,000 known instances.
Another Threat: Proprietary Software
However, software supply chain risk is not limited to open source. Proprietary commercial products may contain vulnerabilities which attacks could exploit and regularly are. They may also include buggy open-source components and tools, like Log4j. In fact, very little code that exists today can genuinely be described as “proprietary”, according to Sonatype director of developer advocacy, Steve Poole.
“As a result, consumers of seemingly proprietary applications have a false sense of security, and thus can be unknowingly vulnerable,” he tells ISMS.online.
In more sophisticated attacks, such as the SolarWinds campaign, threat actors can even compromise the vendor’s own IT environment and insert malware in legitimate software updates. This enabled Russian state operatives to compromise several US government departments.
“Any kind of software can be compromised. The main problem is an unjustified implicit trust in that software,” argues Udo Schneider, security evangelist Europe at Trend Micro.
Samuel Barfoot, security team leader at Checkmarx, says the maturity of the software vendor and ISO accreditation is vital.
“While the software itself may not be designed to cause harm, if it is infiltrated, it can be used to leak information,” he tells ISMS.online. “When moving to the cloud, organisations also face risks related to vendor controls, support, backups and system availability in the event of a hack or outage. The maturity of the vendor is crucial in mitigating these risks through preparedness and provisions.”
Visibility is the First Step Towards Managing Risk
Whether dealing with proprietary or open-source code, organisations wanting to mitigate risk in the software supply chain must first gain insight into “bad” components and subcomponents, according to Trend Micro’s Schneider. This can be achieved by requesting a software bill of materials (SBOM).
“An SBOM for a software artefact (library, executable or even container) contains a dependency graph where all software (sub-)components used are listed, including an exact version number. SBOMs can be generated directly from source within a CI/CD pipeline or later on ‘dead’ artefacts such as executables or even containers,” he explains.
“This is particularly helpful for proprietary software where the vendor usually does not provide SBOMs. In jurisdictions/verticals where vendors must provide an SBOM, they can be continuously checked against known vulnerabilities, providing an up-to-date basis for possible action.”
Sonatype’s Poole adds that organisations should also assess vendor security posture, paying particular attention to the quality of their vulnerability reporting processes.
For open source components, organisations should run a programme of continuous evaluation of open source components, patching/updating promptly where necessary to head off rapid exploitation, he argues. Software Composition Analysis (SCA) tools can also help by discovering what’s inside products or components.
“However, the sophistication of the SCA tool must match and exceed that of the bad actors, or the organisation faces the real risk of an attack via an undetected vector,” he warns.
“Finally, bring developers into the fold by educating them on how modern cyber-attacks happen, and what secure coding principles are, and teach them about their responsibilities at the beginning of the software supply chain—their immediate choices and actions have consequences.”
Start With an ISMS
Trend Micro’s Schneider argues that an information security management system (ISMS) can be a great way to mitigate software supply chain risk on an ongoing basis.
“By feeding data from SBOM tools, enriched with distribution data, into an ISMS, it is possible to assess better and document the security posture and therefore the overall risk of the entire system, of which software is only one part,” he explains. “When used as a basis for mitigating risk and documenting the actions taken, this, in principle, provides far better security than manual tracking of software assets.”
A Checklist for Managing Software Supply Chain Risk:
- Request an SBOM
- Assess proprietary software vendors (especially their vulnerability reporting)
- Use SCA tools to gain insight into software components
- Continuously scan for vulnerabilities and patch promptly
- Educate developers about the importance of security by design
- Consider feeding SBOM data into an ISMS for holistic risk management
Find out how the ISMS.online solution enables a simple, secure and sustainable approach to supply chain risk management and information management with ISO 27001 and over 100 other global frameworks.
