9.4. Acquired and Third-Party Software
💡 First Principle: Your organization's security perimeter includes every piece of software running in your environment — regardless of who wrote it. A vulnerability in a commercial-off-the-shelf (COTS) product, an open-source library, or a SaaS vendor's platform is your vulnerability once it processes your data or runs on your infrastructure. The attack surface does not distinguish between code your developers wrote and code a vendor licensed to you.
Third-party software security is a supply chain problem: you are trusting that the vendor's development practices, security testing, and patch management meet a standard you often cannot independently verify. The CISSP tests whether you understand how to assess, manage, and contractually enforce third-party software security.
Why this matters: Third-party software assessment, vendor due diligence, SBOM requirements, and software supply chain attacks (SolarWinds, Log4Shell, XZ Utils) are increasingly tested topics. The exam expects you to understand both the contractual and technical dimensions of third-party software risk.
⚠️ Common Misconception: "Using a library or framework automatically makes code secure." Frameworks provide security features (CSRF tokens, parameterized queries, output encoding) — but only if developers use them correctly. A framework with built-in ORM protection against SQL injection provides no benefit if a developer bypasses the ORM to write raw SQL queries. Security is not inherited by inclusion; it is achieved by correct usage.
