A security-patching agent applies dependency updates across repositories and automatically commits changes. During a post-incident review, it is discovered that the agent committed a version that introduced a known CVE. Which evaluation gate would have most effectively prevented this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
You do not let food leave the kitchen to find out if it is spoiled — you check it before it goes out. On the exam: success criteria checks (including security scans) must run before commit actions are executed, not after; post-commit scanning is too late when the goal is prevention.
Full explanation below image
Full Explanation
The core principle here is that evaluation gates must run before irreversible actions. Once a commit is pushed to a repository, rolling it back requires deliberate effort and may have already triggered downstream consumers. The correct design (option B) is to run an automated vulnerability scan as a pre-commit success criterion: the agent stages the dependency change, runs the scan against the updated dependency tree, checks the result against the CVE database, and only proceeds to commit if no new vulnerabilities are introduced. This is exactly what tools like GitHub Advanced Security dependency review are designed for.
Option A (manual security review) is not scalable for an automated patching agent that may process dozens of repositories. It also introduces human latency into a pipeline designed for automation. While human review has a place for high-risk changes, automated scanning covers the CVE detection use case without blocking velocity.
Option C (post-commit CI job with revert) is a common pattern but not the most effective prevention gate. The agent has already committed by the time the scan runs — the CVE is now in the repository's git history, potentially already pulled by other developers, and the revert itself may introduce complications. Pre-commit scanning prevents the CVE from entering the codebase at all.
Option D (patch-level-only updates) is a risk-reduction heuristic, not an evaluation gate. CVEs can exist in any version, including patch releases — restricting to 0.0.x updates does not guarantee the absence of new vulnerabilities and may leave the agent unable to apply security fixes that require minor or major version bumps.