mediumMultiple Select
CS0-003 Practice Question: Which three of the following are best practices…
Which three of the following are best practices for integrating vulnerability scanning into a continuous integration/continuous deployment (CI/CD) pipeline? (Choose three.)
⚠ Common exam trap
CompTIA often tests the misconception that security scanning should be deferred to later stages (like production) to avoid slowing down development, but the correct approach is to integrate scanning early and often (shift-left) while using automated gates to maintain both speed and security.
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
✓
Embedding static application security testing (SAST) into the build phase to catch code-level vulnerabilities early
Embedding SAST into the build phase is a best practice because it allows developers to identify and fix code-level vulnerabilities (e.g., SQL injection, buffer overflows) early in the development lifecycle, reducing remediation cost and preventing insecure code from progressing further down the pipeline. This shift-left approach aligns with DevSecOps principles by catching flaws before they reach integration or production environments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Scanning only the production environment after deployment to ensure real-world security
Why it's wrong here
Relying solely on post-deployment production scanning violates the fundamental DevSecOps principle of shifting security left. Detecting vulnerabilities only after code is live increases the risk of active exploitation and significantly raises remediation costs compared to catching flaws during the development phase.
- ✓
Embedding static application security testing (SAST) into the build phase to catch code-level vulnerabilities early
Why this is correct
Integrating SAST into the CI/CD build pipeline allows for automated, non-runtime analysis of source code, binaries, or byte code. This practice ensures that common coding flaws, such as injection vulnerabilities and insecure cryptographic implementations, are identified and remediated before the software is compiled or packaged.
- ✓
Using container image scanning tools to detect known vulnerabilities in base images before deployment
Why this is correct
Container image scanning analyzes base images and application layers against known CVE databases prior to deployment. This prevents the introduction of outdated packages, misconfigured libraries, or embedded secrets into the runtime environment, securing the underlying microservices infrastructure.
- ✗
Disabling all vulnerability scanning during development to accelerate build times
Why it's wrong here
Disabling security scans during development to prioritize speed creates massive technical and security debt. This approach delays critical feedback to developers, resulting in complex, deeply integrated vulnerabilities that are far more difficult and expensive to remediate during later stages of the lifecycle.
- ✓
Automating dynamic application security testing (DAST) in a staging environment that mirrors production
Why this is correct
Automating DAST in a representative staging environment allows security teams to evaluate the running application for runtime vulnerabilities, such as cross-site scripting and broken authentication, under realistic conditions. This approach identifies deployment-specific flaws without risking the availability or integrity of the live production environment.
- ✗
Scanning dependencies only when a new vulnerability disclosure is published
Why it's wrong here
Relying on reactive scanning triggered only by public disclosures leaves organizations exposed to zero-day exploits and missed advisories. Software composition analysis (SCA) must be continuously automated within the CI/CD pipeline to ensure that third-party libraries and transitive dependencies are constantly evaluated against up-to-date threat intelligence.
Go deeper
Related to this question
Learn chapter
Patch and Remediation Workflows
Key term
SAST
Static Application Security Testing is a white-box method of analyzing source code, bytecode, or compiled binaries for security vulnerabilities without executing the program.
Key term
Remediation
Remediation is the process of fixing or eliminating vulnerabilities, misconfigurations, or security weaknesses in an IT environment.
About these practice questions
One of 701 original CS0-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CS0-004 practice question is part of Courseiva's free CompTIA 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 CS0-004 exam.