Security/Web Bug Rotation

Web Bug Verification

When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security assurance team is a weekly rotation. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed. In general bugs will have an attempt to verify them in approximately 1 working day.

Process

Under bug 835475 (web-bounty), you will find a list metabugs for different Mozilla web properties. The list is ad-hoc
and likely needs to be expanded. There is currently a catch all bug 836522 (other-bounty) to cover bugs that do not fit
into any of the other trackers.

1. New bugs reported to the security@ alias or filed directly will have the whiteboard marked with [verif?] to designate them as needing verification. They shall also have the status of unconfirmed.
2. The bug will be assigned to the security assurance member listed on the security assurance calendar is the on-call rotation for that week.
3. Verification assignee determines if the issue reported is NEW, INVALID, or DUPLICATE
   • DUPLICATE (via general bugzilla search or via existing meta bugs)
   1. Dupe against old bug
   2. Set keywords & whiteboard for the new duped bug
      • Whiteboard - [site:example.com]
        • set to site being reported
      • Keywords - wsec-
        • set to appropriate keyword for type of issue being reported
   3. Set "sec-bounty" flag to "-" on new bug since it was a dupe
   4. Set the new bug blocking the appropriate metabug(s)
   • For older bugs duped against that do not have the current flags
   1. If the old bug has the attachment 'bounty non-qual' or similar then set sec-bounty- on the old bug
   2. If the old bug has the attachment 'bounty awarded X' or 'bounty paid X', then set sec-bounty+ on the old bug
   3. If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.
   • NEW
   1. Remove [verif?] from the whiteboard
   2. Set keywords & whiteboard for the new duped bug
      • Whiteboard - [site:example.com]
        • set to site being reported
      • Keywords - wsec-
        • set to appropriate keyword for type of issue being reported
   3. Set "sec-bounty" flag to "?"
   4. Change "Status" shall be set to "NEW" to show bug is verified
   5. Block the appropriate meta-bug
   6. Edit "Assigned To" and check the box for "Reset Assignee to default"
   • INVALID
   1. Resolve bug as invalid

Proposed enhancement to the process:

1. For NEW issues assigneee should use Minion (or one of its supported tools directly) to determine if the vulnerability should have been found by those tools on the default settings.
2. Assignee should record:
   1. If the security tools supported by Minion could have found the bug automatically
   2. If not, could they be easily changed to find the bug
   3. If we think other tools could have found it that Minion doesnt currently support - these could either be specific tools or classes of tools (like static code analysers)
3. This information is currently being recorded here: https://mana.mozilla.org/wiki/display/SECURITY/AppSec+Web+Bug+Reviews but we may change to record it in Bugzilla