- Severity, Exploitability, Difficulty and Report Quality of the Bug: Bugs will be graded on a scale of 1-5, with 5 being the most severe level. This will be based on the potential damage the bug could cause if exploited.
Level | Description | Points |
Level 1 | The cosmetic issue with minimal impact | 5 |
Level 2 | A minor bug affecting non-critical functionality | 10 |
Level 3 | The major bug affecting important functionality | 20 |
Level 4 | Critical bug exposing sensitive data | 40 |
Level 5 | Extremely critical bug allowing system compromise
| 80
|
The Exploitability of Bug:
Level | Description | Points |
Level 1 | Only exploitable with unlikely user interaction | 5 |
Level 2 | Exploitable with common user interaction | 10 |
Level 3 | Exploitable without user interaction | 20 |
Level 4 | Exploitable remotely without credentials | 40 |
Level 5 | Exploitable remotely with default credentials | 80
|
Technical Difficulty:
Level | Description | Points |
Level 1 | Basic coding errors are easily found through scanning | 5 |
Level 2 | Requires understanding of common vulnerabilities | 10 |
Level 3 | Requires expert knowledge of complex vulnerabilities | 20 |
Level 4 | Requires discovering unknown zero-day vulnerabilities | 40 |
Level 5 | Requires advanced skills and persistence to exploit | 80
|
Report Quality:
Level | Description | Points |
Level 1 | Lacking details needed to reproduce the bug | 5 |
Level 2 | Reproducible but missing important context | 10 |
Level 3 | Complete the report with steps to reproduce | 20 |
Level 4 | Well-written report with screen captures and debug data | 40 |
Level 5 | Concise report with clear proof of concept | 80
|
some examples of how the point system could work:
Example 1:
Severity: Level 2 (10 points) Exploitability: Level 1 (5 points) Technical Difficulty: Level 1 (5 points) Report Quality: Level 2 (10 points)
Total Points: 10 + 5 + 5 + 10 = 30 points
Example 2:
Severity: Level 5 (80 points) Exploitability: Level 3 (20 points) Technical Difficulty: Level 3 (20 points) Report Quality: Level 4 (40 points)
Total Points: 80 + 20 + 20 + 40 = 160 points
Example 3:
Issue 1: Severity: Level 3 (20 points) Exploitability: Level 3 (20 points) Technical Difficulty: Level 3 (20 points) Report Quality: Level 3 (20 points) Total for Issue 1 = 20 + 20 + 20 + 20 = 80 points
Issue 2: Severity: Level 3 (20 points) Exploitability: Level 3 (20 points) Technical Difficulty: Level 3 (20 points) Report Quality: Level 3 (20 points) Total for Issue 2 = 20 + 20 + 20 + 20 = 80 points
Total Points for both issues: 80 + 80 = 160 points
Note:
- Duplicate Submissions: In the event that two or more participants submit the same bug at the same time or within a very short time frame, the bug will be assigned to the participant whose submission timestamp is earliest. Other participants will be notified about the duplicate submission and won't receive points for that specific bug.
- Claiming Bugs: Participants are encouraged to avoid working on bugs already claimed by another team member. Before starting to work on a bug, it is essential to check the bug tracking system or communication channels to ensure it is still unclaimed.
- Communication Protocol: To maintain an organized and efficient bug-hunting process, participants must follow a designated communication protocol. This includes using the bug tracking system, designated chat channels, or project management tools to report bugs and updates. Avoid private or undocumented communication methods for reporting vulnerabilities.
- One Bug, One Report: Each unique bug should be reported only once. Participants should refrain from submitting multiple reports for the same issue, which may lead to confusion and extra overhead for the review team.
- Responsible Disclosure: Participants must adhere to responsible disclosure practices. Refrain from sharing bug details or exploits publicly before the vulnerabilities have been mitigated and disclosed by the project's maintainers.
- Proof of Concept (PoC): If possible, participants should include a detailed Proof of Concept (PoC) along with their bug reports. This helps in faster validation and resolution of the issue.
- Avoiding Testing on Production: Participants should refrain from performing security testing on the live production environment. Use designated testing or staging environments provided by the project.
- Non-Interference: Avoid actions that could potentially disrupt the project's functionality, compromise user data, or lead to any form of data loss during the bug-hunting process.
- Reporting Format: Follow the specified bug report template, if any, provided by the project. Include all necessary details, such as vulnerability description, impact, steps to reproduce, and potential fixes.
- No Automated Scanning: Manual testing is encouraged over automated scanning tools, as they may inadvertently cause a high volume of false positives or overload the system.