An analyst finds a critical vulnerability in an internet-facing service. The vendor has not released a patch, but the vendor advisory lists a configuration change that reduces exposure. What should the vulnerability management team do first?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a temporary seatbelt while the airbag is still being recalled: you don't just sit there and hope. You apply the workaround, document it, and keep the risk on your radar until the real patch lands. The trap is treating a partial fix as a reason to do nothing.
Full Explanation
When a vendor patch is unavailable, prioritization shifts from immediate remediation to risk reduction. A documented vendor workaround that reduces exposure is a compensating control, not a final fix, so it should be applied, recorded in the vulnerability record, tied to an owner and expiration date, and reviewed once the patch is available. Waiting for the patch without interim control leaves known exposure open on an internet-facing service, which is inconsistent with risk-based vulnerability management. Accepting the risk while ignoring an available mitigation is also incorrect because risk acceptance is a formal decision made after evaluating controls, not a substitute for a low-cost workaround. Leaving the service unchanged and merely opening a ticket fails to reduce the likelihood or impact of exploitation and can be seen as passive risk accumulation. A false-positive closure is wrong because the vulnerability is confirmed; its patch status affects remediation method, not validity. Exam caveat: choose the action that reduces risk now while preserving traceability to the eventual patch. Operational check: record the workaround, CVSS context, business impact, compensating-control evidence, and a reassessment date in the vulnerability ticket.