Talk:Firefox3/Security Review Template

Sid says: Overall, I think it might be more useful to have a decision-based review whereby the template has conditions with follow-up questions. One sample condition and follow-ups could be:

• Does your project create a new API?
  • Enumerate inputs and outputs for each interface in the API
  • What other projects will use the API and how?
  • What type of validation is done for inputs?
  • What type of normalization or sanitization is performed on the outputs?

This would make it easy for applicants to skip sections where the conditions do not apply.

We should also identify what types of projects will use this template to make it more complete (and identify corner cases for uniqueness in each type of project). Here's a brief list of types that I think we want to cover:

• Web Properties
• Back-end Properties (such as data stores)
• Client software product
• Client software module/feature
• Protocol or communication API (such as the sync api -- just the API)

Note that many projects will fall into multiple type categories (such as Sync, which is a back-end, client software module, and protocol), so those projects would have to fill out multiple sections of the template.

Specific suggestions:

• Do we want to include some amount of code review for small projects?
• We should maybe call-out any cryptographic code for detailed code review.
• For web properties, we should ask what protection measures are being used (e.g., CSP, anti-CSRF tokens, SQL prepared statements, etc)
• We should explicitly ask for links to relevant bugs or any existing documentation.
• We should explicitly ask for links to relevant RFCs, IETF Internet Drafts or other normative specifications.
• Could we address design-time reviews? For example, should we ask for a design document to be submitted for pre-review before a full-feature security review happens? This would help make a final project review easier since we won't have to worry about architectural stuff and just focus on details and exploitation.
• We should ask about any third-party libraries used and security analysis of those libraries.
• We should ask the developers to brainstorm the worst things that could happen to their product (or enabled by their product). They are often more familiar with its capabilities and in a position to drum up worst-case scenarios.