CISSP - Software Development Security (10% of the exam) - 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.

Exam traps in Software Development Security

Answers that look right on this material and are not. Each one is a distractor from a different question in the CISSP bank for this domain.

  • Mandate that developers manually review the change-log of every transitive dependency before each release goes to production.

    Why it is wrong: Tempting because manual review feels rigorous, but 400 transitive dependencies make this infeasible at release cadence, the reviews are inconsistent, and it does not prevent a typo-squatted or compromised package from entering the build between reviews.

  • Commission an independent penetration test of the production tenant before any contract or non-disclosure agreement is in place with the vendor.

    Why it is wrong: Tempting because a fresh test seems more current than a vendor-supplied summary, but testing a production tenant without contractual authority is unlawful and skips the higher-value contractual and assurance review that frames any later technical testing.

  • Run dynamic application security testing on every pull request and defer static analysis and secret scanning to a weekly scheduled scan of the main branch.

    Why it is wrong: DAST needs a deployed, running application and is too slow for pull-request gating, while deferring SAST and secret scanning lets vulnerabilities and leaked credentials merge to main long before they are detected.

Examworthy is not affiliated with or endorsed by ISC2. Original, blueprint-aligned practice material only.