Supply-Chain Risk and Software Dependencies

A software supply-chain attack exploits the trust relationships between an organisation and the external components it incorporates into its own systems. The attacker does not need to breach the target organisation's perimeter directly; instead, they compromise something the organisation already trusts and uses. There are four main attack vectors, and understanding them shapes how controls are designed.

The SolarWinds attack is instructive because the backdoor was inserted into the build environment rather than the source repository itself. The resulting binary was code-signed by SolarWinds, which meant standard integrity controls such as signature verification provided no protection. This attack vector, targeting the build and delivery pipeline rather than the code, is addressed by controls in the SLSA (Supply-chain Levels for Software Artefacts) framework published by Google and now maintained by the OpenSSF.

Log4Shell demonstrated a different mechanism: a vulnerability in a transitive dependency. Log4j was embedded in thousands of products and services, often without the vendors knowing it was present. The absence of component inventory made rapid response nearly impossible for many organisations. Those with current SBOMs could query them immediately to determine exposure; those without faced days of manual investigation.

An SBOM is a formal record of every software component in a product: the component name, version, supplier, unique identifier, dependency relationships, and licence. It functions as the software equivalent of an ingredient list on a food package. When a vulnerability is disclosed in a component, an organisation with an accurate SBOM can determine within minutes whether it is exposed; an organisation without one may take days or weeks.

Two SBOM formats have emerged as standards. SPDX (Software Package Data Exchange), published as ISO/IEC 5962:2021, originated in the Linux Foundation and is widely used in open-source tooling. CycloneDX, maintained by OWASP, has gained significant adoption in commercial security tooling and is particularly strong for vulnerability tracking because it integrates directly with vulnerability disclosure formats. Both formats are machine-readable (JSON, XML, or tag-value) and can be generated automatically by SCA tools during the build process.

NTIA (US National Telecommunications and Information Administration) identified seven minimum data fields for an SBOM: supplier name, component name, version, other unique identifiers, dependency relationships, author of the SBOM data, and timestamp. Beyond these minimums, effective SBOMs include cryptographic hashes of components (to verify integrity), licence identifiers (for compliance), and a pedigree field tracing how the component was obtained. SBOMs should be machine-readable, automatically generated as part of the build process, and updated on every release rather than maintained manually.

The auditor assessing supply-chain risk evaluates whether the organisation has implemented controls across the full lifecycle of a software dependency: selection and approval, ongoing monitoring, and incident response. Controls fall into four categories.

Software Composition Analysis (SCA) integrated into CI/CD is the primary automated detective control. SCA tools such as OWASP Dependency-Check, Snyk, Black Duck, or GitHub Dependabot scan build manifests (package.json, requirements.txt, pom.xml, go.mod) and container image layers, match identified components against vulnerability databases including the NVD (National Vulnerability Database), OSV, and vendor-specific advisory feeds, and report findings with CVSS severity scores. Audit evidence should include scan results, defect tracking integration showing how findings are actioned, and SLA metrics for remediation time by severity.

Dependency pinning and integrity verification are preventive controls. Pinning specifies exact versions of dependencies (rather than accepting any compatible version) so that updates cannot be introduced without a deliberate change. Lockfiles in npm (package-lock.json), Python (poetry.lock), and Go (go.sum) serve this purpose. Subresource Integrity (SRI) checks on CDN-hosted assets extend the same principle to the browser. Cryptographic verification of packages via package-manager trust chains or cosign-signed artefacts addresses the build-pipeline attack vector.

Open-source component governance policies define which packages may be used, from which registries, and under which licence types. Many organisations maintain an approved component list and require security review before new open-source libraries are added to a project. Automated policy enforcement via SCA tooling can block builds that include unapproved packages or components with vulnerabilities above a defined severity threshold.

Supply-chain security controls appear across the major frameworks, but each frames the requirement differently. Understanding the mapping helps auditors assess against whichever framework applies to their engagement and helps practitioners satisfy multiple requirements with a single control implementation.

For organisations pursuing ISO 27001 certification, the supply-chain controls in Annex A are often under-evidenced. Auditors frequently find that organisations have supplier contracts but have not specified information security requirements in those contracts in the way A.5.20 requires, or that they monitor service-level metrics but not security-specific indicators such as patch cadence, incident notification obligations, or SBOM update schedules. The ISMS Scope and Implementation topic covers how to incorporate supply-chain risk into the ISMS boundary definition.

Software supply-chain risk is a subset of the broader third-party risk programme. A mature programme addresses vendor risk across the full lifecycle: pre-procurement due diligence, contract security requirements, onboarding controls, ongoing monitoring, and off-boarding. Supply-chain-specific additions to each phase are well-defined and auditable.

Pre-procurement due diligence for software vendors should include a review of the vendor's SBOM (or confirmation that one can be provided), their vulnerability disclosure and patch policy, their secure software development lifecycle (S-SDLC) practices, whether they hold relevant certifications such as ISO 27001 or SOC 2 Type II, and whether they have experienced supply-chain incidents in the past and how they responded. Vendors who cannot provide basic transparency about their software components are a higher risk category and should be treated accordingly.

Contract security requirements for software suppliers should specify: minimum patch turnaround times by severity class, an obligation to notify the customer of supply-chain incidents that affect components delivered under the contract, the right to audit the supplier's SBOM and secure development practices, and obligations on the supplier to flow down equivalent requirements to their own sub-suppliers. These flow-down requirements address the 'fourth-party risk' problem: a vendor who is themselves compliant but who relies on sub-suppliers who are not.

Ongoing monitoring should include automated alerts from SCA tooling when new CVEs are published against components in use, periodic SBOM refresh requests from key vendors, and review of vendor security advisories and incident notifications. Where a vendor participates in a sector-specific information sharing arrangement such as the US FS-ISAC (Financial Services), UK NCSC early warning service, or India's CERT-In advisory feeds, monitoring can be partially delegated to those channels.

Supply-chain compromises have distinctive characteristics that standard incident-response playbooks often do not account for. The organisation may be a victim rather than the initial target, the scope of exposure may be uncertain for days, and the remediation action (removing or patching a component) may require coordinated action across dozens of applications and teams. Incident-response preparedness for supply-chain scenarios is a specific audit area.

When a supply-chain compromise is disclosed, the immediate question is: are we affected? Without an SBOM or SCA tooling, answering that question requires manual inventory work across every application. With an SBOM and tooling, the question can be answered in minutes by querying the component inventory for the affected package and version. The Log4Shell response in December 2021 illustrated this difference sharply: organisations with mature SCA practices could assess and begin remediation within hours, while others were still discovering affected systems weeks later.

The incident-response plan should include supply-chain-specific playbooks covering: how to rapidly assess exposure using the SBOM, who has authority to approve emergency dependency updates outside the normal change management process, how to coordinate with the affected vendor and with sector peers through information-sharing channels, and how to communicate to customers if the compromise affects software or services the organisation delivers to others. See the Incident Response and Management subject for detailed coverage of those planning and execution disciplines.