Manage software supply chain risk — the risk introduced by dependencies on third-party packages and repositories

Overview

Software supply chain attacks — in which adversaries compromise a widely-used open source package, a software repository, a build tool, or an update mechanism to distribute malicious code to the large number of organizations and applications that depend on the compromised component — have become one of the most significant and most sophisticated threat vectors in enterprise cybersecurity. Unlike direct attacks against organizational systems, supply chain attacks exploit the trust that developers place in the third-party components and repositories that are integral to modern software development. The consequences of successful supply chain attacks can be severe: the SolarWinds compromise of 2020 affected thousands of organizations through a malicious update to a widely-used IT monitoring platform, demonstrating the scale of impact that a single supply chain compromise can produce.

Best Practice

Govern software supply chain risk through a combination of policy controls, technical controls, and continuous monitoring that addresses the principal supply chain attack vectors. For package integrity verification: require cryptographic signature verification for all open source packages and third-party software components before they are incorporated into builds, using the signing capabilities provided by package ecosystems and registries where available. For repository security: use vetted, internal or enterprise-grade package mirrors rather than pulling directly from public registries in production build pipelines, reducing exposure to repository-level compromises and ensuring that the packages used in builds are the packages that were reviewed and approved. For dependency version pinning: pin all dependencies to specific, verified versions in build manifests rather than accepting the latest version automatically, preventing supply chain attacks that exploit automatic update behavior to distribute malicious updates. For provenance verification: use SBOM data and provenance attestation capabilities — such as those provided by the Supply Chain Levels for Software Artifacts framework — to verify the build-time origin and integrity of software components incorporated into organizational builds. (Reference: SLSA Framework, slsa.dev, Supply Chain Levels for Software Artifacts.)

Establish a supply chain incident response process that defines how the organization responds when a supply chain compromise affecting one of its dependencies is disclosed — how quickly affected components are identified through SBOM and vulnerability data, how quickly affected applications are assessed for exploitation, and how quickly clean versions are deployed or mitigations applied.

Benefit(s)

Software supply chain risk governance converts the organization’s dependency on third-party packages and repositories from an unmanaged trust relationship into a governed security discipline. Package integrity verification prevents the most common supply chain attack vector — the substitution of a malicious package for a legitimate one — from reaching the build pipeline. Repository security controls reduce the attack surface available to adversaries seeking to compromise package sources. Dependency version pinning prevents automatic update mechanisms from being exploited as supply chain attack vectors. And the SBOM data that supports supply chain governance produces the rapid impact assessment capability that makes supply chain incident response effective rather than chaotic.