Each Report on BugBase has a status associated with it to identify the stage of a particular vulnerability from submission to resolution
The following stages indicate that a bug report is still open and has not been resolved:
When a bug report is first submitted, it is in the New stage. This stage is used to indicate that the bug report has not been reviewed by the development team yet.
The New stage is also used to indicate that the bug report has not been reviewed by the security team and is yet to be validated/triaged.
When a bug report is triaged, it is moved to the Triaged stage.
This stage is used to indicate that the bug report has been reviewed by the security team and is under going resolution.
Marking a report Triaged rewards the reporter with +10 points
Additionally, incase the Proof Of Concept is not clear the the security team, an additional label asking for More Context can be added to the report.
When a bug report is complete and no further action is needed, it is typically shifted to the Closed stage.
The report is valid, and the issue it describes has been successfully resolved by the Program Security Team.
No further dialogue with the hacker is needed. The report can be considered complete and the issue can be considered closed.
Marking a report Resolved rewards the reporter with additional points ranging from 0-30 points depending on the Priority of the issue.
This indicates that the issue has already been reported previously. If an issue has already been reported, it is important to attribute the discovery of the issue to the original discoverer in order to build trust and give credit where it is due. This can be done by linking the current report to a previous report via some identifying information, such as a report ID or other Unique identifier/Attachments. Additionally, it can be helpful to include details about the original discovery of the issue, such as the time and date of the original report, in order to provide a complete and accurate record of the issue's history.
By taking these steps, organisations can demonstrate their commitment to transparency and fairness, and help to build trust with the hacking community.
Marking a report Duplicate rewards the reporter with additional points ranging from 0-7 points
The report does not describe a valid security issue or vulnerability. If a bug report is invalid, it is important for security teams to provide a clear explanation of why. This can help hackers to improve their skills and better understand the requirements for successful bug reports. Some common reasons for invalid reports include: the issue being out of scope, reported on out-of-scope assets, or the hacker unable to demonstrate impact.
Marking a report Invalid will deduct 5 points from the reporter. Additionally, if the report is marked as Spam, the reporter will have 15 points deducted
This indicates that the bug reported doesn’t cause any operational issues or errors in the program. Instead, it may provide useful information to developers or end-users, but doesn’t impede the normal functioning of the software. This type of bug is often considered less critical than other types of bugs that can cause system crashes, data loss, or security vulnerabilities.
Marking a report informational does not reward the reporter with any points.
This will notify the reporter to provide more information on the report submitted as it lacks sufficient information.
Last modified 3mo ago