Cyber Crime
Assessing and protecting the technology supply chain – Pt II
Software runs the world. It’s keeps planes in the sky, and hospitals operational. It keeps us entertained at home and productive at work. This ubiquity also makes it a key factor when we come to assess technology supply chain risk. Because no software “product” today is a monolithic block of code. It is an assemblage of disparate parts. And each of these building blocks could introduce new risk.
Save to Folio
The first step towards mitigating this risk, is understanding where it is.
Dependencies of dependencies
Virtually no application is developed without reliance on third-party commercial and open source libraries. Yet the use of these external assets (known as dependencies) can introduce challenges if they also contain vulnerabilities or malicious code. Even worse, these dependencies also have dependencies (known as transient dependencies) which are often harder to spot. This can in turn hide any vulnerabilities that they may introduce.
This is a problem, because a vulnerability in any dependency or transitive dependency could make the application that relies on that dependency vulnerable. This includes vulnerabilities that become known long after the release, through no fault of the developer. The best-known example is a bug in Log4j, a widely used logging framework for Java, which was published and almost immediately exploited. Because Log4j was used by more than 35,000 Java software packages, it enabled remote code execution in a huge range of Java applications.
Another illustration of the complexity of the software supply chain is Docker containers. From a supply chain perspective, they are merely a packaging format for software. But from a dependency perspective, they contain a multitude of third-party applications, packages, OS tools, container overlays and other artefacts. And as with direct library dependencies, a vulnerability in one of these components could compromise the entire application. At this point, you're looking at a dependency tree of unimaginable size.
According to one report, 1.2 billion vulnerable dependencies were downloaded every month last year, with transitive dependencies accounting for six in every seven project vulnerabilities.
Gaining visibility and control
The first step to mitigating risk in such massive dependency trees is to gain visibility. Due to the volume of components and the complexity of the data, this must be done in an automated fashion. Like bills of materials in the physical world, software bills of materials (SBOMs) are gaining traction in IT as a way to keep track of dependencies.
These are created automatically—ideally within the CI/CD pipeline, as this is the only place where dependency information is fully available. If this is not possible (e.g. with third-party software or containers), it is still possible to extract SBOM information from the "dead" software artefact. In this case, certain dependency information may no longer be visible, although it’s better than nothing. While commercial software vendors are currently reluctant to provide SBOMs, it is likely that they will become standard, especially for deployment in critical environments. In the US, a Presidential Executive Order already contains legal requirements to do so for vendors supplying the government sector.
One caveat is that SBOMs are only accurate for the “locked” version of dependencies, so even small version changes can render SBOM information virtually worthless. This is not a problem for programming languages and package managers. It’s more challenging for Docker files and Kubernetes manifests, but not insurmountably so.
Once the SBOM has provided visibility into dependencies, the organisation must continuously validate them against known vulnerabilities. OWASP's DependencyTrack is one of the best known open source tools for this purpose. Thus, when the next Log4J incident emerges, organisations will be able to tell at a glance where and how they are affected, for a wide range of products and versions.
Towards DevSecOps
The complexity of software supply chains threatens to outpace the ability of organisations to manage risk in them. But although they nominally expand the attack surface, SBOMs and automated vulnerability checks offer a useful response. The key for security teams will be to embed such knowledge and processes in development lifecycles, via DevSecOps. Log4j showed that the worst-case scenario can sometimes become reality.
Stay tuned for the third part in this mini-series where we’ll be looking at attacks on customers and suppliers.