Security/Web Bug Rotation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 3: Line 3:


=Process=
=Process=
Under {{bug|835475}} (web-bounty), you will find a list metabugs for different Mozilla web properties. The list is ad-hoc
and likely needs to be expanded. There is currently a catch all {{bug|836522}} (other-bounty) to cover bugs that do not fit
into any of the other trackers.
# 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.
# 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.
# The bug will be assigned to the security assurance member listed on the security assurance calendar is the on-call rotation for that week.
# The bug will be assigned to the security assurance member listed on the security assurance calendar is the on-call rotation for that week.
# The assignee shall verify the issue reported and check for duplicate existing bugs.
# Verification assignee determines if the issue reported is NEW, INVALID, or DUPLICATE
## If a duplicate is found the bug shall be resolved as a duplicate.
#* '''DUPLICATE''' (via general bugzilla search or via existing meta bugs)
## Dupe against old bug
## Set keywords & whiteboard for the new duped bug
##* Whiteboard - [site:example.com]
##**<i>set to site being reported</i>
##* Keywords - wsec-
##** <i>set to appropriate keyword for type of issue being reported</i>
## Set "sec-bounty" flag to "-" on new bug since it was a dupe
## Set the new bug blocking the appropriate metabug(s)
#* For older bugs duped against that do not have the current flags
## If the old bug has the attachment 'bounty non-qual' or similar then set sec-bounty- on the old bug
## If the old bug has the attachment 'bounty awarded X' or 'bounty paid X', then set sec-bounty? on the old bug
##  If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.
##  If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.
# If bug is verified the following items need to be changed:
#* '''NEW'''
* The [verif?] whiteboard will be removed.
## Remove [verif?] from the whiteboard
* The sec–bounty flag set to "?", so the bounty committee can consider the bug when the issue is resolved.
## Set keywords & whiteboard for the new duped bug
* The bug status shall be set to NEW
##* Whiteboard - [site:example.com]
* 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.
##**<i>set to site being reported</i>
##* Keywords - wsec-
##** <i>set to appropriate keyword for type of issue being reported</i>
## Set "sec-bounty" flag to "?"  
## Change "Status" shall be set to "NEW" to show bug is verified
## Block the appropriate meta-bug
## Edit "Assigned To" and check the box for "Reset Assignee to default"
#* '''INVALID'''
## Resolve bug as invalid

Revision as of 13:37, 13 March 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

Under bug 835475 (web-bounty), you will find a list metabugs for different Mozilla web properties. The list is ad-hoc
and likely needs to be expanded. There is currently a catch all bug 836522 (other-bounty) to cover bugs that do not fit
into any of the other trackers.
  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. Verification assignee determines if the issue reported is NEW, INVALID, or DUPLICATE
    • DUPLICATE (via general bugzilla search or via existing meta bugs)
    1. Dupe against old bug
    2. Set keywords & whiteboard for the new duped bug
      • Whiteboard - [site:example.com]
        • set to site being reported
      • Keywords - wsec-
        • set to appropriate keyword for type of issue being reported
    3. Set "sec-bounty" flag to "-" on new bug since it was a dupe
    4. Set the new bug blocking the appropriate metabug(s)
    • For older bugs duped against that do not have the current flags
    1. If the old bug has the attachment 'bounty non-qual' or similar then set sec-bounty- on the old bug
    2. If the old bug has the attachment 'bounty awarded X' or 'bounty paid X', then set sec-bounty? on the old bug
    3. If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.
    • NEW
    1. Remove [verif?] from the whiteboard
    2. Set keywords & whiteboard for the new duped bug
      • Whiteboard - [site:example.com]
        • set to site being reported
      • Keywords - wsec-
        • set to appropriate keyword for type of issue being reported
    3. Set "sec-bounty" flag to "?"
    4. Change "Status" shall be set to "NEW" to show bug is verified
    5. Block the appropriate meta-bug
    6. Edit "Assigned To" and check the box for "Reset Assignee to default"
    • INVALID
    1. Resolve bug as invalid