Shared Responsibility and Scope of Testing

Why This Topic Matters
Modern software is rarely built entirely in-house. Organizations consume cloud platforms, open-source libraries, commercial off-the-shelf (COTS) components, outsourced development, and third-party APIs. Every one of these dependencies introduces risk that someone must own, test, and monitor. The shared responsibility model defines who is accountable for which security controls, and the scope of testing defines what the acquirer may, must, or must not test. Misunderstanding either leads to the classic failure mode in supply chain security: everyone assumes someone else tested it. The CSSLP exam (Domain 8: Secure Software Supply Chain) tests whether you can clearly allocate responsibility, define contractual testing boundaries, and avoid gaps and overlaps.

What Shared Responsibility Means
Shared responsibility is the explicit division of security duties between a supplier (cloud provider, vendor, outsourcer, open-source maintainer) and the acquirer (your organization). Key principles:
• Responsibility can be delegated; accountability cannot. Even if a vendor builds and tests a component, the acquiring organization remains accountable to its customers and regulators for the security of the final product.
• The split varies by service model. In IaaS the provider secures physical infrastructure, hypervisor, and network fabric, while the customer secures the OS, middleware, applications, data, and identities. In PaaS the provider also covers the OS and runtime; the customer owns application code, configuration, and data. In SaaS the provider owns almost everything except data classification, user access management, and secure configuration/usage.
• Common 'always yours' items: data, identity and access management, client-side configuration, and verifying that the vendor actually meets its obligations.
• Documentation is the control. The split must be written into contracts, Service Level Agreements (SLAs), Statements of Work (SOWs), and security addenda, not merely assumed.

What Scope of Testing Means
Scope of testing defines the boundaries of what the acquirer will test on supplied software and services, and what the supplier is obligated to test and evidence. Elements include:
• Components in scope: which modules, APIs, interfaces, integration points, and environments (dev, staging, production) may be tested.
• Testing types permitted: static analysis (SAST), dynamic analysis (DAST), penetration testing, fuzzing, software composition analysis (SCA), code review, configuration review. Cloud providers typically prohibit testing shared infrastructure, denial-of-service tests, or testing other tenants.
• Rules of engagement: authorization, timing windows, notification requirements, data handling, and stop conditions.
• Evidence in lieu of testing: when you cannot test (e.g., SaaS back end), you rely on third-party attestations such as SOC 2 Type II, ISO/IEC 27001, FedRAMP, penetration test summaries, SBOMs (Software Bill of Materials), and vulnerability disclosure processes.
• Right to audit / right to test clauses: contractual language that preserves the acquirer's ability to verify.

How It Works in Practice
1. Identify the supply chain. Enumerate all suppliers, components, and services (SBOM, dependency inventory, vendor register).
2. Classify the engagement model. COTS, open source, outsourced development, IaaS/PaaS/SaaS, or managed service. Each has a different default responsibility split.
3. Map responsibilities. Build a responsibility matrix (often a RACI) covering secure design, secure coding, testing, vulnerability management, patching, incident response, logging, and data protection. Mark each item as supplier, acquirer, or shared.
4. Define testing scope contractually. State what the supplier must test and report, what the acquirer will independently test, acceptance criteria, and remediation SLAs. Include the right to receive vulnerability notifications and to perform or commission penetration tests where permitted.
5. Perform acquirer-side verification. Test what you own and what you are allowed to test: your code, your configuration, integration points, authentication flows, data handling. Use SCA to verify third-party library versions and known CVEs.
6. Collect and evaluate evidence for what you cannot test. Review attestations for currency, scope coverage, and exceptions. A SOC 2 report that excludes the specific service you use is not sufficient evidence.
7. Close gaps and overlaps. A gap is a control nobody owns; an overlap is wasted effort or conflicting changes. Both are addressed by updating the matrix and the contract.
8. Monitor continuously. Responsibilities shift as architectures change, vendors update terms, or new components are added. Reassess at renewals, major releases, and after incidents.

Key Terms to Recognize
• Shared responsibility model – provider/customer control allocation, especially in cloud.
• Accountability vs. responsibility – accountability stays with the acquirer.
• Rules of engagement – authorized scope and constraints for testing.
• Attestation / third-party assurance – SOC 2, ISO 27001, FedRAMP, CSA STAR.
• SBOM – component inventory enabling scoped SCA.
• Right to audit – contractual verification clause.
• Acceptance testing – acquirer verification before deployment of supplied software.

Exam Tips: Answering Questions on Shared Responsibility and Scope of Testing
• Accountability never transfers. If an answer implies the organization is no longer accountable because a vendor or cloud provider handles security, it is wrong. The vendor may be responsible for controls; your organization remains accountable for outcomes.
• Match the service model. When a question names IaaS, PaaS, or SaaS, mentally draw the stack. The lower the customer sits in the stack (IaaS), the more they must test themselves; the higher (SaaS), the more they rely on attestations and configuration/identity/data controls.
• Data, identity, and configuration are almost always the customer's job. If the question asks what the customer must still secure in SaaS, look for data classification, access management, and secure configuration.
• 'Documented in the contract' beats 'assumed' or 'verbally agreed.' The best answer for defining responsibilities or testing scope is typically a contract, SLA, SOW, or security addendum, established before acquisition.
• Never test without authorization. Any answer suggesting penetration testing a provider's shared infrastructure or another tenant without explicit written permission is wrong and may be illegal. Look for 'obtain authorization' or 'review the provider's testing policy' options.
• When you cannot test, verify through evidence. If the acquirer has no access to the vendor's code or back end, the correct approach is to obtain and evaluate independent attestations, test reports, SBOMs, and vulnerability disclosure processes, and to verify their scope matches what you use.
• Gaps are the hidden danger. Questions describing an incident 'that neither party tested' are pointing to a responsibility gap; the fix is a documented responsibility matrix, not blaming the vendor.
• Prefer the 'first' or 'most important' logical step. CSSLP questions often ask what to do first. Typically: identify/inventory components and define responsibilities before testing, and define scope before executing tests.
• Open source has no vendor to hold responsible. For open-source components, the acquirer assumes responsibility for evaluation, SCA, and monitoring; answers that rely on 'the maintainer's SLA' are distractors.
• Acceptance testing applies to supplied software too. Even vendor-tested COTS should undergo acquirer acceptance and integration testing within the agreed scope before production deployment.
• Watch for absolutes. 'The provider is responsible for all security' or 'the customer must test everything' are both usually wrong; the exam favors balanced, documented, risk-based allocation.
• Think like a manager, not just an engineer. CSSLP emphasizes governance. When two answers seem technically valid, choose the one that establishes policy, contractual clarity, or risk-based prioritization over a purely technical fix.

Quick Self-Check
Can you state, for a given service model, which layers you must test and which you must verify through attestation? Can you explain why accountability stays with the acquirer? Can you name three artifacts that define testing scope (contract/SOW, rules of engagement, vendor testing policy)? If yes, you are prepared for this objective.