Is this report a vulnerability? A triage guide for maintainers

Sort each report into one of four buckets: working as intended, a bug, a feature request, or a vulnerability. A vulnerability is something that lets an attacker compromise confidentiality, integrity or availability across a trust boundary. Most reports that arrive labelled "security" are one of the other three.

The four buckets

The OpenSSF maintainer guide uses these categories, and they are practical:

• Working as intended. The behaviour is documented or is the design. The reporter expected something else.
• Bug. Wrong behaviour with no attacker gain, such as a crash on bad input that only hurts the person who supplied it.
• Feature request. A hardening idea or missing control. Valuable, but not a flaw in what you shipped.
• Vulnerability. Someone can do something they should not be allowed to do.

The guide states plainly that not everything reported as a vulnerability is one. Say that to yourself before you reply.

Five questions that settle most cases

1. Who is the attacker? Name them. An anonymous remote user is different from someone who already controls the machine.
2. What boundary do they cross? If the attacker needs access they would already have, there may be no boundary.
3. What do they gain? Read data, change data, run code, or take the service down.
4. Does it work against a default setup? A flaw that needs an unusual configuration is still real, but it changes how you describe it.
5. Can you reproduce it? Ask for a proof of concept if one is missing.

If the answers to the first three are empty, it is probably not a vulnerability. Your README is the right place to write down that boundary, so you can point to it. See what to document in a maintainer boundaries README.

Replying to each outcome

• Not a vulnerability: Thank them, explain which bucket you chose and why, and offer to move it to the public tracker as a bug or feature request.
• Unclear: Ask for affected lines, the risk, a proof of concept, and what a fix needs to cover.
• Cannot reproduce: Try more than once, say what you tried, and close politely.
• Vulnerability: Move to the private fix process and agree a timeline.

A polite explanation matters. Reporters who feel brushed off post publicly. Reporters who feel heard often come back with a better report.

Severity comes second

Do not argue about the score before you agree it is a vulnerability. Once it is, severity follows from the answers above. Scores are a communication tool for users, and your judgment about your own project should carry weight.

Quick check

Sources

• OpenSSF maintainer guide for vulnerability reports

Last reviewed: 19 October 2026.