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 might be eligible for a security readiness review. But given current resources and constraints, here 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 typically submitted through gerrit and handled via standard code review
 * Security patches or other discreetly-deployed code
 * Applications running under Cloud VPS or Toolforge, even high-visibility apps like Quarry, etc.
 * 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.