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 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**: The other party said this issue is now fixed but I haven't verified if the fix works, or I verified that there is a fix in place but the other party hasn't confirmed either that they haven't taken yet all the steps necessary to fix the vulnerability or the fix isn't broadly available - **Verified**: Both myself and the other party verified that the fix is working and it is broadly available - **Invalid**: This was not a valid issue report - **Duplicate**: This report duplicates an existing issue - **WontFix**: We decided not to 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 - **Deadline**: indicates the disclosure deadline (can be from 90 up to 540, but default is 90) - **Reward**: if, after some time, the vendor decides to issue a reward as part of a bug hunting program, this field should be filled with the amount of the reward in dollars 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, in case the report will take some time to write, 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, @Douglasbot will automatically make the report public by changing the "visible to" field to "Public (No Login Required)". The bot will leave a grace period of one day, which means it will not publish it the exact day that the deadline is exceeded, but one or two days after that. In more detail, the bot is executed every day at 05:13 UTC time, and will only publish vulnerabilities if the following condition is met: `currenttime > reporttime + (deadlinedays + graceperiod)*24*60*60`, where `currenttime` is the current UNIX timestamp, `reporttime` is the UNIX timestamp of the date that the issue was reported to the other party, `deadlinedays` is the number of days before the vulnerability goes public and `graceperiod` is the number of days added as a grace period (which is actually set to `1`).

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**: OThe other party said this issue is now fixed but I haven't verified if the fix works, should verify if fix worksor I verified that there is a fix in place but the other party hasn't confirmed either that they haven't taken yet all the steps necessary to fix the vulnerability or the fix isn't broadly available - **Verified**: I’veBoth myself and the other party verified that the fix is working and it is broadly available - **Invalid**: This was not a valid issue report - **Duplicate**: This report duplicates an existing issue - **WontFix**: We decided to notnot to 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) - **Reward**: if, after some time, the vendor decides to issue a reward as part of a bug hunting program, this field should be filled with the amount of the reward in dollars 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, in case the report will take some time to write, 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)"@Douglasbot will automatically make the report public by changing the "visible to" field to "Public (No Login Required)". The bot will leave a grace period of one day, which means it will not publish it the exact day that the deadline is exceeded, but one or two days after that. In more detail, the bot is executed every day at 05:13 UTC time, and will only publish vulnerabilities if the following condition is met: `currenttime > reporttime + (deadlinedays + graceperiod)*24*60*60`, where `currenttime` is the current UNIX timestamp, `reporttime` is the UNIX timestamp of the date that the issue was reported to the other party, `deadlinedays` is the number of days before the vulnerability goes public and `graceperiod` is the number of days added as a grace period (which is actually set to `1`).