canmove, Confirmed users
637
edits
Security/Firefox/Security Bug Life Cycle: Difference between revisions
Security/Firefox/Security Bug Life Cycle (view source)
Revision as of 20:55, 30 September 2019
, 30 September 2019Added an introduction
m (edit suggestions from Thyla) |
(Added an introduction) |
||
| Line 1: | Line 1: | ||
Security bugs in our product put people millions of people at risk. To fulfill Mozilla's mission we must discover those bugs, fix them, and ship those fixes. This process involves multiple teams across the organization. This page describes a bug-centric view of the tasks that are part of that process as a sort of outline to make sure we are executing on each step. There are also handy bugzilla queries that will be helpful for people as they work on each task. | |||
Since this is a bug-centric view there are many important activities performed by Mozilla security teams that are not mentioned, or only briefly. Fuzzing, static analysis, and other research are an input into this process: a source of bug discovery (and much preferred to bugs being found in the wild). The analysis step described in this page can be an input to the efforts to harden Firefox against exploits (e.g. sandboxing, site-isolation, and mitigating XSS in privileged UI code). | |||
'''Note:''' The bugzilla links in this document are intended for the people performing the tasks described in the sections where they are found. Most of them will yield empty or incomplete results unless you are logged in to bugzilla.mozilla.org and have access to security bugs. | |||
= A Bug is Born = | = A Bug is Born = | ||
| Line 16: | Line 24: | ||
= Security Triage = | = Security Triage = | ||
== Incoming == | == Incoming == | ||
| Line 79: | Line 85: | ||
== Landing Fixes == | == Landing Fixes == | ||
External parties watch our check-ins in order to identify security patches; we have several documented cases of this. We don’t want to 0-day ourselves by landing obvious fixes that sit in the tree for a long time before they are shipped in an update, and we especially don't want to land test cases that demonstrate how to trigger the vulnerability. The [https://wiki.mozilla.org/Security/Bug_Approval_Process '''Security Bug Approval Process'''] is designed to prevent that. Part of the approval process is evaluating what bugs need to be pushed to Beta and which are risky and need to ride the trains, and whether or not the patch is needed on supported ESR branches. | |||
[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20sec-approval%3F '''Pending sec-approval requests'''] | [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20sec-approval%3F '''Pending sec-approval requests'''] | ||