Validate a report by reproducing the issue on the stated version, confirming the attacker needs no privileges the report ignores, checking which other versions and code paths share the flaw, and recording the outcome. Only then decide priority and start a fix. A fix written before validation often fixes the wrong thing.
Where validation sits in the process
The CERT Guide to Coordinated Vulnerability Disclosure lists the phases as discovery, reporting, validation and prioritization, remediation, public awareness and deployment. Validation comes first after the report arrives: an analyst confirms the report is accurate before action is taken, then ranks it against other reports. Treat those as two separate jobs. Confirming is about truth. Ranking is about urgency.
The validation steps
- Pin the version. Ask which release the reporter tested. Reproduce on that exact version first, then on current.
- Build a clean environment. Use a fresh install or container with default settings. Many reports depend on a setting the reporter changed.
- Follow the reporter's steps literally. If the steps are unclear, ask a question instead of guessing.
- Check the preconditions. Does the attacker need an account, a particular role, network position, or user interaction? Write each one down.
- Measure the impact. What can the attacker read, change or break? Record the real result, not the worst case in the report.
- Find the siblings. Search the code for the same pattern. One reported flaw often has copies.
- Check older and newer versions. Note the first and last affected release.
- Write the outcome. One of the outcomes in the table below.
Validation outcomes
| Outcome | Meaning | Next step |
|---|---|---|
| Confirmed | You reproduced it | Rank it, start a fix |
| Confirmed, lower impact | It works but needs more than the report claims | Rank honestly, explain to reporter |
| Cannot reproduce | Steps fail on your build | Ask for detail, set a date to close |
| By design | Behaviour is intended | Explain, consider whether the design is wise |
| Out of scope | Not your product or not covered | Redirect, see your policy |
| Duplicate | Already known or reported | Link the cases |
Keep the reporter in the loop
Tell the reporter the outcome in plain words, with the reason. A "cannot reproduce" with the exact version and settings you tried invites a better report. A "confirmed" with a rough sense of timing keeps goodwill. If you are unsure, say so.
Common mistakes
- Skipping reproduction because the reporter sounds expert.
- Reproducing on a build with debug settings that the product does not ship with.
- Closing a report as invalid because one step failed, without asking.
- Fixing the exact example and missing the underlying pattern.
Try it yourself
The exploitability check demo shows the same habit applied to scanner findings: asking whether a weakness can actually be reached and used. Click through it and watch how the verdict changes when the preconditions are not met.
Click through it at your own pace, or open it full screen.
Quick check
How long should validation take?
Set your own target and publish it. For a small team, a first answer within a few working days is realistic. What matters is that the reporter hears an update on the date you promised.
Can the reporter help validate?
Yes. Ask for a video, a script or a test case. Do not run exploit code from a stranger on a production system; use an isolated environment.
Safeguard's reachability analysis applies this idea to your dependencies, showing whether vulnerable code in a library is called by your application. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
