⛓️ Software and Hardware Supply Chain Security: SBOM, S-SDLC, and SLSA

Lessons from Major Supply Chain Incidents

The 2020 SolarWinds SUNBURST attack demonstrated that even deeply trusted software with a legitimate code-signing certificate could be a trojan horse. Attackers compromised the SolarWinds Orion build pipeline and inserted a backdoor into signed updates distributed to approximately 18,000 customers, including US government agencies and critical infrastructure operators. The attack dwelled undetected for months because the malicious code was delivered as a legitimate, digitally-signed software update — it bypassed every perimeter control because it was a trusted package.

CVE-2021-44228 (Log4Shell) revealed a different dimension of supply chain risk: transitive open source dependencies. The Apache Log4j library was embedded as a dependency (often a dependency of a dependency) in thousands of commercial products, including industrial SCADA platforms, OT vendor software, and enterprise applications. Organizations had no inventory of which of their systems used Log4j because their software vendors had not disclosed it. The remediation effort — requiring every vendor to audit their own codebase and release updates — took months. The 2024 XZ Utils backdoor (CVE-2024-3094) further demonstrated that a sophisticated adversary could socially engineer their way into an open-source maintainer role over years to insert a backdoor in a widely-used compression library. Together these incidents drove regulatory mandates for Software Bills of Materials.

Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of every component — open source libraries, third-party packages, and in-house code — that comprises a software product, along with version information and license data. The two dominant SBOM formats are SPDX (Software Package Data Exchange, ISO/IEC 5962:2021, maintained by the Linux Foundation) and CycloneDX (maintained by OWASP, more commonly used for security-focused SBOMs and VEX — Vulnerability Exploitability Exchange — documents). President Biden's Executive Order 14028 (May 2021) mandated SBOM adoption for software sold to the US federal government. CISA has published SBOM minimum element requirements: data fields (supplier name, component name, version, unique identifier, dependency relationships, SBOM author, timestamp) and automation support (machine-readable format, at least 75% of components with relationship data).

For OT/ICS, SBOM adoption enables rapid response to vulnerability disclosures: when a new CVE affects a specific library version, the asset owner can query their SBOM inventory to determine which of their deployed systems include the affected component — the question that took months to answer manually during Log4Shell can be answered in minutes with an SBOM database query. Tools like Anchore, Snyk, and Black Duck generate SBOMs from container images, build artifacts, and package manager lock files. CISA's SBOM tooling guide documents open source generators (Syft, CycloneDX CLI) for pipeline integration.

NIST SP 800-161r1: C-SCRM

NIST SP 800-161 Revision 1 (2022), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, provides a comprehensive framework for C-SCRM (Cyber Supply Chain Risk Management). It maps supply chain risk practices to the NIST Cybersecurity Framework functions (Identify, Protect, Detect, Respond, Recover) and provides control overlays for critical software, hardware, and services. Key practices include: establish a C-SCRM program with executive ownership, maintain a qualified supplier list with cybersecurity evaluation criteria, require contractual cybersecurity clauses in supplier agreements (including SBOM delivery, vulnerability disclosure timelines, and incident notification), and conduct periodic supplier assessments using questionnaires (SIG Lite, CAIQ) or third-party audit reports (SOC 2 Type II, ISO 27001).

Third-Party Risk Management (TPRM) and Vendor Assessment

TPRM programs tier vendors by criticality: Tier 1 vendors with access to critical OT systems or sensitive data require full on-site or virtual assessment, penetration testing results, and SOC 2 Type II reports. Tier 2 vendors with limited access require standardized security questionnaires and evidence review. Tier 3 commodity vendors with no system access require only contractual cybersecurity terms. For OT environments, vendor remote access is a critical TPRM risk vector — every OT vendor with remote access capability (ABB, Siemens, Rockwell Automation field service teams) is a Tier 1 supplier. Vendor access reviews should verify that vendors have MFA enforced on their remote access accounts, that vendor personnel list matches active employees (terminated employee accounts are a common TPRM gap), and that vendor session logs are retained and monitored.

Hardware Supply Chain: Counterfeit Components and Tamper Evidence

Hardware supply chain risk includes counterfeit electronic components (particularly in military and critical infrastructure procurement) and hardware implants inserted during manufacturing or shipping. Counterfeit components — recycled or cloned semiconductor chips relabeled with false markings — can fail prematurely or behave incorrectly in safety-critical applications. Mitigation requires: purchase from authorized distributors only, require certificates of conformance, use X-ray fluorescence (XRF) testing for component verification on high-criticality procurements. Hardware implants, famously demonstrated at DEF CON (e.g., the Bloomberg Supermicro reporting controversy and confirmed demonstrations of PCIe implant hardware), require tamper-evident packaging (seals with unique identifiers, chain of custody documentation), and post-delivery inspection protocols. NIST SP 800-193 (Platform Firmware Resiliency) and the NIST hardware security guidelines address firmware integrity verification via Secure Boot and TPM attestation.

Open Source Security: OSSF Scorecard, OpenSSF, and SLSA

The Open Source Security Foundation (OpenSSF), hosted by the Linux Foundation, provides tooling to evaluate open source project security posture. The OpenSSF Scorecard assesses repositories on 18 security checks including: Branch-Protection (are pushes to main branch protected?), Code-Review (are all commits reviewed?), Signed-Releases (are release artifacts cryptographically signed?), Token-Permissions (does CI use least-privilege tokens?), Pinned-Dependencies (are dependency versions pinned to specific hashes?). Scores range 0–10. Engineers evaluating open source libraries for inclusion in products should require a minimum Scorecard of 6 and specifically verify Signed-Releases and Pinned-Dependencies to mitigate dependency substitution attacks.

The SLSA (Supply-chain Levels for Software Artifacts) framework, developed by Google and now hosted by OpenSSF, defines four levels of supply chain integrity assurance for software artifacts. SLSA Level 1 requires a scripted build process and provenance (build metadata). SLSA Level 2 requires a hosted build service (GitHub Actions, Google Cloud Build) that generates signed provenance. SLSA Level 3 adds source integrity controls — every build input must be tracked and the build environment must be hardened. SLSA Level 4 (aspirational) requires two-party review of all changes and hermetic, reproducible builds. US government software procurement increasingly references SLSA levels as requirements, and NIST SSDF (Secure Software Development Framework, SP 800-218) maps to SLSA practices. Firmware signing with Secure Boot provides an analogous integrity chain for embedded OT device firmware.