1.11 Supply Chain Risk
Supply Chain Risk Management at a glance
Modern organisations rarely build every technology component themselves. They depend on software vendors, cloud providers, hardware manufacturers, consultants, managed service providers and many other suppliers.
Supply Chain Risk Management (SCRM) focuses on understanding and managing the cybersecurity risks introduced by those dependencies throughout the lifecycle of products and services.
Assess
Understand suppliers, products, dependencies and their security risk.
Who are we trusting?Control
Establish security requirements through contracts and technical controls.
What must they do?Monitor
Supplier and product risk can change throughout the relationship.
Is the risk changing?Why supply chain security matters
An organisation can build strong internal security controls and still be compromised through a supplier.
A trusted supplier may have privileged access, process sensitive data, provide critical infrastructure or supply software that becomes part of the organisation's environment.
Your security can depend on organisations that you do not directly control.
Examples of supply-chain dependencies
An organisation has excellent endpoint protection, network security and access controls.
However, attackers compromise a trusted software vendor and distribute a malicious update through the vendor's legitimate update mechanism.
The organisation can be compromised through trust placed in the software supply chain.Supply Chain Risk Management lifecycle
1 Risks from Products and Services Acquisition introduces trust
Acquiring a product or service means accepting some degree of dependency on another organisation.
Risks may arise from:
Software may contain vulnerabilities introduced during development.
Products may be deliberately altered somewhere in the supply chain.
Products may not genuinely originate from the claimed manufacturer.
Attackers may compromise the supplier itself.
Weak supplier processes may expose customers to unnecessary risk.
Supplier outages may disrupt dependent business services.
A supplier may stop supporting a product or cease trading.
Your supplier may depend on additional organisations you never selected.
2 Tampering, Counterfeits and Implants Specific supply-chain threats highlighted by ISC2
Product Tampering
Tampering involves unauthorised alteration of a product somewhere between its design, manufacture, distribution and use.
Network equipment is intercepted during distribution and modified before being delivered to the customer.
Counterfeit Components
Counterfeit products or components may falsely claim to originate from a legitimate manufacturer.
They may:
- perform unreliably;
- contain unknown components;
- lack expected security features;
- fail prematurely;
- create unknown security exposure.
Malicious Implants
A malicious implant is functionality intentionally introduced into hardware, firmware or software to provide unauthorised capability.
Firmware supplied with a device contains hidden functionality that allows remote unauthorised access.
Organisations need confidence not only that a product functions, but also that it is genuine and has not been improperly altered.
3 Supplier Criticality Not every supplier creates the same level of risk
Organisations may have hundreds or thousands of suppliers.
Applying the same level of assessment to every supplier may be inefficient.
Supplier criticality can help determine how much assurance is needed.
Factors may include:
A supplier provides office furniture and has no access to systems or sensitive information.
A cloud provider hosts the organisation's customer authentication, transaction processing and sensitive customer information.
The second supplier naturally warrants considerably greater cybersecurity scrutiny.4 Supplier Due Diligence Understand the supplier before relying on them
Due diligence involves gathering relevant information about a supplier or product so that informed acquisition and risk decisions can be made.
Areas worth considering can include:
Who owns or controls the supplier?
Where do products, components and services originate?
Can the supplier continue operating through disruption?
Does the supplier demonstrate reasonable foundational security?
Which other organisations does the supplier depend on?
Are there relevant previous incidents or security concerns?
Discovering that a critical supplier has unacceptable security only after a multi-year contract is signed makes risk treatment much more difficult.
5 Third-Party Security Assessment Obtain evidence rather than relying only on promises
Supplier assessment may use different forms of evidence depending on risk and criticality.
Ask the supplier about relevant controls and processes.
Review suitable independent assessment or certification evidence.
Exercise contractual audit or inspection rights where appropriate.
Review appropriate security-test or vulnerability information.
Assess relevant security policies and operating practices.
Understand how the service is designed and where customer data flows.
"Are you secure?"
Supplier response: "Yes."
Ask specific questions about access control, vulnerability management, incident response, secure development, continuity, encryption and subcontractors — and obtain appropriate evidence.
Self-attestation can provide useful information, but higher-risk relationships may justify stronger independent assurance.
6 Minimum Security Requirements Define expectations before integration
Organisations should determine minimum security requirements for products and services based on risk.
Authentication, privileged access and access-review expectations.
Protection requirements for sensitive data.
Identification and remediation of vulnerabilities.
Appropriate software-development security practices.
Security monitoring and audit requirements.
Supplier response and notification obligations.
Recovery capabilities for critical services.
Requirements that apply further down the supply chain.
Security requirements are considerably easier to negotiate before the organisation becomes dependent on the supplier.
📜 Contractual Security Controls Turn expectations into obligations
Supplier contracts provide an important mechanism for defining security responsibilities.
Depending on the relationship, contractual provisions may address:
A supplier processes highly sensitive customer information.
The contract requires the supplier to notify the organisation promptly following qualifying security incidents and to maintain agreed security safeguards.
Security expectations have now become part of the formal supplier relationship.⏱️ Service Level Requirements Can the supplier meet the business requirement?
Service Level Agreements or requirements establish measurable service expectations.
Security-relevant examples include:
Required uptime or service availability.
How quickly incidents must be acknowledged or addressed.
Recovery expectations following service disruption.
Expected timeframes for addressing security vulnerabilities.
A critical business service has an RTO of four hours.
Its only cloud supplier guarantees recovery within 24 hours.
The supplier commitment does not meet the organisation's business recovery requirement.A supplier's standard SLA is not automatically appropriate simply because that is what the supplier normally offers.
7 Continuous Supplier Monitoring Assessment does not end when the contract is signed
Supplier risk can change after onboarding.
Ongoing monitoring may consider:
A critical supplier passed a security assessment three years ago.
Since then it has been acquired, moved its service to a different cloud platform and outsourced development to several new subcontractors.
The original assessment may no longer represent the current risk.Critical suppliers should be reassessed when material changes occur, not merely because a calendar date arrives.
4️⃣ Fourth-Party and Sub-Tier Risk Your supplier has suppliers too
A third-party supplier may itself depend on other providers.
Those downstream organisations are sometimes described as fourth parties or sub-tier suppliers.
Your payroll supplier experiences no internal security failure.
However, one of its subprocessors responsible for file transfer is compromised and employee information is stolen.
Your organisation may still experience the impact despite having no direct contractual relationship with the compromised subprocessor.This is one reason supply-chain risk can be difficult to manage.
🎯 Concentration Risk Many services may depend on the same provider
Concentration risk occurs when several important services depend on the same supplier, technology or underlying infrastructure.
Ten critical business applications appear to use different SaaS suppliers.
Investigation reveals that all ten suppliers host their platforms on the same underlying cloud provider.
A major outage affecting that cloud provider could disrupt all ten services simultaneously.Possible mitigations
But introducing multiple suppliers can also increase complexity, so the trade-off should be assessed rather than assumed.
8 Software Supply Chain Risk Modern software is assembled from many components
Modern applications commonly contain code from many different sources.
These may include:
This creates dependency on the security and maintenance of external components.
Software supply-chain threats
A third-party library contains a security vulnerability.
An attacker publishes or modifies a malicious package.
Attackers compromise infrastructure used to build software.
A trusted update mechanism distributes compromised software.
A dependency is no longer actively maintained.
A malicious package is selected instead of the intended dependency.
9 Software Bill of Materials — SBOM What ingredients are inside the software?
What is an SBOM?
A Software Bill of Materials is a structured record of the software components and relationships used to build a software product.
An SBOM is similar to an ingredients list for software.
Why is this useful?
If a serious vulnerability is discovered in a widely used component, organisations need to determine which products contain that component.
A critical vulnerability is announced in Library X.
The organisation has 2,000 applications but does not know which ones use Library X.
The organisation can identify applications containing the affected library and prioritise investigation and remediation.
An SBOM can improve visibility into:
Having an SBOM does not automatically make software secure.
It provides information that can help organisations understand and manage software supply-chain risk.
How an SBOM can help
🌐 Open-Source Supply Chain Free to use does not mean free of risk
Open-source software can provide enormous value and is a normal part of modern software development.
However, organisations still need to manage relevant supply-chain risks.
Questions include:
The security issue is whether software dependencies are understood, maintained and appropriately managed.
10 Hardware Supply Chain Security Trust begins below the operating system
Supply-chain risk can exist at the hardware and firmware layers as well as software.
Risks may include:
Hardware assurance can involve
- trusted procurement channels;
- manufacturer verification;
- provenance records;
- anti-tamper controls;
- cryptographic verification;
- secure hardware roots of trust;
- component authenticity mechanisms.
🌱 Silicon / Hardware Root of Trust Establish trust from a protected foundation
What is a root of trust?
A hardware root of trust provides a highly trusted hardware or hardware-and-firmware foundation from which other security operations can establish trust.
Depending on its implementation, it may support functions such as:
Why put trust in silicon?
If the first software running on a device can be freely modified by an attacker, software checks built on top of it may also become unreliable.
A protected hardware foundation can make some security properties more difficult for software-level attackers to subvert.
The root of trust provides a protected starting point on which higher layers of trust can be built.
🧬 Physically Unclonable Function — PUF Use physical uniqueness as part of device trust
What is a PUF?
A Physically Unclonable Function uses small physical variations created during manufacturing to produce device-specific behaviour or responses.
Because those physical characteristics are difficult to reproduce exactly, PUF technology can be used in areas such as device identification, authentication or cryptographic key derivation, depending on the implementation.
Two chips may be manufactured from the same design.
Tiny physical variations introduced during manufacturing make each chip respond slightly differently to a particular challenge.
Those device-specific characteristics can contribute to proving or deriving device identity.PUF = physical uniqueness of the hardware.
Hardware assurance memory aid
📍 Provenance and Pedigree Where did the product come from?
Provenance concerns the origin and history of a product, component or service.
Understanding provenance can increase confidence that technology genuinely comes from the expected source and has followed an acceptable supply-chain path.
Questions include:
An organisation purchases network equipment from an unknown online marketplace because the price is considerably lower than from the authorised supplier.
The equipment appears genuine.
Lack of trusted provenance may increase the risk of counterfeit or altered components.✍️ Code Signing and Integrity Verification Can we establish where software came from?
Digital signatures can help establish software origin and detect unauthorised modification.
A vendor digitally signs a software update.
The customer verifies that the signature is valid before installing the update.
This can help establish that the package is associated with the expected signing identity and has not been modified since signing.If an authorised supplier itself distributes malicious or vulnerable code, a valid signature may still exist.
Code signing protects important aspects of authenticity and integrity, but it is not a complete supply-chain security solution.
🛟 Supplier Resilience What happens if the supplier fails?
Supply-chain risk includes availability and resilience as well as confidentiality and integrity.
A supplier may fail because of:
Continuity questions
🔒 Vendor Lock-In and Exit Risk Can we leave if the relationship becomes unacceptable?
Organisations may become highly dependent on a supplier over time.
Migration may become difficult because of:
A business stores ten years of critical information inside a proprietary SaaS platform.
The supplier's security posture deteriorates, but moving to another provider would take two years.
Lack of exit planning has increased the organisation's exposure.Important exit requirements should be considered during procurement and contracting rather than only when the relationship has already failed.
🚪 Secure Supplier Offboarding End the relationship cleanly
Supplier security responsibilities continue until the relationship has been safely terminated.
Revoke supplier accounts, VPN access, API credentials and privileged access.
Ensure required organisational information is returned or transferred.
Ensure remaining supplier copies are securely deleted where required.
Recover organisational hardware, tokens or other property.
Change credentials, certificates or cryptographic material known by the supplier where necessary.
Retain information required for audit, legal or regulatory purposes.
A managed service provider contract ends.
Supplier staff accounts are disabled, but a service API key known to the supplier remains active indefinitely.
Offboarding was incomplete.🚨 Supplier Security Incidents Your incident may begin somewhere else
Organisations should prepare for security incidents involving suppliers.
Questions include:
Critical supplier incidents are easier to manage when notification, escalation and communication routes have already been established.
🤝 Shared Responsibility Outsourcing a service does not outsource all responsibility
A supplier may operate security controls on behalf of a customer, but the customer may still retain important security responsibilities.
A cloud provider secures its underlying infrastructure.
The customer remains responsible for configuring user permissions within its cloud environment.
The customer accidentally grants public access to a sensitive storage location.
The existence of a secure cloud provider does not compensate for insecure customer configuration.Security responsibilities between customer and supplier should be understood rather than assumed.
⚠️ Common mistakes Supply-chain assumptions that create risk
Outsourcing a service does not automatically remove the customer's security, legal or risk-management responsibilities.
Supplier risk can change as ownership, systems, threats, subcontractors and business dependencies change.
Certifications and assurance reports can provide useful evidence, but they should be interpreted in the context of the actual service and organisational risk.
An SBOM improves visibility into software components. It does not by itself prove that those components or the overall application are secure.
Open source is not inherently insecure. The risk depends on factors such as provenance, maintenance, vulnerabilities, dependencies and organisational controls.
A digital signature can help verify origin and integrity, but the signed software itself may still contain vulnerabilities or malicious functionality.
Critical suppliers may themselves depend on important subcontractors, cloud providers and other sub-tier suppliers.
The alternative may depend on exactly the same underlying cloud, software or infrastructure provider.
Risk continues through deployment, maintenance, updates, supplier changes and eventual disposal.
Access, data, secrets, integrations and organisational assets also need to be considered during offboarding.
Think beyond your organisation's boundary
Supply-chain questions often test whether you recognise that risk extends beyond systems directly owned or operated by the organisation.
🔍 Before acquisition
📜 Contract
👁️ During service
💻 Software
🔧 Hardware
🚪 Exit
📝 Practice scenarios Apply supply-chain risk thinking
Scenario 1
A company plans to purchase a critical SaaS product that will process millions of customer records.
What should happen before purchase?
Appropriate supplier due diligence and risk assessment should be performed before the organisation becomes dependent on the service.
Scenario 2
A critical supplier passed a security assessment three years ago but has since changed ownership and moved its infrastructure.
What should happen?
Reassess relevant supplier risk because material circumstances have changed.
Scenario 3
A serious vulnerability is announced in an open-source library.
The organisation needs to determine which applications contain that component.
What can help?
A useful Software Bill of Materials and software component inventory.
Scenario 4
Network devices are purchased from an unknown reseller at a large discount.
What supply-chain concern should be considered?
Provenance, counterfeit components and possible tampering.
Scenario 5
A supplier provides a valid digital signature on its software update.
Does that prove the software is free from malicious code?
No. The signature can help establish authenticity and integrity but does not prove the signed software itself is safe.
Scenario 6
A supplier hosts a critical service and promises recovery within 24 hours. The customer's BIA requires recovery within four hours.
What is wrong?
The supplier's recovery commitment does not meet the customer's business requirement.
Scenario 7
An organisation believes it uses five unrelated SaaS providers. All five rely on the same underlying infrastructure provider.
What risk has been identified?
Concentration risk.
Scenario 8
A software supplier uses dozens of open-source packages but cannot identify which versions are present in its product.
Which supply-chain capability could improve visibility?
Software component inventory and SBOM practices.
Scenario 9
A security capability embedded into hardware provides a protected foundation for validating higher layers during startup.
Which concept does this describe?
A hardware or silicon root of trust.
Scenario 10
A device uses physical manufacturing variations to generate device-specific responses.
Which technology does this describe?
A Physically Unclonable Function — PUF.
Scenario 11
A SaaS supplier is secure, but one of its subprocessors suffers a data breach affecting your customer records.
What does this demonstrate?
Fourth-party or sub-tier supply-chain risk.
Scenario 12
A supplier contract ends and all supplier user accounts are disabled, but the supplier still retains copies of sensitive customer data.
What failed?
Secure supplier offboarding and data-disposal requirements.
Scenario 13
A supplier claims that its cybersecurity controls are strong but provides no supporting evidence.
What could improve assurance?
Appropriate third-party assessment, independent evidence or audit depending on the supplier's criticality.
Scenario 14
A critical supplier is compromised and the organisation learns about it from the media three weeks later.
What supplier control should be reviewed?
Contractual incident-notification requirements and supplier incident response processes.
Supply Chain Risk thinking flow
Quick memory aid
Assess. Require. Monitor. Exit.
ISC2 1.11 special terms
Key takeaways
Supply Chain Risk Management extends cybersecurity beyond the organisation's direct boundary.
Organisations depend on software suppliers, cloud providers, hardware manufacturers, contractors and many other external organisations.
Supply-chain threats can include tampering, counterfeit components, malicious implants, supplier compromise and insecure development practices.
Supplier risk should be assessed according to factors such as data access, privileged access, business criticality, connectivity and replacement difficulty.
Due diligence should occur before significant dependency is established wherever possible.
Third-party assessments can use questionnaires, independent assurance, technical evidence, audits and other forms of verification depending on supplier risk.
Minimum security requirements should be identified and incorporated into supplier relationships where appropriate.
Service-level requirements should align with the organisation's actual business and continuity requirements.
Supplier risk changes over time. Significant suppliers therefore require ongoing monitoring and reassessment.
A supplier may itself depend on other organisations, creating fourth-party or sub-tier risk.
Concentration risk can occur when many critical services ultimately depend on the same supplier or infrastructure.
An SBOM provides visibility into the components used to build software.
An SBOM improves visibility but does not prove that software is secure.
A hardware or silicon root of trust provides a trusted foundation that can support higher-level security functions.
A Physically Unclonable Function uses physical characteristics of hardware to provide device-specific behaviour useful for security applications.
Provenance helps establish where technology originated and whether trusted supply channels were used.
Outsourcing a service does not automatically outsource security responsibility.
Exit planning should consider access revocation, data return or deletion, credentials, migration and ongoing confidentiality requirements.
Most importantly: understand who your organisation depends on, what you are trusting them with, and what happens if that trust fails.
📚 Sources & Further Reading Authoritative references
- ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline - NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk Management Practices
View NIST C-SCRM guidance - NIST SP 1326 — C-SCRM Due Diligence Assessment Quick-Start Guide
View NIST due-diligence guidance - NIST — Cybersecurity Supply Chain Risk Management Project
View NIST C-SCRM resources - NIST — Software Bill of Materials
View NIST SBOM guidance - NIST — SBOM Glossary Definition
View SBOM definition - NIST — Hardware Root of Trust
View NIST definition