Business services depend on software the organisation did not write. Commercial products, open-source components and the software suppliers use to handle the organisation's data are built and updated by others, and each reaches the organisation's systems or data with trust it has been granted. When that trust is abused, or a supplier's update fails, the consequences fall on the organisation's own services, customers and data. Overseeing that dependency is part of the management body's responsibility for cyber risk.
Four areas of exposure
The exposure falls into four overlapping areas, each with its own implication for oversight.
Trusted updates can interrupt operations. In July 2024 a faulty CrowdStrike update caused widespread outages across Windows systems that depended on it. Oversight therefore covers which suppliers can push updates to critical systems and how a failed update would be contained.
Hidden components complicate exposure assessment. In 2021 a serious vulnerability, known as Log4Shell, was found in a widely used logging library. Organisations had to find every place that library was running, including inside their suppliers' products and in software that had included it without their knowledge. How quickly that question can be answered depends on dependency records kept before a vulnerability is announced.
Build environments need protection. In 2020 attackers compromised the SolarWinds build system and distributed malicious code through signed updates to its Orion software. A valid digital signature can accompany malicious software when the supplier's build or signing process has been compromised.
Software operated by suppliers can expose the organisation's data. In 2023 attackers exploited a flaw in the MOVEit file-transfer product and took data belonging to organisations whose suppliers used it to process that data. Oversight therefore extends to the software suppliers use to handle the organisation's data.
What leadership should require
Software supply chain risk crosses technology, procurement and the business owners of the services that depend on the software. A named owner holds it across those functions, with authority to set supplier requirements and to escalate material dependencies to the board. The accountable owner should establish the organisation's applicable obligations, translate them into requirements for suppliers and internal development, and obtain evidence that those requirements are being met.
For each critical service, leadership needs a maintained dependency record connected to the versions actually deployed and to supplier information. A software bill of materials helps identify potentially affected components when a vulnerability is disclosed, and technical assessment then establishes whether a deployed service is vulnerable or exploitable. Supplier contracts set security obligations, require prompt notification of incidents and vulnerabilities, and give the organisation a right to evidence.
Where the organisation controls the timing of updates, staged rollout reduces the potential spread of a defective one. Where a supplier pushes updates directly, the board should know which suppliers hold that position. For those suppliers, leadership needs evidence of release testing, deployment controls and arrangements for containing a failed update. In both cases, tested rollback, recovery and continuity arrangements determine how quickly critical services return if an update or compromise takes them down. Where the organisation builds software, leadership needs assurance that changes to code, build systems and released software are authorised, traceable and protected against tampering.
Questions for the board
- Who owns software supply chain risk across technology, procurement and business services?
- Which suppliers and components do our critical services depend on, and how current is that record?
- When a vulnerability like Log4Shell is disclosed, how quickly can we establish whether we are exposed?
- Which suppliers can push updates directly to critical systems, and what controls apply?
- What do our contracts require of software suppliers on security, notification and evidence?
- Where we build software, what assurance do we have that the build and release process is protected against unauthorised changes?
- How would critical services recover if a supplier update or compromise made them unavailable?
- Which material dependencies require investment, an alternative arrangement or explicit risk acceptance?
A Critical Supplier Cyber Risk Review establishes which supplier relationships carry material cyber risk, where concentration sits, and what the contracts and due diligence need to change.
References
- Microsoft, Helping our customers through the CrowdStrike outage, 20 July 2024.
- Apache Software Foundation, Apache Log4j security vulnerabilities (CVE-2021-44228), December 2021.
- SolarWinds, New findings from our investigation of SUNBURST, January 2021.
- Progress Software, MOVEit Transfer and MOVEit Cloud vulnerability statements, 2023.
- National Institute of Standards and Technology, Special Publication 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines, February 2024.