cisspSecurity and Risk Management· 10 min read· 15 May 2026
Supply Chain Risk Management: Third-Party Risks, SBOMs, and Silicon Root of Trust
Supply chain risk management (SCRM) has become one of the most significant areas of cybersecurity practice — and one of the most heavily updated sections of the CISSP 2024 exam outline. The SolarWinds attack in 2020, the Log4Shell vulnerability in 2021, and a cascade of subsequent supply chain compromises have made clear that an organisation's security posture is only as strong as its weakest supplier.
For the CISSP exam, SCRM is tested at the governance and process level: understanding the risks, knowing the assessment lifecycle, and recognising the controls and standards that address supply chain threats.
Why Supply Chain Attacks Are a Top CISSP Concern
The SolarWinds attack provides the defining case study for modern supply chain risk. Threat actors compromised the SolarWinds Orion software build environment and inserted malicious code into legitimate software updates. When customers downloaded and installed the update — trusting the vendor's software signing — they unknowingly deployed a backdoor. Approximately 18,000 organisations, including multiple US federal agencies, were affected.
The SolarWinds attack illustrates why supply chain security is qualitatively different from conventional perimeter security. Traditional defences assume that threats originate outside the organisation's trusted network. A supply chain attack exploits the trust relationships that organisations depend on — the trust in a vendor's software, hardware, or services. By compromising a trusted third party, attackers can bypass even the most rigorous internal security controls.
For the exam: supply chain attacks are significant because they exploit trust relationships. The attacker does not need to breach the target directly — they compromise a trusted supplier instead.
Supply Chain Risk Categories
The CISSP identifies several categories of supply chain risk that candidates must understand.
Product tampering involves malicious modification of hardware or software during manufacturing or distribution. A compromised device may contain backdoors, keyloggers, or covert communication channels installed before the customer ever receives it.
Counterfeit components are fake hardware components that appear genuine but are of lower quality, contain hidden vulnerabilities, or have been modified to serve attacker objectives. This is particularly concerning in critical infrastructure, military, and medical device contexts where component integrity is safety-critical.
Hardware implants are covert malicious components inserted into legitimate hardware during manufacturing or supply chain handling. Unlike software backdoors, hardware implants can persist through OS reinstallations and are extremely difficult to detect through software-based security tools.
Third-party software vulnerabilities arise when software components from external vendors or open-source repositories contain vulnerabilities that are inherited by the organisation's products and systems. Log4Shell is the canonical example: a vulnerability in a widely used logging library affected thousands of applications that had incorporated it as a dependency.
Supply chain process failures occur when a vendor's internal processes are insufficient to prevent errors, tampering, or security failures before products reach the customer. This includes inadequate code review, missing security testing, and poor change management.
Software Bill of Materials (SBOM)
The Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all software components in a product — including open-source libraries, third-party modules, and their versions and dependencies. The SBOM has become a central tool in software supply chain risk management and was mandated for software sold to US federal agencies by Executive Order 14028 in 2021.
An SBOM allows organisations to: identify which of their products or systems are affected when a vulnerability is disclosed in a specific component (such as Log4j), understand the full dependency tree of their software, verify that software has not been tampered with in the supply chain, and make informed procurement decisions based on the security posture of the components used.
Standard SBOM formats include SPDX (Software Package Data Exchange, maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). These machine-readable formats allow automated tooling to ingest SBOM data and cross-reference it against vulnerability databases.
For the exam: SBOM is a 2024 addition to the CISSP outline. Know that it is a component inventory for software products, that it enables vulnerability tracking across the software supply chain, and that it is required for US federal software procurement.
Silicon Root of Trust and Physically Unclonable Functions
At the hardware level, the silicon root of trust is a concept for establishing a cryptographically verifiable, immutable foundation of trust in a computing device. It ensures that the first code executed when a device powers on is authentic and unmodified.
A silicon root of trust is typically implemented as a dedicated hardware module (such as a Trusted Platform Module, or TPM, or a secure enclave like Intel SGX or ARM TrustZone) that stores cryptographic keys, performs secure boot verification, and provides attestation services. Because the root of trust is implemented in silicon (hardware), it is significantly more resistant to tampering than software-based trust mechanisms.
Secure boot uses the silicon root of trust to verify the cryptographic signature of each stage of the boot process: firmware → bootloader → operating system kernel. If any component fails verification, the boot process halts. This prevents boot-level malware (bootkits) and ensures that compromised firmware or OS components cannot load undetected.
Physically Unclonable Functions (PUFs) exploit unique physical variations in semiconductor manufacturing to create a device-specific fingerprint. Because no two chips have identical physical characteristics at the microscopic level, a PUF can generate a unique cryptographic key from the device's physical properties — without storing the key in memory. PUFs are used in hardware authentication and anti-counterfeiting applications.
For the exam: silicon root of trust provides cryptographic assurance that a device's firmware and software are authentic. It is the hardware-level answer to supply chain integrity for computing devices.
Third-Party Assessment Programmes and Minimum Security Requirements
The process of managing third-party supply chain risk follows a lifecycle: assess before onboarding, monitor throughout the engagement, and reassess periodically or when circumstances change.
Pre-engagement assessment involves evaluating a vendor's security posture before entering into a relationship. This may include questionnaire-based assessments (such as the Cloud Security Alliance CAIQ, the Shared Assessments SIG, or custom questionnaires), review of third-party audit reports (SOC 2 Type II, ISO 27001 certification), contractual security requirements (right to audit, breach notification obligations, data handling requirements), and penetration testing reports.
Ongoing monitoring involves continuous or periodic review of the vendor's security status. This includes monitoring threat intelligence feeds for news of vendor breaches, reviewing vendor-provided security metrics, and conducting periodic reassessments.
Contractual protections should include: data processing agreements specifying how the vendor handles the organisation's data, breach notification requirements (typically requiring notification within 24 to 72 hours of a vendor-side breach affecting the organisation's data), right-to-audit clauses, security requirements as service level agreement components, and indemnification clauses.
Minimum security baselines define the floor of acceptable security practices for vendors. Organisations increasingly require vendors to demonstrate: multi-factor authentication on privileged accounts, vulnerability management and patch management programmes, endpoint detection and response capabilities, data encryption at rest and in transit, and employee security awareness training.
Exam Tip
SCRM questions test process — assessment BEFORE onboarding, monitoring THROUGHOUT engagement. When an exam question asks what to do before engaging a new vendor, the answer is always to conduct a security assessment first. When a question asks about ongoing vendor management, continuous monitoring is the answer. The exam also tests that supply chain risk cannot be eliminated by contractual controls alone — technical verification is also required.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Security and Risk Management
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.