This document describes the typical lifecycle of a vulnerability report of the avm99963 Security Research project. ##Discovering the vulnerability Any security vulnerability of any program, app, website or anything related to computer engineering is eligible to be reported in the Maniphest issue tracker of this project. What’s more, when a vulnerability is discovered, it should be reported as soon as possible by performing the following steps. ##Reporting the vulnerability To report the vulnerability you should [[ https://vulnz.avm99963.com/maniphest/task/edit/form/1/ | fill a new vulnerability report ]]. In the **title** field, write a brief description of the vulnerability. An example would be: "//XSS vulnerability in Clickedu calendar//". In the **description** field, write the bug report itself. You should include the steps in which you can reproduce the vulnerability, what should happen and what doesn’t. Finally, additional comments should be entered such as if the other party was contacted and when. Most vulnerability reports would be subject to a **90 day disclosure deadline**. If this is the case, information about the disclosure deadline should be added in the bottom of the issue description, such as the following notice: > This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. The **status** should be set according to the following format: - **New**: Issue has not had initial review yet - **Accepted**: Problem reproduced by other party - **Started**: Work on this issue has begun by the other party - **Fixed**: Other party said this issue is now fixed, should verify if fix works - **Verified**: I’ve verified that the fix is working - **Invalid**: This was not a valid issue report - **Duplicate**: This report duplicates an existing issue - **WontFix**: We decided to not take action on this issue - **Done**: The requested non-coding task was completed The following fields should be filled: - **Priority**: priority of the bug, being 0 the most important and 3 the least - **Vendor**: the vendor of the product which contains the vulnerability - **Product**: the product which contains the vulnerability - **Reported**: the date in which the issue was reported (e.g: “Reported-2015-Jan-22”) - **Deadline**: indicates the disclosure deadline (can be from 90 up to 540, but default is 90) In the **subscribers** field enter the other party's Phabricator user (if they have one) so the report can be sent to them. In some cases in which the other party doesn’t understand English fully or they don't have a Phabricator user but both parties can fully understand and write in another language, a manual email should be sent with the report translated into that language. Before submitting the vulnerability report the best practice is to contact the vendor informing about the vulnerability and then send the vulnerability report so that the vulnerability can be fixed as soon as possible. ##Follow-up Both parties should report progress on a weekly basis for the first month, and then at least monthly thereafter. The vulnerability report in the issue tracker should be updated accordingly. ##Updating a fixed vulnerability When a vulnerability is fixed by the other party, the bug should be updated with the //Fixed// or //Verified// statuses. ##Disclosure deadline exceeded When the vulnerability disclosure deadline exceeds, it should be made public by changing the "visible to" field to "Public (No Login Required)".

This document has moved to https://bugs.avm99963.com/p/vulnz/adminIntro.

This document describes the typical lifecycle of a vulnerability report of the avm99963 Security Research project. ##Discovering the vulnerability Any security vulnerability of any program, app, website or anything related to computer engineering is eligible to be reported in the Maniphest issue tracker of this project. What’s more, when a vulnerability is discovered, it should be reported as soon as possible by performing the following steps. ##Reporting the vulnerability To report the vulnerability you should [[ https://vulnzhas moved to https://bugs.avm99963.com/maniphest/task/edit/form/1/ | fill a new vulnerability report ]]. In the **title** field, write a brief description of the vulnerability. An example would be: "//XSS vulnerability in Clickedu calendar//". In the **description** field, write the bug report itself. You should include the steps in which you can reproduce the vulnerability, what should happen and what doesn’t. Finally, additional comments should be entered such as if the other party was contacted and when. Most vulnerability reports would be subject to a **90 day disclosure deadline**. If this is the case, information about the disclosure deadline should be added in the bottom of the issue description, such as the following notice: > This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. The **status** should be set according to the following format: - **New**: Issue has not had initial review yet - **Accepted**: Problem reproduced by other party - **Started**: Work on this issue has begun by the other party - **Fixed**: Other party said this issue is now fixed, should verify if fix works - **Verified**: I’ve verified that the fix is working - **Invalid**: This was not a valid issue report - **Duplicate**: This report duplicates an existing issue - **WontFix**: We decided to not take action on this issue - **Done**: The requested non-coding task was completed The following fields should be filled: - **Priority**: priority of the bug, being 0 the most important and 3 the least - **Vendor**: the vendor of the product which contains the vulnerability - **Product**: the product which contains the vulnerability - **Reported**: the date in which the issue was reported (e.g: “Reported-2015-Jan-22”) - **Deadline**: indicates the disclosure deadline (can be from 90 up to 540, but default is 90) In the **subscribers** field enter the other party's Phabricator user (if they have one) so the report can be sent to them. In some cases in which the other party doesn’t understand English fully or they don't have a Phabricator user but both parties can fully understand and write in another language, a manual email should be sent with the report translated into that language. Before submitting the vulnerability report the best practice is to contact the vendor informing about the vulnerability and then send the vulnerability report so that the vulnerability can be fixed as soon as possible. ##Follow-up Both parties should report progress on a weekly basis for the first month, and then at least monthly thereafter. The vulnerability report in the issue tracker should be updated accordingly. ##Updating a fixed vulnerability When a vulnerability is fixed by the other party, the bug should be updated with the //Fixed// or //Verified// statuses. ##Disclosure deadline exceeded When the vulnerability disclosure deadline exceeds, it should be made public by changing the "visible to" field to "Public (No Login Required)"com/p/vulnz/adminIntro.