Software Supply Chain Security: Why It Matters Now
1. What this chapter covers
This is a background chapter — read it, no hands-on work required. Through real-world incidents, you will see what software supply chain security looks like in practice, why an SBOM (Software Bill of Materials) has become an essential tool, and how international regulations now require it.
After reading this chapter, you will have a clear answer to the question "Why do I need this kit?" Everything you do in later chapters — writing policy, designing processes, creating an SBOM, analyzing vulnerabilities — makes more sense in the context laid out here.
2. What is the software supply chain?
How open source enters a product
Software is never built in isolation. Developers pull open source libraries from package registries such as npm, PyPI, and Maven, and each of those libraries depends on still other libraries. This entire chain is the software supply chain.
Modern software is 70-90% open source components. In other words, far more code comes from outside than your team writes itself. This speeds up development, but it is also a conduit through which external threats can flow inward.
Supply chain security is the discipline of identifying and managing the risks that can arise anywhere along this path — vulnerabilities, malware, and license violations.
3. Three real-world supply chain attacks
The following three cases show that supply chain security is anything but an abstract concept.
SolarWinds (2020)
What happened Attackers inserted malware (Sunburst) into SolarWinds' internal build pipeline. Because it was bundled into a legitimate software update (the Orion Platform) and distributed that way, existing security tools had an extremely hard time detecting it.
Scope of impact More than 18,000 organizations worldwide — including federal agencies such as the U.S. Treasury and the Department of State — installed the malicious update. Attackers had undetected access to internal networks for months.
Lesson The build pipeline that produces the software can itself be a target. You need a system that verifies where every component in the product comes from and that the build process is safe.
Log4Shell (2021, CVE-2021-44228)
What happened An injection vulnerability was found in Apache Log4j 2, a logging library used almost universally across Java applications. It abused JNDI (Java Naming and Directory Interface), letting an attacker achieve remote code execution (RCE) with a single specially crafted string.
Scope of impact Hundreds of millions of systems worldwide were affected, covering the services of virtually every major technology company — Apple, Amazon, Tesla, Twitter, and more. Millions of exploit attempts were detected within 72 hours of disclosure.
Lesson You cannot even patch what you cannot find. With an SBOM, every system using Log4j could have been identified and remediated immediately.
XZ Utils (2024, CVE-2024-3094)
What happened Over two years, an attacker using the pseudonym "Jia Tan" contributed to the XZ Utils open source project, posing as a trustworthy maintainer. After building credibility through steady contributions, they committed malicious code that planted a backdoor in sshd (the SSH daemon). A widespread compromise was averted only because a developer noticed anomalies just before the release shipped.
Scope of impact Major Linux distributions including Fedora, Debian, and Ubuntu had already pulled in the vulnerable versions. Had discovery been delayed by even a few days, backdoors would have landed on millions of servers.
Lesson The identity and long-term behavior of open source contributors deserve scrutiny. The health of the open source projects you depend on — their governance and maintainer activity — is also part of supply chain security.
4. International regulatory trends
Supply chain security is moving beyond voluntary best practice and becoming a legal requirement.
U.S. Executive Order EO 14028 (2021)
Background In response to a series of large-scale supply chain attacks such as SolarWinds and Microsoft Exchange, the Biden administration signed this cybersecurity executive order in May 2021.
Key requirements
- Mandatory submission of an SBOM for software delivered to the federal government
- Conformance with the SBOM minimum elements defined by the NTIA (National Telecommunications and Information Administration)
- Confirmation of compliance with secure software development practices
Impact on companies Companies that supply the U.S. federal government directly are affected immediately. Because the same requirements increasingly flow down the indirect supply chain (through subcontracting by the supplier), most companies operating in the U.S. market should assume they will be affected too.
EU Cyber Resilience Act — CRA (2024)
Background An EU-wide regulation adopted in 2024 to strengthen the cybersecurity of digital products placed on the EU Digital Single Market.
Key requirements
- Apply security requirements to digital products placed on the EU market (software included)
- Mandatory management of the open source component list and remediation of vulnerabilities
- Full enforcement scheduled for 2027
Penalties For non-compliance, up to EUR 15 million or 2.5% of annual global turnover, whichever is greater.
Impact on companies This applies to any business that sells software products or services in the EU. All products with digital elements — cloud services, mobile apps, IoT devices — are in scope.
Trends in Korea
Discussions on mandating supply chain security are advancing quickly in Korea as well.
- MSIT/KISA Software Supply Chain Security Guidelines (2023): Korea's first official guideline recommending the adoption of SBOM.
- Review of SBOM for public-sector software projects: Authorities are considering requiring an SBOM for software procured by public institutions.
- Discussion of a domestic SBOM mandate: Similar domestic regulation is likely to follow once the EU CRA takes effect.
5. How both standards contribute to supply chain security
ISO/IEC 5230 and ISO/IEC 18974 each address one of the two key risks in supply chain security.
- ISO/IEC 5230: removes the risk of license violations by ensuring transparency in open source use.
- ISO/IEC 18974: removes security risk by identifying and responding to known vulnerabilities.
Conforming to both standards together covers both the licensing and the security side of supply chain security.
| Risk type | Responsible Standard | Main tools |
|---|---|---|
| License violation | ISO/IEC 5230 | SBOM + License Scan |
| Security vulnerability | ISO/IEC 18974 | SBOM + CVE scan |
The core tool shared by both standards is the SBOM. You need an SBOM to scan licenses, and you need it to look up CVEs. As the Log4Shell case showed, without an SBOM you cannot even tell where a component is being used.
6. Self-study path
You can simply read this chapter. Focus on understanding the concepts.
- Read this page — get the full context of supply chain security
- Summarize, in your own words, the three key lessons from the incidents
- Identify which international regulations apply to your company
- Read
sbom-101.mdfor a detailed understanding of SBOM technical concepts
7. Completion checklist
- I can explain the three supply chain security incidents (SolarWinds, Log4Shell, XZ Utils)
- I understand why an SBOM is needed
- I have identified how EO 14028 and the EU CRA affect my company
- I understand the role each standard plays in supply chain security
8. Next steps
- Learn the SBOM technical concepts: go to
sbom-101.mdto learn the CycloneDX and SPDX formats and the SBOM minimum elements. - Go straight to environment preparation: go to
docs/01-setup/and start installing the toolchain.
Once you understand the concepts well enough, you can begin the hands-on work in docs/01-setup/. You can return to this chapter for reference at any time.