A retail company deploys an e-commerce API on public-cloud PaaS, processing data classified as restricted cardholder information. A recent penetration test found that a fixed dependency version pinned two years ago now carries a publicly disclosed vulnerability. The security lead wants to prevent this class of problem from recurring across the secure SDLC. Which practice most directly addresses vulnerable third-party components entering and remaining in the build?
AAdd dynamic application security testing against the running API to detect exploitation of the vulnerable component.
BRequire peer code review of every pull request before it is merged to the main branch.
CMaintain a software bill of materials and run automated software composition analysis in the build pipeline against a vulnerability feed.check_circle Correct
DEnable web application firewall rules in front of the API to block known attack signatures.
Select software composition analysis with a software bill of materials as the SDLC practice that catches vulnerable third-party dependencies. Pinned dependencies can become vulnerable long after they are chosen. A software bill of materials records what is in the build, and software composition analysis compares those components against a live vulnerability feed in the pipeline, so a newly disclosed flaw in a stale pin is flagged before release rather than found later by a penetration test.
Why A is wrong: Dynamic testing can sometimes reveal an exploitable path at runtime, but it inspects observable behaviour rather than the dependency inventory, so it may miss a vulnerable component that is present but not triggered by the test cases.
Why B is wrong: Peer review strengthens the quality of first-party code changes, but reviewers rarely track newly disclosed vulnerabilities in long-pinned transitive dependencies, so it does not systematically catch a component that turned vulnerable over time.
Why C is correct: A software bill of materials plus software composition analysis inventories every dependency and continuously checks pinned versions against known-vulnerability data, which is the practice designed to catch a component that becomes vulnerable after it was first pinned.
Why D is wrong: A web application firewall is a useful runtime mitigation and may blunt some exploits, but it is a compensating control that does not remove the vulnerable dependency from the build or prevent the next stale component from shipping.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCSP bank for this domain.
Because the source is closed, no independent assurance of the vendor's development practices is obtainable
errorWhy it is wrong: This overstates the limitation; independent attestations and audit reports exist precisely so buyers can gain assurance without source access, so the claim is false.
Enforce a web application firewall in front of the loan application to block malicious request payloads at the network edge
errorWhy it is wrong: A WAF filters inbound attack traffic at runtime but does nothing to detect a vulnerable or tampered library inside the build, so it addresses a different risk than the one stated.
Dynamic application security testing (DAST) run against the production endpoint after each release to probe for injection responses
errorWhy it is wrong: DAST does find injection at runtime, which makes it tempting, but it tests a deployed running instance rather than the source and runs after release, missing the goal of catching flaws in the source before deployment.