Software supply chain security

No organization writes all of its own software. A typical modern application contains hundreds of open source packages, most of them pulled in indirectly by the packages its developers chose, and it is built with third-party tools, deployed on third-party platforms and updated through third-party channels. Each of those is a link in the software supply chain, and each can fail. The OWASP Top 10 2025 recognized this by expanding its old category of vulnerable and outdated components into Software Supply Chain Failures, ranked third. This lesson explains the risks, the controls that address them, three landmark incidents viewed from a governance perspective, and the regulatory expectations that now apply in Canada, the United States and the European Union.

CISSP-110 Lesson 10 introduced supply chain risk management for the whole organization, and ITIL-141 covers supplier management as a service management practice. Lesson 4 of this course covered the organization's own build pipeline, and Lesson 11 covers the acquisition of complete software products and services. This lesson concentrates on the components and tools that flow into software the organization builds.

How supply chain risk arises

Supply chain risk in software takes several forms. A component may contain an ordinary vulnerability that is discovered after the organization has adopted it, which is by far the most common case. A component may be abandoned by its maintainers and stop receiving fixes. A legitimate component or build tool may be deliberately compromised, as in the incidents described below. A malicious package may be published with a name similar to a popular one, a practice known as typosquatting, in the hope that developers install it by mistake. A build may fetch a public package instead of an internal one with the same name, a weakness known as dependency confusion. And a component's license may impose obligations the organization did not expect. The controls for all of these start with the same foundation: knowing exactly what is in the software.

Software bills of materials

A software bill of materials (SBOM) is a formal, machine-readable inventory of the components in a piece of software and the relationships between them, analogous to the list of ingredients on a food label. The two dominant formats are SPDX, maintained by the Linux Foundation and published as the international standard ISO/IEC 5962:2021, and CycloneDX, maintained by OWASP and standardized by Ecma International as ECMA-424. In 2021 the US National Telecommunications and Information Administration (NTIA) published the minimum elements for an SBOM: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and timestamp, together with practices on how often SBOMs are produced and how they are shared. CISA released a proposed update of these minimum elements for comment in August 2025, adding fields such as component hashes, license information and the tool used to generate the SBOM.

An SBOM is useful only if it is generated automatically for every build, stored with the release, kept accurate and actually used. Its main uses are answering the question 'are we affected?' within minutes when a new vulnerability is announced, tracking license obligations, and giving customers transparency. A related format, Vulnerability Exploitability eXchange (VEX), lets a supplier state whether a product is actually affected by a given vulnerability, which helps customers avoid chasing findings in components whose vulnerable code is not used.

import json
# Match an invented CycloneDX-style SBOM against an invented advisory list (defensive pattern)
sbom = json.loads('''{
  "bomFormat": "CycloneDX", "specVersion": "1.6",
  "metadata": {"component": {"name": "refunds-service", "version": "2.4.0"}},
  "components": [
    {"name": "webframe",   "version": "5.2.1", "purl": "pkg:pypi/webframe@5.2.1"},
    {"name": "logfmt",     "version": "2.14.0", "purl": "pkg:pypi/logfmt@2.14.0"},
    {"name": "xmlparse",   "version": "1.0.9", "purl": "pkg:pypi/xmlparse@1.0.9"},
    {"name": "dateutilx",  "version": "0.9.3", "purl": "pkg:pypi/dateutilx@0.9.3"}
  ]}''')
advisories = [   # name, first affected, first fixed, identifier, known exploited?
    ('logfmt',   '2.0.0', '2.17.1', 'ADV-2026-0412', True),
    ('xmlparse', '1.1.0', '1.1.4',  'ADV-2026-0388', False),
    ('webframe', '5.0.0', '5.2.0',  'ADV-2026-0201', False),
]
v = lambda s: tuple(int(x) for x in s.split('.'))
print('SBOM for', sbom['metadata']['component']['name'], 'lists', len(sbom['components']), 'components')
for c in sbom['components']:
    for name, lo, fixed, adv, kev in advisories:
        if c['name'] == name and v(lo) <= v(c['version']) < v(fixed):
            urgency = 'URGENT (known exploited)' if kev else 'schedule'
            print(f"  {c['name']} {c['version']} affected by {adv}; upgrade to >= {fixed}: {urgency}")
print('Not affected: versions outside every advisory range')

SBOM for refunds-service lists 4 components
  logfmt 2.14.0 affected by ADV-2026-0412; upgrade to >= 2.17.1: URGENT (known exploited)
Not affected: versions outside every advisory range

Note the comparison of versions as numbers rather than text, since '2.14.0' sorts before '2.9.0' as text but after it as a version. Real tools use package URLs (purls) and standard advisory databases such as the Open Source Vulnerabilities (OSV) database and the US National Vulnerability Database, and they must cope with the wide variety of versioning schemes in different ecosystems.

Choosing and managing components

The best time to manage component risk is before a component is adopted. A component policy should define how new dependencies are approved and what is considered: how actively the project is maintained, how many maintainers it has, whether it has a security policy and responds to reports, its history of vulnerabilities, its license, how widely it is used, and whether a smaller or standard-library alternative would do. The OpenSSF Scorecard project automates many of these checks for open source repositories. Fewer dependencies mean a smaller attack surface and less maintenance.

Once adopted, components need continuous management. Dependencies should be pinned to exact versions with lock files and integrity hashes so that builds are repeatable and a changed package cannot slip in silently. Builds should pull packages through an internal proxy or mirror that the organization controls, which also defends against dependency confusion when internal package names are reserved. Automated tools should propose upgrades when fixes are released, and teams should merge routine upgrades frequently so that urgent upgrades are small. Components that reach end of life must be replaced, not left in place indefinitely.

# Health score for candidate open source components before adoption (illustrative weights)
candidates = {
    #               maintainers, months since release, security policy, open critical issues, terms ok
    'qrcode-lite':  (1, 26, False, 2, True),
    'qrgen':        (6, 2,  True,  0, True),
    'fastqr':       (3, 5,  True,  0, False),
}
def score(m, months, policy, crit, lic):
    s = min(m, 5) * 8                    # up to 40 for maintainers
    s += 25 if months <= 6 else (10 if months <= 18 else 0)
    s += 15 if policy else 0
    s += 20 if crit == 0 else 0
    return s if lic else 0              # unacceptable usage terms override everything
for name, attrs in candidates.items():
    s = score(*attrs)
    verdict = 'approve' if s >= 70 else ('review' if s >= 40 else 'reject')
    print(f'{name:12s} score {s:3d}  {verdict}')

qrcode-lite  score   8  reject
qrgen        score 100  approve
fastqr       score   0  reject

Three landmark incidents

SolarWinds (disclosed December 2020). Attackers compromised the build environment of SolarWinds' Orion network management product and inserted malicious code that was compiled, signed and distributed as a legitimate update to roughly 18,000 customers, including government agencies. Signing did not help, because the malicious code was added before signing. The governance lessons concern the integrity of the build process itself: isolated and monitored build systems, provenance, reproducibility, and least privilege and monitoring for network management tools that have broad access in customer environments.

Log4Shell (disclosed December 2021). A critical vulnerability (CVE-2021-44228) in Log4j, a ubiquitous Java logging library, allowed remote code execution in a vast number of products. Many organizations spent weeks simply finding out where they used Log4j, often as a transitive dependency several layers deep or inside vendor products. The governance lessons concern inventory: organizations with accurate SBOMs and software inventories could answer 'are we affected?' quickly, and those without could not. The incident also highlighted how much critical infrastructure depends on open source projects maintained by a handful of volunteers.

xz Utils (discovered March 2024). Over about two years, a contributor using the name 'Jia Tan' gained the trust of the overworked maintainer of xz Utils, a compression library included in many Linux distributions, and became a co-maintainer. Malicious code hidden in test files and the release build process was then introduced into versions 5.6.0 and 5.6.1 (CVE-2024-3094). It was discovered by chance, by a Microsoft engineer investigating a small slowdown, before it reached most stable distributions. The governance lessons concern the human side of open source: maintainer burnout, the difficulty of verifying contributor identity, differences between published source and release artifacts, and the value of supporting the projects an organization depends on.

Regulatory and government expectations

In the United States, Executive Order 14028 of May 2021 directed NIST to define secure software development practices, which led to the SSDF, and Office of Management and Budget memoranda M-22-18 and M-23-16 required software producers selling to federal agencies to attest to those practices using a CISA common form released in March 2024. In January 2026, OMB memorandum M-26-05 rescinded M-22-18 and M-23-16, ending the government-wide attestation requirement; each agency now sets its own software assurance policy based on risk, may still require SBOMs in contracts and can use the CISA form and the SSDF voluntarily. Executive Order 14306 of June 2025 amended EO 14028 and directed further NIST work on the SSDF. Sector rules also apply: the FDA, for example, requires SBOMs in premarket submissions for networked medical devices. Defense contractors face the Cybersecurity Maturity Model Certification (CMMC) program.

The European Union's Cyber Resilience Act (CRA), which entered into force in December 2024, applies to products with digital elements placed on the EU market and therefore reaches many North American software makers. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform, with an early warning within 24 hours, a notification within 72 hours and a final report later. Most other obligations, including secure-by-design requirements, vulnerability handling, security updates for a defined support period and technical documentation that includes an SBOM, apply from 11 December 2027. Fines can reach 15 million euros or 2.5 % of worldwide turnover. Ridgeline does not currently sell in the EU, but its bank partner has asked whether its products would meet CRA-style expectations, which shows how regulation in one market quickly becomes a contractual expectation in others.