Security/Web Bug Rotation: Difference between revisions

Reboot triage process
No edit summary
(Reboot triage process)
Line 1: Line 1:
{{TOC right}}
{{TOC right}}


=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. In general bugs will have an attempt to verify them in approximately 1 working day.
Web security bugs are reported to security@Mozilla.org mailbox or in a Bugzilla component, a member of Mozilla Security verifies the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security team. 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=
= Rotation =
{| class="wikitable"
|-
! Day !! On-call !! IRC handle
|-
|  Monday || Adam Muntner || adamm
|-
|  Tuesday || Julien Vehent || ulfr
|-
|  Wednesday || Simon Bennetts || psiinon
|-
|  Thursday || Yvan Boily || yvan
|-
|  Friday || April King || April
|}


Under {{bug|835475}} (web-bounty), you will find a list metabugs for different Mozilla web properties. The list is ad-hoc
= Verification process =
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 procedure below is performed by the on-call individual.
# 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 the issue was reported to the security@ alias, create a bug for it
#* '''DUPLICATE''' (via general bugzilla search or via existing meta bugs)
# Determine if the issue reported is NEW, INVALID, or DUPLICATE
## Dupe against old bug
# For '''NEW''' bugs
## Set keywords & whiteboard for the new duped bug
## Find an owner (typically a dev or the product manager) to assign the bug to, and needinfo her/him
##* Whiteboard - [site:example.com]
## Set the right '''[https://bugzilla.mozilla.org/describekeywords.cgi wsec keywords]'''
##**<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.
#* '''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 "?"  
## Set "sec-bounty" flag to "?"  
## Change "Status" shall be set to "NEW" to show bug is verified
## Change "Status" shall be set to "NEW" to show bug is verified
## Block the appropriate meta-bug
## Block the appropriate meta-bug
## Edit "Assigned To" and check the box for "Reset Assignee to default"
## Edit "Assigned To" and check the box for "Reset Assignee to default"
#* '''INVALID'''
# If the verification shows that the issue is invalid, close the bug as '''INVALID'''
## Resolve bug as invalid
# For '''DUPLICATE''' bugs, set dupe against old bug. Set keywords & whiteboard for the new duped bug


= Proposed enhancement to the process =
Follow up on a '''NEW''' bug until you get the assurance that it will be fixed, the urgency of which depends on the vulnerability and the target.
# For NEW issues assignee should use Minion (or one of its supported tools directly) to determine if the vulnerability should have been found by those tools on the default settings.
 
# Assignee should record:
=Bounty=
## If the security tools supported by Minion could have found the bug automatically
 
## If not, could they be easily changed to find the bug
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.
## If we think other tools could have found it that Minion doesnt currently support - these could either be specific tools or classes of tools (like static code analysers)
 
# This information is currently being recorded here: https://mana.mozilla.org/wiki/display/SECURITY/AppSec+Web+Bug+Reviews but we may change to record it in Bugzilla
For '''NEW''' bugs
== NEW ==
For NEW bugs that have been verified, simply set the "sec-bounty" flag to "?"
 
== DUPLICATE ==
If the bug is a duplicate of an existing bug
# 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.
Confirmed users
529

edits