Security/Firefox/Security Bug Triage Process
Jump to navigation
Jump to search
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.