Third-party and supply chain resilience

This is Part 4 of a 7-part series on Cyber Resilience for CISOs. Read the previous parts on resilience thinking, the threat landscape, and zero trust architecture for context.

---

A supplier breach can affect your systems even when your own controls work. Your recovery plans therefore need to account for organisations you do not control.

The most sophisticated attacks increasingly exploit this dependency. Nation-state actors compromise software vendors to reach their actual targets. Ransomware groups target managed service providers to multiply their victim count. Criminal organisations attack widely-used open-source libraries to poison thousands of downstream applications.

Include suppliers in access reviews and recovery planning.

The supply chain attack surface

Understanding the scope of third-party risk is the first step. Most organisations underestimate their exposure.

Software supply chains

Every application in your environment has a supply chain:

• Commercial software vendors who develop, maintain, and update their products
• Open-source dependencies embedded in your applications, including dependencies of other components
• Build tools and pipelines that compile and deploy your code
• Package managers and repositories from which you download components
• Container registries and base images on which your workloads run

Each link in this chain represents a potential attack vector. The SolarWinds compromise demonstrated how a single software vendor breach can impact thousands of downstream organisations.

Service provider chains

Beyond software, organisations depend on service providers:

• Managed service providers with privileged access to your systems
• Cloud service providers hosting your infrastructure
• SaaS applications processing your data
• Consultants and contractors with temporary access
• Outsourced functions from HR to customer support

These relationships often involve elevated access. An MSP compromise can give an attacker the privileged access already assigned to the provider.

Physical supply chains

Hardware and physical infrastructure also present risk:

• Network equipment that could contain backdoors
• Computing hardware from servers to IoT devices
• Data centre facilities where your infrastructure resides
• Telecommunications providers carrying your traffic

Physical supply chain attacks are harder to execute but potentially devastating when successful.

Why traditional approaches fail

Most third-party risk programmes focus on compliance assessment. Vendors complete questionnaires, provide certifications, and undergo periodic reviews. This creates false confidence.

Point-in-time assessment

Annual security reviews capture a snapshot. They reveal nothing about what happens between assessments. A vendor could be compromised the day after receiving a clean audit.

Reality: Continuous monitoring and ongoing verification matter more than periodic certification.

Self-reported data

Questionnaires rely on vendors honestly and accurately representing their security posture. There is no verification. Vendors have incentives to present their security favourably.

Supplement self-assessment with independent validation where possible.

Certification theatre

SOC 2 reports, ISO 27001 certificates, and similar attestations demonstrate that security processes exist. They do not guarantee those processes are effective or that the vendor has not been compromised.

Reality: Certifications are necessary but insufficient. They are starting points, not endpoints.

One-size-fits-all

Treating all vendors identically wastes resources on low-risk relationships while potentially under-scrutinising critical ones.

Reality: Tiered approaches that concentrate effort on high-risk vendors are more effective.

Building supply chain resilience

Genuine resilience requires moving beyond compliance checkbox approaches. Consider these strategies.

Visibility and inventory

Start by recording the suppliers and software your operations depend on:

Software inventory:

• What commercial software do you use?
• What open-source components are embedded in your applications?
• What build tools and infrastructure support your development?
• What container images and base systems do you run?

Service provider inventory:

• What organisations have access to your systems?
• What data do you share with third parties?
• What services would cause operational impact if unavailable?

Categorisation:

• Tier 1: Critical vendors whose compromise would cause major impact
• Tier 2: Important vendors with significant access or dependency
• Tier 3: Standard vendors with limited access and replaceability

Concentrate resilience investments on Tier 1 and 2 relationships.

Continuous assessment

Replace point-in-time audits with ongoing monitoring:

• Security ratings services that continuously assess external attack surface
• Threat intelligence that flags vendor compromises or vulnerabilities
• Dark web monitoring for vendor credentials or data appearing in criminal marketplaces
• News monitoring for vendor breaches or security incidents

These do not replace deeper assessment but provide early warning between formal reviews.

Contractual protections

Ensure contracts support resilience objectives:

• Security requirements. Specific controls vendors must implement
• Incident notification. Timely disclosure when vendors experience security events
• Audit rights. Ability to verify vendor security claims
• Subcontractor disclosure. Visibility into fourth-party relationships
• Exit provisions. Clear terms for data return and access termination

These provisions are easier to negotiate before signing than after you are dependent.

Architectural containment

Apply zero trust principles discussed in Part 3 to third-party access:

• Least privilege. Vendors receive only the access they need
• Segmentation. Third-party access is isolated from sensitive systems
• Monitoring. Third-party activities are logged and analysed
• Time-bound access. Temporary access expires automatically
• Multi-party approval. Sensitive actions require internal approval

Assume that any third party could be compromised. Design access accordingly.

Software composition analysis

For software dependencies, implement rigorous analysis:

• Software Bill of Materials (SBOM). Document all components in your applications
• Vulnerability scanning. Automated checking for known vulnerabilities in dependencies
• License compliance. Ensure open-source usage meets licensing obligations
• Dependency update policies. Regular updating to receive security patches
• Private artifact repositories. Control what packages can be used

This is particularly important given the prevalence of dependency-based attacks discussed in Part 2.

Alternative planning

Resilience means continuing operations even if a supplier fails:

• Identify single points of failure. Which vendor failures would halt operations?
• Develop alternatives. Are there backup providers for critical functions?
• Test switchover. Can you actually execute the transition?
• Maintain capability. Do you retain skills to operate if a vendor departs?

This applies beyond security to general business continuity, but security events increasingly trigger vendor transitions.

Special considerations

Certain third-party relationships deserve additional attention.

Managed service providers

MSPs typically have broad privileged access to customer systems. Compromise of your MSP may be more damaging than a direct attack.

Additional controls:

• Require MFA for all MSP access
• Implement session recording for privileged activities
• Conduct periodic access reviews
• Establish out-of-band verification procedures for sensitive changes
• Ensure contractual incident response obligations

Cloud service providers

Cloud dependencies are particularly complex because you cannot easily switch providers, and their controls are partially outside your visibility.

Additional controls:

• Understand the shared responsibility model explicitly
• Implement cloud-specific security controls (CSPM, CWPP)
• Monitor for misconfigurations that could expose data
• Plan for multi-cloud or hybrid options where critical
• Ensure data portability

Open-source dependencies

Open-source software powers most modern applications, but maintainer security practices vary widely.

Additional controls:

• Monitor for compromised packages
• Verify package integrity using checksums and signatures
• Consider the health of projects you depend on (maintainer activity, security responsiveness)
• Pin versions and control updates deliberately
• Contribute to projects you critically depend on

Quick reference: third-party resilience assessment

Use this checklist to assess your third-party resilience posture:

Visibility:

• Complete inventory of software vendors and dependencies
• Complete inventory of service providers with access
• Third parties categorised by criticality and risk
• SBOM maintained for critical applications
• Fourth-party (vendor's vendor) risks understood

Assessment:

• Tiered due diligence process based on risk
• Continuous monitoring supplements point-in-time reviews
• Security ratings tracked for critical vendors
• Threat intelligence incorporated into vendor monitoring
• Regular reassessment cadence established

Contractual:

• Security requirements in contracts
• Incident notification obligations defined
• Audit rights preserved
• Exit and transition provisions included
• Subcontractor disclosure required

Architectural:

• Third-party access follows least privilege
• Vendor access segmented from sensitive systems
• Third-party activities logged and monitored
• Time-bound access implemented where appropriate
• Sensitive operations require internal approval

Resilience:

• Single points of failure identified
• Alternative providers identified for critical functions
• Switchover procedures documented
• Data portability verified
• Incident response coordinated with critical vendors

The regulatory dimension

Regulators increasingly recognise third-party risk. Frameworks like DORA (Digital Operational Resilience Act) impose specific requirements for critical sector organisations.

Key regulatory themes:

• Due diligence. Appropriate assessment before engaging vendors
• Ongoing monitoring. Continuous oversight, not just initial review
• Concentration risk. Avoiding over-dependence on single providers
• Exit planning. Ability to transition away from vendors
• Incident coordination. Aligned response capabilities

As discussed in SOC 2 and secure controls, demonstrating third-party risk management is increasingly a compliance obligation, not just best practice.

Building collaborative relationships

Third-party risk management is not purely adversarial. The best relationships involve genuine collaboration:

• Share threat intelligence with trusted partners
• Conduct joint exercises that test coordinated response
• Discuss security openly rather than hiding behind questionnaires
• Provide feedback that helps vendors improve
• Recognise mutual dependence: your vendor's security is your security

Organisations that treat vendors as partners in security, rather than merely sources of risk, often achieve better outcomes.

What comes next

Third-party resilience extends your security boundary. But eventually, despite all preparation, incidents will occur. Part 5 provides a reality check on incident response and the steps to take when things go wrong.

Part 6 addresses how to communicate crises to the board, turning incidents into leadership moments.

Review which supplier failures would stop your operations and test the alternatives before you need them.

---

Managing third-party security risk

My IT management services help organisations assess vendor risk, implement ongoing monitoring, and build resilience across their supplier ecosystem.

Get in touch to discuss how to strengthen your third-party security posture.

---

Previous: Part 3: Zero Trust as Resilience Foundation

Next: Part 5: The Incident Response Reality Check