To get a security fix scheduled, bring the product manager four facts: who is exposed, what waiting risks, how big the fix is, and a proposed date. Skip the severity debate. Product teams respond to a clear trade-off and a small, well-scoped ask far better than to an alarming score.
What product managers are weighing
A product manager has a fixed capacity and a list of commitments to customers. A security request is one more claim on that capacity. They are not ignoring security. They are comparing it to everything else, and they usually have less information about it than you do. Your job is to make the comparison easy.
The four facts
| Fact | Good version |
|---|---|
| Exposure | The affected service is internet-facing and handles customer login |
| Cost of waiting | If exploited, attackers could read account data. Exploitation of this flaw is [known or not known], per a cited source |
| Size of the fix | A version bump in one service, about two days including tests |
| Proposed date | In the sprint starting Monday, with a fallback date if that slips |
Quote severity scores sparingly. FIRST notes that a base score represents only the intrinsic characteristics of a vulnerability and should not be used alone to assess risk (FIRST). Facts about your own exposure persuade more.
Offer options, not ultimatums
Give product two or three paths.
- Fix now, with a stated disruption to the roadmap.
- Apply a temporary mitigation now, schedule the full fix within a defined window.
- Accept the risk for a stated period, with a named approver and a review date.
The third option matters. When a person is allowed to say "accept" openly, with their name on it, they often choose the fix. When they are not, they stall.
Use exploitation evidence honestly
CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities known to be exploited in the wild and recommends use as an input to prioritization (CISA). If the flaw is listed, say so. If it is not, say that too. Do not imply exploitation you have not seen.
Make the fix cheap
Much friction comes from the size of the change. Prepare the pull request, the test plan and the rollback plan before the meeting. A fix that arrives as a ready branch is easier to schedule than a request to investigate.
After the meeting
Write the decision in the ticket: what was chosen, who approved it, the date. If the date moves, the ticket moves with a reason. A pattern of quietly slipped dates is the signal to escalate through the normal management route, not through a louder severity score.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see a fix presented as a ready change. A prepared fix makes the scheduling conversation shorter.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests. It is off by default and every category starts on Manual, so a person approves before anything merges. Pair it with policies and gates so agreed deadlines are visible. The free scan is at gold.safeguard.sh/scan.
Quick check
What if product says no?
Record the risk acceptance with an approver, a reason and a review date, and keep the temporary mitigation in place.
Should security quote the score to win the argument?
Quote it with its source, but lead with exposure and exploitation evidence.
Sources
Last reviewed: 19 October 2026.
