Security/Reviews/Secure Development Lifecycle

Document Status

• DRAFT
• Will soon be open for comment with Mozilla Security Community on security-group and dev-security-policy

Objective

• Quickly bring products and applications to market with integrated and verified controls that mitigate security and privacy risks to an understood and acceptable level
• Capture the overall review lifecycle that ensures Mozilla applications, services and supporting infrastructure are appropriately supported in the areas of :
  • Security
  • Privacy

Mozilla Development Lifecycle Overview

The mozilla development lifecycle is fluid and informal. In the early stages projects often flow between Prototype and Design & Development stages frequently.

Phases of Development Lifecycle

• Prototype
• Design & Development
• Staging
  • Firefox - Nightly / Aurora / Beta
  • Web Applications - Dev Server / Staging Server
• Production Launch
  • Firefox - Release
  • Web Applications - Production Server

Mozilla Secure Development

Note: This process is flexible and adjusts to meet the demands of the particular project. Our goal is to responsibly get code to market and work together to identify any risks that we should be aware of.

Initial Risk Analysis

• When: During prototype phase
• Objective: Determine if new feature/application needs FULL REVIEW or LIGHT REVIEW
• Audience: Development Lead, Security Assurance Representative, & Mozilla Security Community
• Process to Engage: SImply file a XXX Form
• Inputs: Answers to Initial Risk Analysis questionnaire (5 basic questions to understand planned app)
• Outputs: Decision on FULL REVIEW or LIGHT REVIEW

Secure by Design

• When: During prototype & Design
• Objective: Analyze selected architecture, perform threat modeling and data flow analysis to identify high risk areas where additional controls are necessary to mitigate risk to acceptable levels
• Audience: Architects, Development Lead, Embedded Security Assurance Representative, & Mozilla Security Community
• Process to Engage: Once a design plan and architecture (even tentative) is selected then either reach out to the embedded Security Assurance Representative or update the project on Security Radar with "Ready for Design Discussion"
• Inputs:
  • Basic application architecture
  • Data flow diagram
  • List of data types handled
• Outputs:
  • Completed threat modeling document - Will be living document
  • Recommended additional enhancements (via bugs) to increase specific security or privacy concerns

Secure Development

• When: Throughout development
• Objective: Provide security guidance, tools and subject matter expertise as needed to avoid introducing security or privacy flaws into the code
• Audience: Developers
• Process to Engage:
  • For security or privacy questions on bugs, design questions, patches etc - SImply add the keyword "Sec-review-needed" to any bug. We triage these each week and will jump in to assist
  • For general questions or immediate needs - Email security@mozilla.org and we'll get back to you right away with assistance
• Inputs:
  • Any security or privacy question that is on your mind. Really anything, we're here to help
  • Development guidelines - check out the following guidelines to find additional information
  • Secure Web Development Guide - concise guidance to avoid common web application security issues
  • Privacy Principles - guiding rules for handling user data in a privacy preserving way
• Outputs: A quick answer to address the issue

Verification

• When:
  • Hosted Applications : Once application is staged and development is complete
  • Firefox : Performed continually against code base
• Objective: Verify if planned security and privacy controls have been correctly implemented and also identify any other security or privacy risks inadvertently introduced during development
• Audience: Security Assurance, Developers, & Mozilla Security Community
• Process to Engage: SImply file a XXX Form
• Inputs: Running code
• Outputs: Bugs for any identified security or privacy weaknesses

Attack Detection / Prevention

• When: Post Launch
• Objective: Continual analysis to identify any residual vulnerabilities or risks associated with new/unknown attack techniques
• Audience: Mozilla Security Community & Security Assurance
• Process to Engage: No action needed, these processes are already in place
• Inputs: The following processes identify vulnerabilities in released code:
  • Security Research via Bug Bounty Program
  • Ongoing security fuzzing via Mozilla Security Assurance
  • Third party automated and manual security reviews
• Outputs: Bugs for any identified security or privacy weaknesses