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
You don’t let food leave the kitchen to find out if it’s 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
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 most effective gate is an automated vulnerability scan—using tools such as GitHub Advanced Security or Dependabot advisories—run as a required success-criterion check before the commit action is executed. 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 dependency review features are designed for.
Manual security review of every dependency update before the agent is allowed to commit 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.
The post-commit CI job that scans for vulnerabilities and reverts the commit if a CVE is found 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.
Restricting the agent to only apply updates for packages with a version bump of 0.0.x, patch-level updates, to minimize security risk 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.