Security/Firefox/Security Bug Triage Process

Assumptions

• We can reach the steady state of less than 10% of sec-high and sec-critical bugs that are older than 1 month by the end of Q2/2018 (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.

Security bug review/fix process

1. 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
2. Critsmash process (once a week):
   • If the bug is a defect and determined to be a sec-high or sec-critical
     1. Set priority to PI
     2. Set the affected releases
     3. Assign to an owner, either the known developer of that code or the manager of the team working on that component
     4. 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 (including "stalled")
   • All sec-high and sec-critical bugs (including "Stalled")
3. 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 (including "stalled")
   • Sec-high bugs should be fixed within 6 weeks. Older sec-high bugs (including "stalled")
   • If it is not possible to be fixed within those timeframes, the assignee needs to
     1. 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.
     2. 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
4. 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.