Skip to content

iOS Security Triage Process

Jump to bottom
mattreaganmozilla edited this page Jan 30, 2026 · 10 revisions

Overview

This page provides a brief overview of the security triage process for the Firefox iOS client. This document will likely be updated soon as part of our documentation overhaul (and migration to Confluence). It does not go into details on how to use Bugzilla, for that please see the original triage Google Doc or ping one of the security team members.

Security Ticket Management

Our security tickets are currently tracked in Bugzilla, and Jira. For confidentiality, we do not track sec tickets in Github. Security tickets in Github should ideally be called out during the weekly health monitor deep dive, and then duplicated to Bugzilla (the GH issue can then be removed after the reporter is informed and the ticket information is recorded). Also keep in mind that because Github information is publicly visible, security issues disclosed there need to be escalated immediately to assess the security rating and impact.

Because Bugzilla and Jira are not currently sync'd via automation, we currently link the tickets manually in a few places to be sure the tickets can be easily cross-referenced:

  • The Bugzilla should have the Jira link added (in the URL or See Also fields)
  • The Jira (on our iOS Security epic) also has the Bugzilla link
  • Our iOS security spreadsheet also ties the two together and provides a place for updating the status, release, and miscellaneous dev notes

Security tickets in Jira should always be made as Stories (not Tasks or Bugs), to avoid our automation duplicating them to Github.

Obtaining Bugzilla Access

Users with existing access to tickets can add other Mozilla team members in the CC list. For more information, see our Security Bug Access Policy.

Firefox & Focus

The security spreadsheet is divided into separate tabs for Firefox and Focus. Apart from this the process is largely identical. The Product field in the Bugzilla should indicate which iOS client a ticket is filed for, but be sure to read the description and confirm (if needed) with the reporter, since these fields are often incorrect initially.

Triage Workflow

This is a brief overview of the general triage process.

  1. Once per week, new tickets are reviewed by someone on the iOS team (Bugzilla query)
  2. Tickets that are in-progress, noteworthy, or sec-high/sec-critical should be added to our security spreadsheet immediately, and called out in the weekly security update (aspects of this process are still in flux, and may be changing soon)
  3. The security team is typically responsible for providing the security classification based on our severity guidelines. The security rating is marked on a Bugzilla using the keywords field, and the associated severity keyword (sec-low, sec-moderate, sec-high, sec-critical)
    • High and Critical bugs should always be addressed with priority, and escalated to the iOS team
  4. Moderate or Low bugs can be mentioned in the weekly security update, or during iOS triage. We have a backlog of Low/Moderate tickets, and so there are typically always security bugs available for engineers with free cycles

Picking up Bugs

Upon receiving or picking up a security ticket, it is advisable to do the following:

  1. Fully read through the description, and make sure the test cases for the bug are documented clearly
  2. Check if the bug overlaps with any other existing Bugzillas (this can be challenging due to the sheer volume of the backlog)
  3. Any POCs, HTML pages, or external links provided by reporters should be downloaded and duplicated onto the Bugzilla
    • This is critical, to ensure we can replicate POCs and test bugs in the future even if the reporter later removes their webpage or link

Fixing Bugs

After fixing and validating a bug, the process is as follows:

  1. Create a PR as usual, but only include the Bugzilla and Jira links. You should omit security-related details or screenshots from the description and PR comments when possible (follow-up communication with the reviewer can be moved to Slack DMs or other secure channels)
  2. Once approved, merge the fix
  3. Notify an iOS security member, so that the security spreadsheet can be updated
  4. Link the PR on the Bugzilla (in the URL, or See Also, field)
  5. Update the Bugzilla status (typically RESOLVED - FIXED) and fix version
  6. Assign the security Jira to an iOS QA team member (be sure to CC the QA member on the Bugzilla so they can view it)

Bounty Questions

Engineering will commonly receive questions on Bugzillas related to bounty rewards. We do not answer these. Instead, direct the reporter to email our Mozilla bounty email address (ping a security member for the email, if needed).

Security Advisories

After a fix is merged, validated, and released, the final step of the process is security advisories. The publication process is documented here. In short, we have several Python scripts which generate the advisory YAML, which is then published to a private repo where it is validated prior to publication.

Clone this wiki locally