User:SBassett (WMF)/drafts/SRR SOP new

Original source material: https://www.mediawiki.org/wiki/Security/SOP/Security_Readiness_Reviews

Purpose
This document describes the process for requesting a security readiness review (a.k.a. security code review) and having said request be completed by the Security Team. This is the review described within the current Preparing For Deployment documentation, as opposed to a security preview, due-diligence third-party review or privacy review.

How do I submit a security readiness review request?
Please use the current Phabricator form to submit your request. These requests are placed within the Incoming column of the secscrum workboard. Once triaged, they will be placed within the Back Orders column of the same workboard where they will await acceptance and scheduling - see the How are these requests prioritized? section below.

What type of project or code triggers this review process?
In theory, any code related to any Wikimedia project is eligible for a security readiness review. But given current resources and constraints, the following are some examples of code that the Security Team probably won't review, at least not via the security readiness review process:

Code not likely to be reviewed:
 * Routine changes which are submitted through gerrit, github or gitlab and handled via standard code review.
 * Security patches or other discreetly-deployed code.
 * Applications running under Cloud VPS or Toolforge, even higher-visibility apps like Quarry.
 * Any user-JavaScript or Gadgets which may run on various Wikimedia wikis.
 * Code which has not gone through appropriate processes (TechCom RFC, the creation of a support plan, sponsorship by a Wikimedia Foundation team, etc.) so as to be a strong candidate for deployment upon Wikimedia production infrastructure.

Code that will never be reviewed:
 * Any variety of stub code - be it a mediawiki extension, service, etc. Boilerplate code is just that and cannot serve as a proxy for reviewing code that may one day exist.
 * Any Work-In-Progress (WIP) patch sets, regardless of their state of completion. If the code is in a stable, testable state, it should be code-reviewed and merged via gerrit, github, etc.
 * Any relevant patch sets which have not been code-reviewed and merged. Again, if the code is in a stable, testable state, it should be code-reviewed and merged via gerrit, github, etc. Exceptions can be made to this policy if a code merge is blocked on another, key review (say from a member of the Performance Team or SRE) but it will be the responsibility of the requester to ask for such an exception from the Security Team and confirm the current state of the code.

How are these requests prioritized?
While the Security Team would love to provide on-demand security readiness reviews for an unlimited number of projects and codebases each quarter, this is simply not possible given current resources and constraints. Given these realities, the below is a set of steps, rules and guidelines the Security Team uses to prioritize this work:
 * 1) At the beginning of each quarter, typically within the first few days or the first week, various Security Team engineers and project managers will convene to prioritize any open requests upon the secscrum workboard, where all security readiness reviews are tracked.
 * 2) A maximum of 6 reviews requests will be accepted to be completed for the quarter.  For some quarters, fewer than 6 reviews may be accepted, given the volume of current review requests and other commitments of the Security Team.
 * 3) Once a review has been accepted for a given quarter, a project manager from the Security Team will contact the requester via a comment on the relevant Phabricator review request task.  If all valid request information has been provided and all relevant code is in a production-ready state (close to deployment with low volatility), the review request will be scheduled for completion with a specific estimated date for completion.
 * 4) While the Security Team will strive to complete a review by a given estimated date of completion, we cannot always guarantee this.  In these rare cases, we will work with requesters to adjust expectations as necessary, while doing everything within our power to quickly and efficiently complete the review.

Secure Coding - Best Practices

 * All code SHOULD avoid the top 25 CWEs, and comply with the requirements of Security for developers/Architecture.
 * Libraries SHOULD encourage safe practices by the developers who use them, or clearly document when misuse can result in a security flaw.
 * Services SHOULD use a standard framework or service template (e.g. the Service Template for Node).
 * External applications (services, or applications such as media conversion utilities) used by the code SHOULD NOT have known, open security issues.


 * 1) Known Guides and Documentation
 * 2) What We Are Looking For
 * 3) Security Training Materials (somewhat dated)
 * 4) Third Party Code Review Checklist
 * 5) Security Checklist For Developers
 * 6) Security For Developers Tutorial
 * 7) Security For Developers Architecture


 * 1) Directive terms capitalized requirement level terms: https://www.ietf.org/rfc/rfc2119.txt
 * 2) Definitions