First ask whether you can fix it. If you can, treat it as in scope whatever the policy says. If it belongs to another vendor, redirect the reporter or contact the upstream owner. If it is an ordinary bug or an incident, route it to the right team. Then use the report to clarify your scope text.
What the guidance says
The CERT Guide to Coordinated Vulnerability Disclosure, in its vendor scenarios, covers reports outside a program's scope: if the vendor can fix it, treat it as in scope; if not, redirect the reporter or contact the upstream vendor; security incidents and ordinary bugs can go to the appropriate teams; and use the report to clarify policy. That is a good rule of thumb for small teams who cannot afford to bounce useful reports.
A decision path
- Is it your code, your service or your infrastructure? If yes, handle it.
- Is it a component you ship but did not write? Handle it as a downstream issue. You need to tell the upstream project and decide what to do for your customers.
- Is it a third party service you use? Pass details to that provider, with the reporter's permission, or tell the reporter where to go.
- Is it a customer's own system? Tell the reporter to contact that customer.
- Is it an active attack on you? Move to your incident process.
- Is it a normal bug? Send to support or engineering and tell the reporter.
How to reply
Thanks for the report. This affects a system we do not operate, so we cannot fix it ourselves. With your permission we will pass your details to the maintainer. If you would rather contact them directly, their security contact is listed at the link below. We appreciate you looking out for our users.
Always say what you will do and what the reporter can do.
Typical out of scope reports
| Report type | Suggested handling |
|---|---|
| Missing header on a marketing site | Thank, log, fix if cheap |
| Issue in an open source library you ship | Handle as upstream plus downstream |
| Scanner output with no proof | Ask for a working demonstration |
| Social engineering of your staff | Route to internal security |
| Third party SaaS misconfiguration | Pass to that provider |
| Denial of service by volume | Check policy, often excluded |
Fix your scope text
Every out of scope report is a hint your policy was unclear. After handling it, edit the policy so the next person knows. State what is covered, what is excluded, and where to send things that are neither. The posts on a vulnerability disclosure policy checklist and AI written bug reports can help.
Quick check
Should we thank people for out of scope reports?
Yes. A short, kind reply keeps goodwill, and next time they may report something in scope.
What if the report is about a dependency we ship?
Validate whether your product reaches the vulnerable code, tell the upstream project, and plan your own patch or mitigation for customers.
Safeguard's SBOM and dependency scanning can help you see which libraries you ship and whether a reported flaw sits in one of them. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
