Submission states help you track the lifecycle of a report from creation to closure. Close reasons add additional context when a submission is closed. Understanding how states and close reasons work together helps ensure consistent handling of submissions across your programs.
Submission states
A submission progresses through a set of states:
Draft
The researcher is preparing the submission before sending it to your program.
Triage
For managed programs, the triage team performs an initial review to reproduce the vulnerability and confirm whether it fits the program scope. At this stage, triage may forward the submission for validation or close it as duplicate, informative, spam, out of scope, or not applicable to reduce noise for your team.
💡Note: For more info on our triage handling, refer to our Triage standards.
Pending
The submission has passed initial triage, or was submitted directly in some setups, and is awaiting review and validation by your team. In this status it is possible to adjust severity or bounty tier. If you change severity or bounty tier, add a comment explaining the decision to the researcher.
Accepted
Your team has validated the vulnerability. At this point the bounty is processed, and the submission moves toward resolution. Integrations can help automate the handoff to internal remediation teams.
Closed
A submission reaches Closed either after a fix for an accepted vulnerability is confirmed and the submission is marked as resolved, or after the submission is rejected. Submissions remain in this state for 14 days to allow follow-up questions before being archived.
Archived
The submission is locked and moved to the archive for long-term record-keeping.
Submission close reasons
When a submission is moved to Closed without being accepted and fixed, a close reason must be selected. The reason you choose impacts researcher metrics.
Accepted risk
Your organization acknowledges the vulnerability but decides not to fix it for business reasons such as low impact, mitigating controls, or planned decommissioning.
Researcher validity ratio ➕ | Researcher is a program contibutor ✔️ |
Duplicate
The vulnerability was already reported in another submission. Link the duplicate to the original parent submission.
Researcher validity ratio ➕ | Researcher is a program contibutor ✔️ |
Informative
The report contains useful information or recommendations but does not describe a distinct, exploitable vulnerability that meets your program requirements.
Researcher validity ratio 🟰 | Researcher is a program contibutor ✖️ |
Out of Scope (OOS)
The report affects assets or vulnerability types that your program policy lists as out of scope.
Researcher validity ratio ➖ | Researcher is a program contibutor ✖️ |
Not Applicable (N/A)
The behavior is not reproducible, is incorrect, or does not represent a security vulnerability in the context of your asset.
Researcher validity ratio ➖ | Researcher is a program contibutor ✖️ |
SPAM
The submission is irrelevant, nonsensical, auto-generated noise, or abusive.
Researcher validity ratio ➖ | Researcher is a program contibutor ✖️ |
Best Practices
Select the close reason that most accurately reflects the outcome of the submission, as it directly affects researcher metrics.
Link duplicate submissions to the correct parent submission.
Don't use Informative as a "kind rejection" for submissions that are actually Not Applicable or Out of Scope.
Avoid using Out of scope or Not applicable interchangeably, as they represent different evaluation outcomes.
Regularly review program statistics related to close reasons to identify potential inconsistencies or training needs for your team.