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

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

Review Required by: 1 February 2021

Purpose
To document the process and requirements for individuals in need of a pre-deployment security code review.

Before a new or significant change to an existing feature, extension, service, or library is deployed (or intended to be deployed) to production on SRE-managed hardware, it MUST have gone through the security readiness review process defined within this SOP.

Work product for which this SHALL NOT be relevant: Examples of code which SHALL NOT 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, even high-visibility apps like Quarry, etc.
 * Any user-JavaScript or Gadgets which may run on various Wikimedia wikis
 * 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 within 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 within 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.

If there are any questions as to what constitutes the requirement for a security review, please contact the Security Team (security-help@undefinedwikimedia.org).

Preparation
Typically, WMF teams or MediaWiki developers embarking on a new project should plan to have 2 or 3 check-ins with the Security Team. Initiatives MUST have a Security Readiness Review task in Phabricator documenting that a pre-deployment security readiness review has been completed. This includes addressing any blocking issues before the deployment of a new extension or major feature.

This review will ensure that the controls identified in any concept reviews have been implemented prior to deployment. Additionally, the Security Team will attempt to ensure that the initiative avoids common implementation flaws. New requests can be made via the Security Readiness Review request form.

If a task has already been created within Phabricator as a placeholder for a review, we ask that you provide the information from the aforementioned Phabricator form on said task.

Requests which are missing requested information will almost certainly be delayed or declined.

Possible Outcomes

 * No issues found, extension can be deployed (provided other requirements at Review queue are met). (Example: T148583)
 * Minor issues found, or any major issues found are straightforward fixes. Extension can be deployed once the found issues are fixed. (Example: T149808)
 * Major or complex security issues found. Once the identified issues are fixed, the extension/software will have to be re-reviewed. (Example: T133408)

Submission and Timelines

 * 1) As early as possible and a minimum of 30 days prior to the desired deployment date, the requester creates a complete Phabricator Task using the Security Readiness Review request form.   IMPORTANT : By default this request will be publicly visible.
 * 2) Weekly, the Security Team reviews requests that come into the queue.
 * 3) Security Team ensures the task has ALL required information; if the Task is missing information, the Security Coordinator sends the task back to the author and holds the task awaiting updated information.
 * 4)  IMPORTANT : Our goal of providing a 30 day turnaround time is only possible on tasks that are in all ways ready for review. Incomplete information, code changes, etc. will necessarily delay our process.
 * 5)  IMPORTANT : A git commit hash or version tag MUST be specified for every repository branch under review. If the code is within patch sets on gerrit or a pull request on github then see the guidelines under the Purpose section above.
 * 6)  IMPORTANT : Code with a strong likelihood of being deployed to Wikimedia production will be prioritized for review. While the Security Team would love to review every bit of code within the Wikimedia universe, it is often infeasible, and so prioritization must occur.
 * 7) If the task meets the prerequisite requirements the Security Team will approve the task, and assign it to an engineer and place the task in the  “In Progress” queue.
 * 8) See the #Security-Team-Reviews workboard for currently planned reviews.
 * 9) The “In Progress” column reflects all active Security Readiness Reviews.
 * 10) A security engineer will review the task and will comment and change status as appropriate.
 * 11) If your task is reviewed by an engineer and requires action on your part the task will be placed in the Waiting queue. The task may reside there for no more than 30 days.
 * 12) If the security engineer has not received a response within 30 days for the above, the task will be moved to the Frozen column.

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.
 * External applications (services, or applications such as media conversion utilities) used by the code SHOULD not have known, open security issues. The application SHOULD be supported by a competent security program.
 * For external application or libraries, a WMF team MUST be committed to being alerted about and fixing any security issues that are fixed by the upstream developers.
 * The people developing the code have already reviewed it, and believe it to be secure.

Required Information (The form prompts for all this)

 * 1) Name of tool/project
 * 2) Description of the tool/project
 * 3) Description of how the tool will be used at WMF
 * 4) Name of the individual/group requesting review and primary contact
 * 5) Name of the individual/group responsible for tool/project after deployment and primary contact
 * 6) The target date for deployment (or approximate date deployed if already in production or labs)
 * 7) Information from any review of the tool that has already been conducted
 * 8) Working test environment
 * 9) Programming language(s) used
 * 10) Source code repository location
 * 11) Upstream project home page (if applicable)
 * 12) WMF project home page (if applicable)
 * 13) Related Phabricator tickets
 * 14) Related patch set(s) or repository URLs with specified commit hash

If your project is not on the schedule and you believe it should be, or if you have any questions about the Security Teams Readiness Review process, please (contact the Security Team) as soon as possible.