Reproduce a reported vulnerability in an isolated copy of your product, never on production, using the researcher's own steps and a log of everything you do. If it works, you have a confirmed case. If it fails, ask for the specific detail you are missing before you decide it is invalid.
Why not just try it on production
A proof of concept is code or requests written to demonstrate a flaw. Running someone else's proof of concept against live systems can alter data, trigger alerts that confuse your on-call team, or expose customer information. OWASP's guidance also warns that organizations can struggle to tell legitimate testing from real attacks, which is a good reason to keep your own testing separate and labeled.
A safe reproduction routine
- Build a throwaway environment. Use the same version the report names. A recent snapshot with fake data is enough for most web and API bugs.
- Read the whole report first. Note the version, the account type used, any required configuration and the claimed outcome.
- Run the steps exactly as written. Change one thing at a time only after you have tried the original.
- Record what happens. Save requests, responses, timestamps and screenshots. This is your evidence if the finding is disputed later.
- Check neighbors. If one endpoint is affected, look for similar endpoints, other versions and other tenants. Reports often show one instance of a pattern.
- Write a one line verdict. Confirmed, partially confirmed, not reproduced, or already known.
When it does not reproduce
Do not reply with "cannot reproduce" and stop. Common causes are a different version, a different account role, a missing header, a feature flag, or timing. Ask for:
- the exact version or build identifier
- the account role used
- raw requests and responses instead of screenshots
- anything the researcher changed in settings
OWASP's cheat sheet notes that reports should contain enough detail to be understood and reproduced, and that organizations may ask for clarification as part of the ongoing exchange. You can also ask whether they are willing to retest after you adjust something.
Records that help later
| Item | Why keep it |
|---|---|
| Original report | The starting point for scope and credit |
| Your reproduction log | Shows the finding was real or not |
| Environment version | Tells you which releases are affected |
| Date and person | Supports your response time metrics |
What counts as confirmed
Confirmation means you saw the claimed effect in your own environment. It does not yet mean you agree with the researcher's severity. Treat those as two separate questions, and see re-scoring a researcher's severity for the second.
Where tooling helps
If the root cause is a vulnerable dependency, you can check whether it is present in the affected release by looking at that release's software bill of materials. Safeguard's SBOM and dependency scanning can list what a given build contains, and a free scan is available. That is only a way to confirm exposure, not a replacement for running the steps.
Quick check
Can I reproduce a report on a staging environment that shares a database with production?
Avoid it. If staging shares data or credentials with production, the test can still touch real records. Use an isolated copy with fake data.
Should I tell the researcher I am testing?
A short note that you are reproducing is polite and helps set expectations. You do not need to share your test details.
Sources
Last reviewed: 19 October 2026.
