# Report Status

### Open Report Stages

The following stages indicate that a bug report is still open and has not been resolved:

**New**

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 program team yet.

The New stage is also indicates that the bug report has not been reviewed by the security team and is yet to be validated/triaged.

**Triaged**

When a bug report is triaged, it is moved to the Triaged stage.

This stage indicates that the bug report has been reviewed by the security team and is under going resolution.

{% hint style="info" %}
Marking a report **Triaged** rewards the bounty hunter with ***+10 points***
{% endhint %}

{% hint style="info" %}
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.
{% endhint %}

### Closed Report Stages

When a bug report is complete and no further action is needed, it is typically shifted to the Closed stage.

**Resolved**

The report is valid, and the program team has successfully addressed the impactful issue it describes. No further dialogue with the bounty hunter is needed, and the report can be considered complete and closed.

{% hint style="success" %}
Marking a report **Resolved** rewards the bounty hunter with additional points ranging from ***0-30 points*** depending on the **Severity** of the issue.
{% endhint %}

**Duplicate**

A duplicate issue is one that has already been reported previously. To ensure fairness and transparency, duplicates should be appropriately linked to the original report.

Handling duplicates:

1. **On BugBase**: Link the duplicate to the original by searching by the report ID or title.
2. **Different platform**: Add a reference ID and a screenshot as proof of the original report.

{% hint style="info" %}
Marking a report **Duplicate** rewards the bounty hunter with additional points ranging from ***0-7 points***
{% endhint %}

**Invalid/Spam**

The report does not describe a valid issue or vulnerability. When marking a report as invalid, security teams should provide a clear explanation of the reason. This feedback helps hackers understand the requirements more clearly.

Common reasons for invalid reports include issues or assets being out of scope or lacking sufficient evidence to demonstrate impact.

{% hint style="danger" %}
Marking a report **Invalid** will deduct ***5***** points** from the bounty hunter.
{% endhint %}

#### Informational

An informational bug doesn’t cause operational issues or errors in the program but may offer useful insights for developers or users without affecting the software's normal functioning.

{% hint style="info" %}
Marking a report **Informational** does not reward the bounty hunter with any points.
{% endhint %}

{% hint style="warning" %}
Note: After 14 days of shifting the report status to a Closed Stage the report is automatically closed - this means that the chat window or any report actions will not be accessible.
{% endhint %}

### Report Status Label

A report status label provides additional context about the current state or requirements of a bug report

#### More Context Required

The report requires additional information from the bounty hunter to clarify certain aspects or provide more details. 

#### Program Review Requested

The report is currently awaiting review by the program managers. The program team will assess the details of the report, and take the appropriate next steps.

#### Spam

Spam reports are flagged as invalid and given an additional status label for spam.

{% hint style="danger" %}
If the report is marked as **Spam**, the bounty hunter will have ***15***** points** deducted.
{% endhint %}