Page MenuHomeVulnz

Vulnerability Reports Lifecycle
Updated 2,271 Days AgoPublic

Version 1 of 3: You are viewing an older version of this document, as it appeared on Apr 25 2018, 11:25 PM.

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 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.


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)".

Last Author
Last Edited
Apr 25 2018, 11:25 PM

Event Timeline

avm99963 edited the content of this document. (Show Details)
avm99963 added a project: Restricted Project.
avm99963 published a new version of this document.