mediumMultiple ChoiceObjective-mapped
CISSP Practice Question: A software development company uses a continuous…
A software development company uses a continuous integration/continuous deployment (CI/CD) pipeline that automatically builds and deploys code to production after passing automated tests. The code repository contains proprietary algorithms and customer data. A recent incident was traced to an attacker who injected malicious code into a library that was pulled from a public package repository during the build process. The company wants to prevent similar supply chain attacks without significantly slowing development. Which of the following is the BEST course of action?
⚠ Common exam trap
ISC2 often tests the distinction between reactive security controls (like SAST or vulnerability scanning) and proactive supply chain controls (like private repositories with integrity verification), and the trap here is that candidates may choose SAST (option B) because it sounds technical and comprehensive, but it fails to prevent the initial injection of malicious code during the build process.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implement a private repository that mirrors approved open-source libraries and enforces signature verification and hash checks before allowing use
Implementing a private repository that mirrors only approved, vetted open-source libraries with enforced signature verification and hash checks directly addresses supply chain attacks by ensuring that only trusted, integrity-verified code enters the build pipeline. This approach prevents malicious code from public repositories from being pulled automatically, without requiring manual review of every library (which would slow development) or relying on post-build scanning that cannot prevent the initial injection. It aligns with the principle of secure software supply chain management by establishing a trusted source of components.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require all developers to perform manual code review of every third-party library before inclusion
Why it's wrong here
Requiring all developers to perform manual code review of every third-party library is inherently inefficient and often ineffective for detecting sophisticated, intentionally malicious code hidden within complex dependencies. The sheer volume of libraries and their transitive dependencies, coupled with the specialized security expertise required for each, makes comprehensive manual review impractical and highly prone to human error, especially when facing an adversary actively trying to evade detection.
- ✗
Perform static application security testing (SAST) on the entire codebase including libraries
Why it's wrong here
Static Application Security Testing (SAST) tools primarily analyze source code for common vulnerabilities, coding errors, and adherence to security best practices within the application's logic. While SAST can identify some security flaws in libraries, it is not specifically designed or optimized to detect deliberately injected malicious logic or backdoors, which are often obfuscated to evade automated analysis focused on known patterns of unintentional flaws.
- ✗
Increase the frequency of vulnerability scanning on the production environment and delay deployment of any library that has a deprecation notice
Why it's wrong here
Increasing the frequency of vulnerability scanning on production environments is a reactive measure, identifying known vulnerabilities in deployed systems rather than proactively preventing the initial introduction of malicious code during the development or build process. Similarly, delaying deployment due to deprecation notices addresses maintenance and potential future compatibility issues, but it does not prevent a currently malicious, non-deprecated library from entering the software supply chain.
- ✓
Implement a private repository that mirrors approved open-source libraries and enforces signature verification and hash checks before allowing use
Why this is correct
Implementing a private repository that mirrors approved open-source libraries establishes a controlled and trusted software supply chain, preventing direct reliance on potentially compromised public sources. Enforcing signature verification confirms the authenticity of the package's origin, while hash checks guarantee the integrity of the content, ensuring no unauthorized modifications or malicious injections have occurred. This proactive approach effectively blocks compromised or malicious packages from entering the development environment.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CISSP question from scratch — 747 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CISSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CISSP exam.