Safeguard
Security Guides•

Triaging an incoming vulnerability report: a decision guide

Six questions a triage owner should answer for every external vulnerability report: real, in scope, new, exploitable, reachable and how urgent.

Safeguard Security Team
3 min read

Triage an external report by answering six questions in order: is it real, is it in scope, is it new, can it be exploited here, is the vulnerable code reachable, and how urgent is the fix. Write the answer to each in the case file and tell the researcher the outcome.

1. Is it real?

Reproduce it in a safe environment using the steps in the report. If you cannot, ask for clarification, as OWASP advises. Check for differences in account type, region, browser or configuration before you decide it is not a bug.

2. Is it in scope?

Compare the asset and bug type against your policy. If it is out of scope but still a genuine risk, fix it anyway and say so politely. A strict reading of scope does not oblige you to ignore real problems.

3. Is it new?

Search your tracker for earlier reports of the same flaw. A duplicate still deserves a reply that says it is known and being handled. Credit practice for duplicates should be written into your policy ahead of time.

4. Can it be exploited in your environment?

Consider authentication needed, user interaction, network position and any compensating control. Describe the realistic attacker, not the worst case. This is where a researcher and a defender often disagree, so give reasons.

5. Is the vulnerable code reachable?

For issues in a dependency, ask whether your application actually calls the affected function. A flaw in a library you ship but never invoke is lower priority than one on your login path. Reachability analysis is the method for answering this, and it is the point where tooling saves hours. If you are unsure which of your dependencies a report touches, you can try the free scan at Safeguard's scan page, which does SBOM and dependency scanning.

6. How urgent is it?

Combine the answers. Active exploitation sets the shortest clock; see how exploitation changes deadlines. Otherwise rate by impact and ease, set a target date, and have the decision maker confirm it.

Reply with the outcome: confirmed, not reproducible, out of scope, duplicate, or accepted risk. Give one clear reason. Keep updating them until the fix ships. The roles and runbook shows who sends what.

Quick check

What if we disagree about severity?

Share your reasoning with specifics and invite correction. Disagreement handled politely rarely harms the relationship.

Do we need a formal scoring system?

Pick one and apply it consistently. Which one matters less than using it the same way each time.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.