Cybersecurity and Digital Resilience
The Global Centre for Risk and Innovation (GCRI)
Software is assembled from open-source libraries, commercial components, build tools and update channels, and hardware from components made across many countries. Attackers who compromise a widely used component or update can reach thousands of downstream users at once. This page sets out how supply chain attacks work, how software provenance and composition are made visible, and what evidence serves developers, buyers and regulators.
Supply chain security · Enterprise network · Quarter 4
tier 1 to 4
| Supplier A | Cloud hosting | Yes | Medium |
| Supplier B | Payroll SaaS | No | Unknown |
| Supplier C | Managed SOC | Yes | Low |
| Supplier D | Identity provider | No | Unknown |
Fig.Security posture and third parties. Design wireframe with placeholder names and illustrative values, not a record or a live system.
Software supply chain security is the protection of the components, tools and channels used to build and deliver software. Dependencies run deep, build and update systems are targets, and critical open-source projects rely on few maintainers, so software bills of materials and verifiable provenance help organizations see and respond.
For supply chain security, in GCRI's spatial-intelligence reading, the map opens on population density, night lights and true-colour imagery with true colour from NASA GIBS, framed on Europe; every other NASA layer, live feed and forecast waits in the layer list.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Activity and hazards, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For supply chain security, in GCRI's spatial-intelligence reading, the map opens on population density, night lights and true-colour imagery with true colour from NASA GIBS, framed on Europe; every other NASA layer, live feed and forecast waits in the layer list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
Software and hardware dependency risk. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
A typical application includes hundreds of open-source packages, each with its own dependencies. A flaw or backdoor deep in the tree reaches every product that uses it.
Compromising a build system or update server lets attackers distribute malicious code signed and delivered as legitimate updates.
Critical open-source projects are often maintained by small volunteer teams, making them vulnerable to burnout, takeover and social engineering.
When a widely used component is found vulnerable, organizations with a software bill of materials can find and fix affected systems quickly; others search blind.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Software bill of materials | A machine-readable inventory of the components in a piece of software. |
| Build provenance | Verifiable information about how, where and from what a software artefact was built. |
| Dependency | A software component that another component relies on to work. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Products shipped with a software bill of materials | percent of products | per assessment | Vendor disclosures | DECLARED |
| Open-source dependencies with known vulnerabilities | count | weekly | Software composition analysis | OBSERVED |
| Builds with verifiable provenance | percent of builds | monthly | Build attestation records | OBSERVED |
| Malicious packages reported in registries | count | monthly | Package registry and research reports | REPORTED |
| Critical projects with security practices in place | score on a stated checklist | per assessment | Open-source scorecards | ESTIMATED |
| Time to remediate a critical component vulnerability | days | per event | Remediation records | OBSERVED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| OpenSSF Scorecard | Automated checks of open-source project security practices | Open source, Apache 2.0 |
| SLSA framework | Levels of supply chain integrity for software builds | Open, community specification |
| CycloneDX and SPDX specifications | Standard formats for software bills of materials | Open standards (SPDX is ISO/IEC 5962) |
| OSV open source vulnerability database | Vulnerabilities mapped to open-source package versions | Open, CC BY 4.0 |
| EU Cyber Resilience Act and NIST Secure Software Development Framework | Requirements and practices for secure products | Public, EU and US government terms |
Cybersecurity and Digital Resilience prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Software developers and vendors | Which components to trust and how to secure builds | Dependency analyses; provenance assessments |
| Buyers and procurement authorities | What supply chain evidence to require | SBOM reviews; security terms |
| Regulators | How to apply product security requirements | Adoption and vulnerability evidence |
Compromising one widely used component can give access to thousands of downstream organizations, which makes supply chains attractive to capable attackers. Accidental weaknesses in common libraries can have the same reach. Because organizations cannot inspect everything they use, they depend on the security practices of suppliers they may not know exist.
Supply chain risk arises at every stage from development to delivery and update.
Applications depend on many libraries, each with its own dependencies. Compromised build systems or update servers can distribute malicious code as a trusted update.
Firmware and hardware components can carry weaknesses that are hard to detect and fix, and replacement can take years.
Critical open-source projects may rely on a few volunteers. Burnout, takeover of abandoned projects or social engineering of maintainers create risk.
Supply chain incidents have shown two distinct patterns. In one, attackers compromise a supplier's build or update process so that a legitimate product delivers malicious code. In the other, a vulnerability in a widely used open-source component is discovered and must be found and fixed across countless systems. Both reward organizations that know what they run and can update it quickly.
Inventories of components in a product. They improve visibility but must be accurate and kept current to be useful.
Methods that record and verify how software was built, so tampering can be detected. Adoption is growing but uneven.
Graph analysis of software ecosystems, applying network science and contagion, identifies components on which many systems depend.
Testing and supply chain controls for hardware. Full verification is rarely feasible, so assurance relies on trusted processes.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.