Security/Firefox/Security Bug Escalation Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Add assumption)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
=== Assumption ===
Security bug fix process needs clearly defined escalation process to be effective
Security bug fix process needs clearly defined escalation process to be effective


== Bug management/escalation process ==
=== Bug management/escalation process ===
#Two days after a sec-crit or sec-hi bug was assigned, if no update on the bug, the assignee will be receive an overdue email. If no activity on the bug for another day, assignee’s manager will be needinfo-ed, This step will continue to escalate every 2 days until the bug is updated with next step. The escalation process stops when an developer is assigned to investigate and fix this P1 bug and provided provided update on how to land the patch with estimate.
#Two days after a sec-crit or sec-hi bug was assigned, if no update on the bug, the assignee will receive an overdue email. If no activity on the bug for another day, assignee’s manager will be needinfo-ed, This step will continue to escalate every 3 days until the bug is updated with next step. The escalation process stops when an assigned developer provide an update on how to land the patch with estimate.
#Weekly security bug status report will be send to engineering managers, engineering directors, Head of Trust and Safety, and release drivers
#Weekly security bug status report will be send to engineering managers, engineering directors, Head of Trust and Safety, and release managers.
#Every two weeks, the stakeholders will meet to review the sec-hi and sec-crit bug status for a relevant releases. Each role is defined in [http://www.brighthubpm.com/six-sigma/29633-daci-for-decision-making/]
#Every two weeks, the stakeholders will meet to review the sec-hi and sec-crit bug status for a relevant releases. Each role is defined in [http://www.brighthubpm.com/six-sigma/29633-daci-for-decision-making/]
## Roles of stakeholders:  
## Roles of stakeholders:  
##* Driver: Wennie Leung
##* Driver: Wennie Leung and Dan Veditz
##* Approvers: Dan Veditz, Wennie Leung, Release owner of a relevant release (rotating)
##* Approvers for uplift and exception: Dan Veditz, Wennie Leung, Release owner of a relevant release (rotating)
##* Consult/Contributor: Marshall Erwin, Director of Trust and Safety; Emma Humphries, Bugmaster.
##* Consult/Contributor: Marshall Erwin, Director of Trust and Safety; Emma Humphries, Bugmaster.
##* Informed: Engineering Directors: Selena Deckelmann, Joe Hildebrand, Chris Karloff
##* Informed: Engineering Directors: Selena Deckelmann, Joe Hildebrand, Chris Karloff, Yan Or
## Meeting agenda:
## Meeting agenda:
##* Review the security bug status
##* Review the security bug status
Line 15: Line 16:
##* Determine the list of security bugs can be shipped with the release without compromising its security and quality.
##* Determine the list of security bugs can be shipped with the release without compromising its security and quality.
#Escalation path
#Escalation path
#* In the event that agreement cannot be reached by the sec bug stakeholders, issues will be escalated to Sr Director of Engineering, Dave Camp and SVP of Firefox Mark Mayo for a decision.
#* In the event that agreement cannot be reached by the sec bug stakeholders, issues will be escalated to Sr Director of Engineering, Dave Camp and Sr Director of Product Integrity, Yan Or.
#* In the event that agreement again cannot be reached, the issue will escalate to SVP of Firefox Mark Mayo for a final decision.
#Uplifting security bug fixes across the train releases
#* Security uplift nominations to the beta branch will be reviewed by security team and release owner within the last two weeks of the cycle
#* Security uplift nominations during RC week will be reviewed by security team and release owner for feasibility to include in m-r.
#* Security uplift nominations to the ESR branch will be reviewed by security team and release owner.

Latest revision as of 06:33, 30 January 2018

Assumption

Security bug fix process needs clearly defined escalation process to be effective

Bug management/escalation process

  1. Two days after a sec-crit or sec-hi bug was assigned, if no update on the bug, the assignee will receive an overdue email. If no activity on the bug for another day, assignee’s manager will be needinfo-ed, This step will continue to escalate every 3 days until the bug is updated with next step. The escalation process stops when an assigned developer provide an update on how to land the patch with estimate.
  2. Weekly security bug status report will be send to engineering managers, engineering directors, Head of Trust and Safety, and release managers.
  3. Every two weeks, the stakeholders will meet to review the sec-hi and sec-crit bug status for a relevant releases. Each role is defined in [1]
    1. Roles of stakeholders:
      • Driver: Wennie Leung and Dan Veditz
      • Approvers for uplift and exception: Dan Veditz, Wennie Leung, Release owner of a relevant release (rotating)
      • Consult/Contributor: Marshall Erwin, Director of Trust and Safety; Emma Humphries, Bugmaster.
      • Informed: Engineering Directors: Selena Deckelmann, Joe Hildebrand, Chris Karloff, Yan Or
    2. Meeting agenda:
      • Review the security bug status
      • Resolve the security bug fixes exceptions: timeline for bug fix and priorities
      • Determine the list of security bugs can be shipped with the release without compromising its security and quality.
  4. Escalation path
    • In the event that agreement cannot be reached by the sec bug stakeholders, issues will be escalated to Sr Director of Engineering, Dave Camp and Sr Director of Product Integrity, Yan Or.
    • In the event that agreement again cannot be reached, the issue will escalate to SVP of Firefox Mark Mayo for a final decision.
  5. Uplifting security bug fixes across the train releases
    • Security uplift nominations to the beta branch will be reviewed by security team and release owner within the last two weeks of the cycle
    • Security uplift nominations during RC week will be reviewed by security team and release owner for feasibility to include in m-r.
    • Security uplift nominations to the ESR branch will be reviewed by security team and release owner.