cisspSoftware Development Security· 10 min read· 21 May 2026
Third-Party and Open-Source Software Risk: COTS, SaaS Procurement, and Supply Chain
Modern software is rarely built entirely from scratch. Organisations rely on commercial off-the-shelf (COTS) products, open-source libraries, and software-as-a-service (SaaS) applications to deliver functionality that would take years to develop internally. While this dramatically accelerates development, it also means that the organisation's security posture depends heavily on the security practices of software vendors and open-source maintainers over whom they have limited control. The CISSP exam tests the governance and risk management approach to acquired software security in Domain 8.
Risk Profiles Compared: COTS, Open-Source, and SaaS
Each category of acquired software has a distinct risk profile.
COTS (Commercial Off-The-Shelf) software is commercial software licensed from a vendor. The vendor is responsible for developing, testing, and maintaining the software, including security updates. COTS risk characteristics: the organisation has limited insight into the software's security testing practices or source code. Vulnerability disclosure depends on the vendor's processes — a vendor may be slow to disclose or patch vulnerabilities. The organisation is dependent on the vendor's continued existence and support. Licence terms may restrict security testing of the software. On the positive side, commercial vendors generally have security teams and formal security development processes, and they face reputational and financial incentives to maintain security.
Open-source software is software whose source code is publicly available and freely usable, modifiable, and distributable. Open-source risk characteristics: the source code is available for security review (a positive), but availability does not mean the code has been reviewed. Many open-source projects are maintained by a small number of volunteers with limited security expertise. Vulnerabilities may persist for years before being discovered and patched. When a vulnerability is disclosed, it is immediately visible to attackers as well as defenders. The Log4Shell vulnerability demonstrates the risk: a critical vulnerability in a widely used logging library (Log4j) affected thousands of applications that had incorporated it, often as a transitive dependency that development teams did not even know was present.
SaaS (Software as a Service) is software delivered over the internet and managed by a vendor. The customer uses the software through a web browser or API and does not manage the underlying infrastructure. SaaS risk characteristics: the customer has very limited control over the security of the application and infrastructure. Security depends almost entirely on the vendor's practices. The shared responsibility model applies: the vendor is responsible for the application and infrastructure security; the customer is responsible for data entered into the application, access management, and configuration. Security validation of SaaS is typically done through the vendor's third-party audit reports (SOC 2, ISO 27001) rather than direct assessment.
For the exam: all acquired software requires security assessment. The nature of the assessment differs by type: COTS through vendor questionnaires and audit reports, open-source through SCA and code review, SaaS through SOC 2/ISO 27001 reports and contractual controls.
Before acquiring any third-party software, the organisation should conduct security due diligence. The procurement security assessment typically includes:
Security questionnaire: a structured set of questions about the vendor's security practices, development processes, incident response capabilities, and compliance certifications. Frameworks like the Shared Assessments SIG or CSA CAIQ provide standardised questionnaire templates.
Audit reports: SOC 2 Type II reports demonstrate that an independent auditor has verified the vendor's security controls over a period of time. ISO 27001 certification demonstrates a certified ISMS. These reports provide assurance without requiring the customer to conduct their own audit.
Vulnerability disclosure programme: does the vendor have a programme for receiving and responding to externally reported vulnerabilities? A bug bounty programme or responsible disclosure policy indicates a mature security programme.
Patch management and disclosure history: how quickly does the vendor release patches for known vulnerabilities? What is their track record for disclosing vulnerabilities that affect customers? A vendor who consistently takes months to patch known critical vulnerabilities is a significant risk.
Contractual security requirements: the contract should specify security obligations: data handling requirements, breach notification timelines, right to audit, compliance with applicable regulations, liability for security failures, and software escrow (for critical COTS applications where the source code may be needed if the vendor ceases operations).
SaaS Security: Shared Responsibility in Vendor-Managed Applications
SaaS introduces a unique security challenge: the customer cannot apply traditional security controls (patching, hardening, network segmentation) to software they do not manage. Security governance in SaaS environments focuses on:
Access management: configuring the SaaS application's user access controls correctly, implementing MFA for all user accounts, using SSO integration to enable centralised access management and easy deprovisioning, and applying least privilege to administrative roles.
Data classification and handling: understanding what data is stored in each SaaS application and ensuring it is classified appropriately. Avoiding storing highly sensitive data in SaaS applications with insufficient security controls.
Configuration security: SaaS applications often have numerous security settings that are misconfigured by default. Sharing settings, external collaboration features, and data export capabilities should be reviewed and configured according to the organisation's security policy.
Vendor monitoring: monitoring the vendor's security communications for new vulnerability disclosures, patches, or configuration changes that affect the organisation's security posture.
CASecob integration: deploying a CASB to gain visibility into SaaS data flows, enforce DLP policies, and detect account compromises or insider threats in SaaS environments.
Open-Source Dependency Risks and the Log4Shell Lesson
The Log4Shell vulnerability (CVE-2021-44228), disclosed in December 2021, is the defining case study for open-source dependency risk. Log4j is a Java logging library used in millions of applications worldwide. The vulnerability allowed remote code execution with minimal exploitation complexity. When it was disclosed, organisations scrambled to identify every application that used Log4j — including as a transitive dependency — and patch it under emergency conditions.
The Log4Shell incident highlighted four key lessons for software security governance:
Organisations did not know what open-source components were in their applications. Many organisations could not quickly answer the question "do we use Log4j?" because they lacked a software bill of materials (SBOM). SCA tools and SBOMs are now recognised as essential.
Transitive dependencies are as risky as direct dependencies. Many affected applications did not directly use Log4j but used frameworks that used Log4j as a logging backend. Dependency management must include the full transitive dependency tree.
Patching open-source components requires the same discipline as patching commercial software. The update was available quickly, but deploying it required identifying all affected applications, testing the patch, and coordinating deployments — the same change management process as any other patch.
Vendor-supplied applications may also be affected. Third-party COTS and SaaS products that incorporated Log4j also needed to be patched by their vendors. Customers were dependent on vendor communication and timeliness.
Software Supply Chain Attacks: Build System Compromise
Software supply chain attacks target the build and distribution processes through which software is created and delivered to end users. Rather than attacking the target application directly, attackers compromise the tools, processes, or infrastructure used to build it.
Build system compromise: if an attacker gains access to a CI/CD pipeline or build server, they can insert malicious code into software artefacts without the development team's knowledge. The SolarWinds attack used this technique: the build environment was compromised to insert a backdoor into signed, legitimate software updates.
Dependency confusion: if an organisation uses internal package registries alongside public ones (npm, PyPI), an attacker can publish a malicious package to the public registry with the same name as an internal package but a higher version number. Build tools that check the public registry before the internal one will download and execute the malicious package.
Defences: build integrity controls (signing build artefacts and verifying signatures before deployment), build system isolation (preventing build systems from accessing the internet unnecessarily), dependency pinning (specifying exact versions and hashes of dependencies rather than version ranges), and binary provenance verification (using tools like SLSA — Supply Chain Levels for Software Artefacts — to verify the provenance of build artefacts).
Exam Tip
Acquired software still requires security assessment — 'we didn't write it' is not an acceptable risk posture. The exam tests that every category of acquired software (COTS, open-source, SaaS) carries risk that must be managed. For open-source, SCA and SBOM are the key controls. For SaaS, the shared responsibility model and third-party audit reports (SOC 2) are the governance mechanisms. Software supply chain attacks exploit the trust that organisations place in their build tools, dependencies, and vendors.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Software Development Security
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.