The gap between a security team reporting a problem and an engineering team fixing it is almost never disagreement. It is that the report cannot be acted on without a conversation, and the conversation takes three weeks to schedule.
The reproduction test
There is one honest test for a finding. Hand it to an engineer who has never seen it, on a Friday, with nobody available to ask. If they can reproduce it, it is a proof. If they open Slack, it is a claim.
Most reports fail this. They describe the vulnerability class accurately, cite the right CWE, include a screenshot of a popup, and omit the exact request that produced it. The engineer has to reconstruct the attack from prose before they can start fixing it.
What has to be in it
- The exact request, including headers, in a form that can be replayed.
- The state it needed: which account, which role, what had to be true first.
- The response that proves it, not a description of the response.
- The blast radius: what this reaches, stated as systems and data, not as a severity word.
- The revert: what the test created, and confirmation that it is gone.
Why this decides the priority
Engineering teams triage by cost of understanding, whether or not anyone admits it. A ticket that can be reproduced in four minutes gets picked up this sprint. A ticket that needs a meeting to interpret slides, regardless of its severity label, because the first step is not fixing, it is scheduling.
Severity decides what should be fixed first. Reproducibility decides what actually is.
The clean up nobody asks about
A test that proves impact has to create something: an account, a session, a file, a token. The proof is incomplete until that is removed and the removal is recorded. Ask any provider what their evidence looks like after the engagement ends. If the answer is that the artefacts are still there, the test left you with new surface.