This chapter covers third-party and supply chain risk in the context of penetration testing scoping, a critical topic in Domain 1 of the PT0-002 exam. Understanding how to identify, scope, and test third-party risks is essential because many breaches originate through trusted vendor relationships. Approximately 10-15% of exam questions touch on supply chain risk, vendor assessments, or scope considerations related to external parties. Mastering this chapter will help you define appropriate rules of engagement when third parties are in scope.
Jump to a section
Imagine you are a building manager responsible for a secure office tower. You control access to the building, CCTV, and alarm systems. However, you hire an external cleaning company to service the offices at night. That cleaning company brings its own employees, equipment, and even its own cleaning supplies. You give them a master key card that works only after hours and only for the floors they need to clean. You also require them to sign a contract stating they will perform background checks on all employees and not share the key card. But you never verify those background checks, and you don't inspect their cleaning supplies for hidden cameras. One day, a cleaner copies the key card and sells it to a burglar. Your building is compromised because you trusted the third party without validating their security practices. This is exactly how supply chain risk works in penetration testing: your organization's security is only as strong as the weakest link in the chain of vendors, contractors, and suppliers that have access to your systems or data. A penetration tester must assess not only the internal environment but also the third-party relationships that could be exploited as an entry point.
What Is Third-Party and Supply Chain Risk?
Third-party risk refers to the potential security exposure introduced by external entities that have access to an organization's data, systems, or facilities. Supply chain risk extends this concept to include the entire lifecycle of products and services—from software libraries and hardware components to cloud providers and maintenance contractors. For the PT0-002 exam, you must understand that these risks must be explicitly addressed during the planning and scoping phase of a penetration test.
Why It Exists
Organizations increasingly rely on external vendors for specialized services, software, and infrastructure. Each vendor relationship creates a potential attack vector. The 2020 SolarWinds breach is a textbook example: attackers compromised the software build pipeline of a trusted IT management vendor, inserting a backdoor into updates that were then deployed to thousands of customer networks. This incident underscored that an attacker can bypass a well-defended perimeter by compromising a less-secure third party.
How It Fits into Penetration Testing Scoping
During the scoping phase, the penetration tester and the client agree on the boundaries of the test. If third-party systems are in scope, the tester must obtain explicit authorization from both the client and the third party. Common in-scope third-party elements include:
Cloud services (e.g., AWS, Azure, GCP) where the client is the customer
Software-as-a-Service (SaaS) applications used for business operations
Hardware or firmware from specific vendors
Code libraries or open-source components used in the client's software
Managed service providers (MSPs) that handle IT operations
Key Components and Definitions
Vendor Risk Assessment (VRA): The process of evaluating a vendor's security posture before engagement. This includes reviewing certifications (SOC 2, ISO 27001), security policies, and incident response capabilities.
Service Level Agreement (SLA): A contract that defines the level of service expected, including security guarantees, uptime, and breach notification timelines.
Business Partner Agreement (BPA): A legal agreement that outlines data handling responsibilities and liability in case of a breach.
Software Bill of Materials (SBOM): A formal record of all components used in building software, including open-source libraries and their versions. SBOMs help identify known vulnerabilities (CVEs) in third-party components.
Attack Surface: The sum of all points where an unauthorized user can try to enter or extract data. Third-party integrations expand the attack surface.
Step-by-Step Mechanism of Third-Party Risk in a Penetration Test
Identify Third Parties: During scoping, list all vendors, partners, and suppliers that have access to the client's network or data. This includes cloud providers, payment processors, SaaS apps, and even physical security contractors.
Determine Scope Inclusion: Decide which third parties are in scope. This depends on the test objectives. For example, a red team exercise might include the client's use of a specific cloud provider, while a web application test might include APIs consumed from a third party.
Obtain Legal Authorization: The tester must have written permission to test third-party systems. This often requires a separate contract or letter of authorization from the third party. Without it, testing may violate laws (e.g., Computer Fraud and Abuse Act in the US).
Assess Third-Party Security: If in scope, the tester evaluates the third party's security controls. This can include:
- Reviewing the vendor's security documentation - Performing external scans of the vendor's infrastructure (if permitted) - Testing the integration points (APIs, SSO, VPN connections) - Checking for default credentials, misconfigurations, or known vulnerabilities
Exploit Third-Party Weaknesses: The tester attempts to use the third-party access as a pivot point to reach the client's internal systems. For example, if a vendor's VPN is poorly configured, the tester might gain access to the client's network through that VPN.
Report Findings: The final report includes risks associated with third parties, with recommendations such as enforcing multi-factor authentication (MFA) on vendor access, segmenting networks, and conducting regular vendor assessments.
Common Third-Party Attack Vectors
Piggybacking: An attacker gains access to the client's network by exploiting a trusted connection from a compromised third party. For example, a vendor's remote desktop tool is used to jump into the client's environment.
API Abuse: Insecure APIs from third-party services can be exploited to access data or perform unauthorized actions.
Data Interception: Data transmitted between the client and a third party may be intercepted if not encrypted properly.
Malicious Updates: As in the SolarWinds case, attackers compromise the software update mechanism to distribute malware.
Physical Access: Third-party maintenance personnel may have physical access to servers or network equipment, allowing them to install hardware keyloggers or steal devices.
Relevant Standards and Frameworks
The PT0-002 exam may reference these frameworks: - NIST SP 800-53: Provides security controls for supply chain risk management (e.g., SR-1 through SR-12). - ISO 28000: Supply chain security management systems. - SOC 2: Reporting on controls at service organizations relevant to security, availability, processing integrity, confidentiality, and privacy. - CSA STAR: Cloud Security Alliance's Security, Trust & Assurance Registry for cloud providers.
Configuration and Verification Commands
While third-party risk assessment is largely a documentation and process exercise, certain technical checks are common:
- DNS enumeration: dig any example.com to discover third-party services like mail servers or CDNs.
- Certificate transparency: openssl s_client -connect example.com:443 to verify SSL/TLS certificates from third-party providers.
- Shodan/Censys: Search for exposed third-party devices or services that belong to the client's vendors.
- Nmap scripts: nmap --script http-headers to check for security headers on third-party web applications.
- OWASP ZAP/Burp Suite: Test third-party API endpoints for common vulnerabilities (injection, broken authentication).
How It Interacts with Related Technologies
Third-party risk is closely tied to: - Cloud Security: The shared responsibility model means the client is responsible for securing their data even in the cloud. The tester must understand what the cloud provider secures vs. what the client must secure. - Identity and Access Management (IAM): Federated identity (SSO) between the client and third parties creates trust relationships that can be exploited. - Network Segmentation: VLANs and firewalls can limit third-party access to specific segments, reducing blast radius. - Data Loss Prevention (DLP): DLP policies may flag data exfiltration to third-party services, but misconfigurations can allow leaks.
Exam-Relevant Details
The PT0-002 objectives explicitly list "Third-party and supply chain risk in scope" under Domain 1.2.
Know that a Business Partner Agreement (BPA) is the legal document that defines data handling responsibilities.
Understand the difference between a Vendor Risk Assessment (evaluates security posture) and a Service Level Agreement (defines performance metrics).
Be aware that Software Bill of Materials (SBOM) is a key tool for identifying vulnerabilities in third-party components.
Remember that penetration testing of third-party systems requires explicit written authorization from both the client and the third party.
Common exam scenario: A client uses a third-party payment processor. The tester must determine if the payment API is in scope and how to test it without affecting live transactions.
Pitfalls and Common Mistakes
Assuming that third-party systems are out of scope by default. Always clarify in the rules of engagement.
Neglecting to test the integration points (e.g., APIs, VPNs) between the client and third party.
Overlooking physical access risks from vendors like cleaning or security staff.
Failing to review the client's vendor management policies, which may reveal gaps in due diligence.
Identify All Third Parties
During the scoping meeting, the tester works with the client to create a comprehensive list of all external entities that have access to the client's systems or data. This includes cloud providers (AWS, Azure, GCP), SaaS applications (Salesforce, Office 365), hardware vendors (Cisco, Dell), managed service providers (MSPs), and even contractors like cleaning or security staff. The tester should ask for contracts, SLAs, and network diagrams that show third-party connections. This step is critical because any omitted third party could become an unassessed attack vector.
Define Scope Boundaries
The tester and client must explicitly decide which third parties are in scope for the penetration test. This decision is documented in the Rules of Engagement (RoE). Factors include the test objectives (e.g., external vs. internal), the sensitivity of data handled by the third party, and the client's contractual rights to test the third party. The scope may include only the integration points (e.g., APIs, VPN tunnels) or extend to the third party's entire infrastructure if permitted. The tester must note any restrictions, such as not testing during business hours to avoid service disruption.
Obtain Legal Authorization
Before any testing begins, the tester must obtain written permission from both the client and the third party. This is often a separate letter of authorization or an addendum to the main contract. The authorization should specify the IP ranges, systems, and testing methods allowed. Without this, testing may violate the Computer Fraud and Abuse Act (CFAA) or similar laws. The tester should also ensure that the third party's SLA does not prohibit security testing. This step is where many penetration tests fail if not properly documented.
Assess Third-Party Security Posture
The tester reviews the third party's security documentation, including SOC 2 reports, ISO 27001 certifications, and incident response plans. Technical assessments may include external vulnerability scans of the third party's public-facing assets, testing API endpoints for OWASP Top 10 vulnerabilities, and checking for misconfigurations like default credentials or exposed admin panels. The tester also evaluates the third party's access controls, such as whether MFA is enforced for vendor accounts. This step identifies weaknesses that could be exploited to compromise the client.
Exploit Third-Party Access
If the assessment reveals vulnerabilities, the tester attempts to exploit them to gain access to the client's environment. For example, if a third-party VPN uses weak authentication, the tester might brute-force credentials or use a stolen session token. Once inside the third-party network, the tester looks for trust relationships, such as shared Active Directory trusts or direct network connections to the client. The goal is to demonstrate how an attacker could pivot from the third party to the client's internal systems. This step requires careful coordination to avoid disrupting operations.
Report and Remediate
The final report includes findings related to third-party risks, categorized by severity. Each finding includes a description, evidence, and remediation recommendations. Common recommendations include enforcing MFA for all vendor access, segmenting third-party network connections, conducting regular vendor risk assessments, and requiring SBOMs for software components. The report also highlights any legal or contractual gaps identified. The tester may also provide a timeline for remediation based on the client's risk appetite.
Enterprise Scenario 1: Cloud Service Provider Integration
A large financial institution uses Amazon Web Services (AWS) for data analytics. During a penetration test, the scope includes the client's AWS environment, but the tester must also assess the integration with a third-party data visualization tool hosted on AWS. The problem: the third-party tool has an API that the client's application calls to generate reports. The tester discovers that the API uses a hardcoded API key in the client's source code, which is stored in a public GitHub repository. The tester exploits this to access the third-party tool's admin panel, revealing sensitive financial data. Remediation: rotate the API key, move the key to AWS Secrets Manager, and enforce IAM roles instead of long-lived keys. This scenario highlights the importance of testing third-party integrations and the risk of exposed credentials.
Enterprise Scenario 2: Managed Service Provider (MSP) Access
A healthcare organization outsources its IT management to an MSP that uses a remote monitoring and management (RMM) tool. The RMM tool has a direct agent installed on every server and workstation. During a red team exercise, the tester targets the MSP's infrastructure. The MSP's RMM portal is protected only by a single password (no MFA). The tester performs a credential stuffing attack using leaked credentials from a previous breach and gains access to the RMM console. From there, the tester deploys a script to all client endpoints, simulating ransomware. The client's network is fully compromised. The fix: enforce MFA on the RMM portal, segment the MSP's network from the client's network, and require the MSP to undergo annual penetration tests.
Scenario 3: Software Supply Chain Attack
A software company uses an open-source library (lodash) in its product. The tester reviews the SBOM and finds that the library version is outdated and has a known Remote Code Execution (RCE) vulnerability (CVE-2021-23337). The tester crafts an exploit and gains a foothold on the company's build server, then modifies the build script to include a backdoor in the final product. This demonstrates how a single vulnerable third-party component can compromise the entire supply chain. Remediation: update the library, implement automated dependency scanning (e.g., Snyk, OWASP Dependency-Check), and sign software releases.
What PT0-002 Tests on This Topic (Objective 1.2)
The exam expects you to understand how third-party and supply chain risk influences the planning and scoping of a penetration test. Key areas:
Identifying which third parties are in scope based on the client's environment.
Understanding legal and contractual requirements for testing third-party systems.
Recognizing the importance of vendor risk assessments, SLAs, BPAs, and SBOMs.
Knowing common attack vectors through third parties (piggybacking, API abuse, malicious updates).
Common Wrong Answers and Why Candidates Choose Them
"Third-party systems are always out of scope unless explicitly included." This is true, but candidates often assume that if the client doesn't mention a third party, it's automatically out of scope. The correct approach is to proactively ask about all third-party relationships during scoping. The exam tests whether you know to identify and document them.
"A penetration test of a third party requires only the client's permission." Wrong. The third party must also authorize the test. Without it, testing is illegal. Candidates may forget the need for dual authorization.
"Supply chain risk only applies to software vendors." False. It includes hardware, cloud providers, and physical security contractors. The exam may present a scenario with a cleaning company or a hardware vendor.
"An SLA is sufficient to ensure third-party security." SLAs define service levels, not security controls. A vendor risk assessment or SOC 2 report is needed for security assurance.
Specific Numbers, Values, and Terms That Appear Verbatim
Business Partner Agreement (BPA) – the legal document outlining data handling.
Software Bill of Materials (SBOM) – a list of components used in software.
SOC 2 Type II – a report on a service organization's controls over time.
ISO 27001 – an information security management standard.
NIST SP 800-53 – supply chain risk controls (SR-1 to SR-12).
Edge Cases and Exceptions
Shared responsibility model: In cloud testing, the tester must know what the provider secures vs. the client. For example, AWS secures the hypervisor, but the client secures the guest OS. The scope may include only the client's portion.
Zero-day in third-party software: If a tester discovers a zero-day in a third-party component, they must follow responsible disclosure procedures and inform both the client and the vendor.
Third-party data processors: Under GDPR, the client is responsible for ensuring third-party processors comply. The tester may need to assess data handling practices.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If an answer option says "only the client's authorization is needed," eliminate it because third-party testing requires dual authorization.
If an option claims "vendor risk assessment is optional," eliminate it because it's a critical part of due diligence.
If an option suggests that "SBOMs are only for open-source software," eliminate it because SBOMs can include proprietary components as well.
If an option states "third-party risk is not part of penetration testing scope," eliminate it because objective 1.2 explicitly includes it.
Third-party risk must be explicitly addressed during the scoping phase of a penetration test.
Both the client and the third party must authorize the penetration test in writing.
Vendor Risk Assessments (VRAs) evaluate security posture; SLAs define performance metrics.
A Software Bill of Materials (SBOM) helps identify vulnerabilities in third-party components.
Common third-party attack vectors include piggybacking, API abuse, and malicious updates.
The SolarWinds attack is a prime example of supply chain compromise via software updates.
NIST SP 800-53 provides supply chain risk management controls (SR-1 to SR-12).
These come up on the exam all the time. Here's how to tell them apart.
Vendor Risk Assessment (VRA)
Evaluates the security posture of a vendor
Includes review of certifications, policies, and incident response
Performed before engagement and periodically thereafter
Focuses on security controls and risk mitigation
May include on-site audits or penetration tests
Service Level Agreement (SLA)
Defines performance metrics like uptime and response time
Does not typically address security controls
Is a contractual obligation for service delivery
Focuses on availability and performance
May include penalties for non-compliance
Software Bill of Materials (SBOM)
Lists all components used in software, including versions
Used to identify known vulnerabilities (CVEs) in dependencies
Proactive: created during development
Helps in supply chain risk management
Does not actively test for vulnerabilities
Vulnerability Scan
Actively scans systems for known vulnerabilities
Uses tools like Nessus or OpenVAS
Reactive: performed on deployed systems
Identifies missing patches and misconfigurations
May produce false positives
Mistake
Third-party risk is only relevant for software vendors.
Correct
Third-party risk includes any external entity with access to your environment, including cloud providers, hardware vendors, managed service providers, and even physical contractors like cleaning or security staff. All of these can be attack vectors.
Mistake
If a client uses a cloud provider, the cloud provider's security is automatically the client's responsibility.
Correct
Under the shared responsibility model, the client is responsible for securing their data, configurations, and access controls within the cloud. The provider secures the infrastructure. The client must still assess the provider's security posture and ensure their own configurations are secure.
Mistake
A Service Level Agreement (SLA) is sufficient to guarantee third-party security.
Correct
SLAs define performance metrics like uptime and response times, but they do not guarantee security controls. A vendor risk assessment (VRA) and certifications like SOC 2 or ISO 27001 are needed to evaluate security.
Mistake
Penetration testing of a third-party system only requires the client's permission.
Correct
Both the client and the third party must provide written authorization. Testing without the third party's consent is illegal and violates laws like the CFAA.
Mistake
Supply chain risk only applies to large enterprises with many vendors.
Correct
Supply chain risk applies to any organization that uses third-party products or services. Small businesses are often more vulnerable because they may lack resources for thorough vendor assessments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you need explicit written permission from both the client and the third party. Without it, testing may violate laws like the Computer Fraud and Abuse Act (CFAA). Always include third-party authorization in the Rules of Engagement.
An SBOM is a formal record of all components used in building software, including open-source libraries and their versions. It is important because it allows you to quickly identify known vulnerabilities (CVEs) in third-party components. For example, if a library has a critical RCE vulnerability, you can check your SBOM to see if you are affected.
Determine which parts are in scope: the client's configurations, applications, and data within the cloud. The cloud provider's infrastructure is typically out of scope unless you have a separate agreement. Use the shared responsibility model to define boundaries. Ensure you have authorization to test the client's resources.
A VRA evaluates a vendor's security posture, including certifications, policies, and incident response capabilities. An SLA defines performance metrics like uptime and response times. A VRA is about security, while an SLA is about service delivery. Both are important, but they serve different purposes.
Yes, MSPs often have broad access to multiple client networks. If the MSP's security is weak (e.g., no MFA on remote access tools), an attacker can compromise the MSP and then pivot to all client environments. This is a common attack vector, as seen in the 2021 Kaseya ransomware attack.
Include findings related to third-party vulnerabilities, such as weak authentication, exposed APIs, or outdated components. Provide evidence and remediation steps, such as enforcing MFA, segmenting networks, and conducting regular vendor assessments. Also note any legal or contractual gaps.
Hardware supply chain risk includes counterfeit components, tampered devices, or backdoors inserted during manufacturing. For example, a network switch could contain a hardware implant that allows remote access. Testing may involve verifying firmware integrity and checking for unauthorized modifications.
You've just covered Third-Party and Supply Chain Risk in Scope — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?