This article explains the journey a submission takes through the platform, from initial report to final closure. It details the different statuses a submission can have and provides clear definitions for each close reason.
Key Takeaways:
Submissions progress through Triage, Pending, Accepted, Closed, and Archived statuses.
Selecting the correct close reason is vital for accurate reporting and fair researcher evaluation.
Understanding these impacts helps ensure data integrity and aligns platform reporting with your internal needs.
Who this article is for:
Program managers
Program members responsible for reviewing, triaging, and validating submissions.
Submission statuses overview
A submission progresses through the following key statuses:
1. Draft
The initial stage where a researcher prepares their submission before submitting it to your program.
2. Triage
For managed programs, our internal triage team conducts an initial review to reproduce the reported vulnerability and verify whether it falls within the program scope. Based on this assessment, they will either forward the submission for validation or close it as a duplicate, informative, spam, out of scope, or not applicable thereby reducing noise for your company.
3. Pending
The submission has passed initial triage (or was submitted directly in some program setups) and is now awaiting review and validation by your team members. You will assess the report's findings against your assets.
Avoid postponing a decision for too long, as the reporter of the issue is eagerly awaiting your final decision. In this state it is also possible to adjust the severity or bounty tier, changes to these should always be accompanied by a comment explaining the decision to change these to the researcher.
4. Accepted
Your team has validated the submission and acknowledged the vulnerability. At this point, the agreed bounty is processed. The submission will then move towards resolution. It is crucial to inform your internal teams regarding the vulnerability to allow them to commence the remediation process. Integrations provide the capability to automate these processes.
5. Closed
This is the final active state of a submission. It is reached 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 for any follow-up questions before being archived.
6. Archived
The submission is locked and moved to the archive for long-term record-keeping. Basic metadata is retained, while sensitive details might be redacted if necessary.
Understanding close reasons
When a submission is moved to the 'Closed' status without being accepted and fixed, a specific reason must be selected. Choosing the correct reason is crucial as it impacts researcher metrics and program statistics. Here are the definitions:
Accepted Risk: Your organization acknowledges the reported vulnerability but decides not to fix it due to specific business reasons (e.g., low impact, mitigating controls elsewhere, planned decommissioning).
Duplicate: The reported vulnerability has already been submitted previously by another researcher (or sometimes by the same researcher) and is documented in a different ('parent') submission. Linking to the original submission is essential.
Informative: The submission contains interesting information, observations, or recommendations related to your assets, but it does not describe a distinct, exploitable vulnerability that meets the program's requirements for acceptance.
Out of Scope (OOS): The reported vulnerability affects assets or vulnerability types listed as out of scope in your program policy.
Not Applicable (N/A): The submission describes behavior that is not reproducible, incorrect, or does not represent a security vulnerability within the context of your application.
SPAM: The submission is clearly irrelevant, nonsensical, auto-generated noise, or otherwise abusive.
Impact of close reasons on researcher metrics
The close reason you select directly influences two key researcher metrics: the validity ratio and program contributor status of the researcher. The validity ratio (%) reflects the proportion of a researcher's submissions that are ultimately deemed valid (Accepted, Resolved, or Accepted Risk). Becoming a program contributor often grants researchers certain privileges or recognition within your program.
Here’s how each close reason impacts these metrics:
Close Reason | Validity Ratio Impact | Program Contributor Status | Notes |
Accepted | Positive (+) | Yes | Acknowledged vulnerability. |
Accepted Risk | Positive (+) | Yes | Considered valid, even if not fixed. |
Duplicate | Positive (+) | Yes |
|
Informative | Neutral (=) | No | No impact on validity ratio |
Out of Scope | Negative (-) | No | Submission is invalid for the program. |
Not Applicable | Negative (-) | No | Submission is invalid. |
SPAM | Negative (-) | No | Submission is invalid / abusive. |
Best Practices
Do:
Familiarize yourself with the definitions and impacts of each close reason.
Always select the reason that most accurately reflects the assessment of the submission.
Link duplicate submissions to the correct parent submission.
Use the 'Informative' reason only when a report provides useful context but isn't an actionable vulnerability per your scope.
Don't:
Use 'Informative' as a "kind rejection" for submissions that are actually 'Not Applicable' or 'Out of Scope'.
Guess the close reason; refer to this guide if unsure.
Expert Tips:
When closing a submission, especially for nuanced reasons like 'Accepted Risk' or 'Informative', add a clear comment explaining the rationale to the researcher.
Regularly review program statistics related to close reasons to identify potential inconsistencies or training needs for your team.