Security/Web Bug Rotation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "=Web Bug Verification= When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers....")
 
Line 1: Line 1:
=Web Bug Verification=
=Web Bug Verification=
When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security assurance team is a weekly rotation. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed.  
When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security assurance team is a weekly rotation. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed. In general bugs will have an attempt to verify them in approximately 1 working day.


=Process=
=Process=

Revision as of 15:35, 30 January 2013

Web Bug Verification

When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security assurance team is a weekly rotation. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed. In general bugs will have an attempt to verify them in approximately 1 working day.

Process

  1. New bugs reported to the security@ alias or filed directly will have the whiteboard marked with [verif?] to designate them as needing verification. They shall also have the status of unconfirmed.
  2. The bug will be assigned to the security assurance member listed on the security assurance calendar is the on-call rotation for that week.
  3. The assignee shall verify the issue reported and check for duplicate existing bugs.
    1. If a duplicate is found the bug shall be resolved as a duplicate.
    2. If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.
  4. If bug is verified the following items need to be changed:
  • The [verif?] whiteboard will be removed.
  • The sec–bounty flag set to "?", so the bounty committee can consider the bug when the issue is resolved.
  • The bug status shall be set to NEW
  • The bug assignee shall be reset to the default such that the team that owns the website or web service can assign an appropriate owner.