CISSP - Software Development Security - Section 8.4

Assess the security impact of acquired software including commercial-off-the-shelf, open source, third-party, and managed services.

Assess the security impact of acquired software by evaluating commercial off-the-shelf (COTS), open source, third-party, and managed service components including SaaS, IaaS, and PaaS offerings. Apply consistent evaluation criteria - such as vendor patching cadence, licence terms, and dependency risk - before incorporating acquired software into the organisation's environment.

COTSopen sourcethird-party softwaremanaged servicesSaaS/IaaS/PaaS

Practice question for this objective

Free sampleSoftware Development Securitymedium

A logistics firm acquires a niche route-optimisation product from a small third-party software vendor. During contract negotiations the vendor refuses to provide source code, citing intellectual property concerns, but offers other forms of assurance. The security manager must recommend the strongest mechanism to protect the firm if the vendor later fails or stops supporting the product. What should the security manager recommend?

  • AInsist on a perpetual licence at no additional cost so the firm can continue running the existing binary indefinitely regardless of vendor status.
  • BRequire a source code escrow arrangement with a reputable agent and clearly defined release conditions tied to vendor insolvency or material support failure. Correct
  • CAccept an extended warranty that doubles the standard support period from one to two years in exchange for the firm signing a multi-year agreement.
  • DRequest that the vendor agree to share the source code only after a confirmed exploit in the product has been actively used against the firm.
Third-party software acquisitions should use source code escrow with defined release triggers to protect continuity and security maintenance if the vendor fails. Source code escrow with a reputable agent and unambiguous release conditions, such as vendor insolvency or material breach of support obligations, gives the acquiring organisation a pre-arranged path to obtain the code and continue maintenance. It addresses the central risk of small-vendor acquisitions, namely the loss of security patching capability if the vendor disappears, without forcing the vendor to surrender IP up front.

Why A is wrong: Tempting because a perpetual licence preserves use rights, but it does not address security patching, dependency updates, or operating-system compatibility once the vendor is no longer maintaining the binary, so the security posture decays even while use is permitted.

Why B is correct: Correct because a properly drafted escrow with explicit release triggers gives the acquirer a contractual route to obtain source for ongoing maintenance and security fixes if the vendor fails, balancing the vendor's IP concerns with the acquirer's continuity risk.

Why C is wrong: Tempting because a longer warranty improves short-term support, but it does nothing if the vendor goes out of business inside the warranty period, leaving the firm without source, patches, or remedy when it most needs them.

Why D is wrong: Tempting because it ties the release to a tangible event, but waiting for confirmed exploitation guarantees damage before remedy is available, and an active incident is the worst possible moment to start onboarding a new code base.

See more CISSP practice questions, answers explained.

More in this domain

Back to all Software Development Security objectives, or the CISSP cert hub.

Examworthy is not affiliated with or endorsed by (ISC)2. Original, blueprint-aligned practice material only.