Security/Web Bug Rotation: Difference between revisions
< Security
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. | ||
# | # Verification assignee determines if the issue reported is NEW, INVALID, or DUPLICATE | ||
## If | #* '''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. | ||
# | #* '''NEW''' | ||
## Remove [verif?] from the whiteboard | |||
* | ## 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 "?" | |||
## 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.
- 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.
- Verification assignee determines if the issue reported is NEW, INVALID, or 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]
- set to site being reported
- Keywords - wsec-
- set to appropriate keyword for type of issue being reported
- Whiteboard - [site:example.com]
- 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.
- NEW
- Remove [verif?] from the whiteboard
- 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
- Whiteboard - [site:example.com]
- 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