Security/Firefox/Security Bug Triage Process: Difference between revisions
Jump to navigation
Jump to search
(Created page with "=== Triage Assumptions === * We reach the steady state of less than total of 3 total sec-high and sec-critical bugs that are older than 1 month by the release date of 59 - 201...") |
m (removing unnecessary search order) |
||
Line 20: | Line 20: | ||
#* The next step should be documented with the ETA of the patch in the bug. | #* The next step should be documented with the ETA of the patch in the bug. | ||
#* If the assigned bug is not updated with next steps by the assignee within 3 business days, the assignee’s manager will be needinfo. | #* If the assigned bug is not updated with next steps by the assignee within 3 business days, the assignee’s manager will be needinfo. | ||
#* Sec-critical bugs should be fixed within two weeks. [[https://bugzil.la/class%3Aclient%2Ccomp%20kw:sec-critical%20creation_ts%3C2w | #* Sec-critical bugs should be fixed within two weeks. [[https://bugzil.la/class%3Aclient%2Ccomp%20kw:sec-critical%20creation_ts%3C2w Older sec-critical bugs]] | ||
#* Sec-high bugs should be fixed within 6 weeks. [[https://bugzil.la/class%3Aclient%2Ccomp%20kw:sec-high%20creation_ts%3C6w | #* Sec-high bugs should be fixed within 6 weeks. [[https://bugzil.la/class%3Aclient%2Ccomp%20kw:sec-high%20creation_ts%3C6w Older sec-high bugs]] | ||
#* If it is not possible to be fixed within those timeframes, the assignee needs to | #* If it is not possible to be fixed within those timeframes, the assignee needs to | ||
#*# Get sign off from both the Senior Engineering Manager of Firefox Security and from the relevant engineering director, who agree on an alternative timeframe or resolution. | #*# Get sign off from both the Senior Engineering Manager of Firefox Security and from the relevant engineering director, who agree on an alternative timeframe or resolution. | ||
#*# Where security engineering and engineering directors do not sign off or cannot agree on an alternative timeframe, the decision on bug will follow the [[Security/Firefox/Security_Bug_Escalation_Process|Security_Bug_Escalation_Process]] | #*# Where security engineering and engineering directors do not sign off or cannot agree on an alternative timeframe, the decision on bug will follow the [[Security/Firefox/Security_Bug_Escalation_Process|Security_Bug_Escalation_Process]] | ||
# After a bug is RESOLVED FIXED it will be assigned to a QE or SoftVision engineer who will attempt to test it in the relevant releases before the bug is VERIFIED FIXED. See the [https://securitywiki.mozilla.org/PostCritSmash Post-CritSmash process document] for current criteria on which bugs we can test. | # After a bug is RESOLVED FIXED it will be assigned to a QE or SoftVision engineer who will attempt to test it in the relevant releases before the bug is VERIFIED FIXED. See the [https://securitywiki.mozilla.org/PostCritSmash Post-CritSmash process document] for current criteria on which bugs we can test. |
Revision as of 22:56, 8 December 2017
Triage Assumptions
- We reach the steady state of less than total of 3 total sec-high and sec-critical bugs that are older than 1 month by the release date of 59 - 2018-03-13 (steady state defined in the process below).
- Security bugs that don’t affect currently shipping releases or are in features disabled behind a hidden pref don’t need to fit the same timeframe. They will, of course, need to be fixed before they’re shipped.
[Draft] Security bug review/fix process
- Security bugs should be triaged and assigned appropriate sec- keywords as they come in
- Component/Triage owners see and triage many of the simple bugs and flag it as security bug appropriately.
- Anything else gets picked up by Pre-Critsmash process
- Untriaged security bugs
- Critsmash process (twice a week):
- If the bug is a defect and determined to be a sec-high or sec-critical
- Set priority to PI
- Set the affected releases
- Assign to an owner, either the known developer of that code or the manager of the team working on that component
- needinfo the assignee
- If the bug is an enhancement, set keyword to sec-want and no owner is needed to be assigned.
- Unassigned sec-high and sec-critical bugs
- All sec-high and sec-critical bugs
- If the bug is a defect and determined to be a sec-high or sec-critical
- The assigned bug owner needs to review and determine the next step within 3 business days.
- The next step should be documented with the ETA of the patch in the bug.
- If the assigned bug is not updated with next steps by the assignee within 3 business days, the assignee’s manager will be needinfo.
- Sec-critical bugs should be fixed within two weeks. [Older sec-critical bugs]
- Sec-high bugs should be fixed within 6 weeks. [Older sec-high bugs]
- If it is not possible to be fixed within those timeframes, the assignee needs to
- Get sign off from both the Senior Engineering Manager of Firefox Security and from the relevant engineering director, who agree on an alternative timeframe or resolution.
- Where security engineering and engineering directors do not sign off or cannot agree on an alternative timeframe, the decision on bug will follow the Security_Bug_Escalation_Process
- After a bug is RESOLVED FIXED it will be assigned to a QE or SoftVision engineer who will attempt to test it in the relevant releases before the bug is VERIFIED FIXED. See the Post-CritSmash process document for current criteria on which bugs we can test.