During a CI/CD review, your vulnerability scanner reports a critical dependency with no known exploit in a non-internet-facing internal service. Engineering asks to deploy the release today. Which action best balances risk communication with development workflow?
Select an answer to reveal the explanation.
Short Explanation
Think of vulnerability reporting like traffic control: you don't stop every car because one lane is wet. You tell the driver what's risky, what's already protected, and when to fix it. If you block every scanner finding, developers will route around you, but context and a deadline make the fix actually ship.
Full Explanation
The correct approach is to communicate vulnerability findings in a risk-based, decision-ready way: what was found, how exploitable it is, what compensating controls exist, and what remediation timeline is acceptable. In a CI/CD pipeline, analysts often see scanner output that is technically severe but operationally mitigated, such as an internal service with no external exposure and no known exploit. The analyst's job is not to hide the finding or stop all work, but to give the release owner enough context to accept, mitigate, or defer the risk under policy.
Blocking every finding treats scanner severity as an absolute release gate, which ignores exploitability, environment, and existing controls; this can create alert fatigue and encourage workarounds. Sending a raw scanner export dumps technical detail without prioritization, leaving developers to guess business risk and likely missing the accountable owner. Escalating every pipeline finding to a change control board adds excessive ceremony for routine risk decisions and slows response without adding meaningful analysis.
Exam caveat: CS0-004 expects reporting that supports decisions, not just delivery of findings. Operational check: attach the finding, exploitability context, compensating controls, owner, and due date in the release ticket before approval.