Wikimedia Security Team/Security reviews

This page describes a crucial part of the Review queue process.

Review process
Before a security-critical feature, extension, service, or library is deployed by the WMF, it needs a security review by the security team. Additionally, third-party systems where confidential data is stored should have a security review as well.

Typically, WMF teams or individual mediawiki developers embarking on a new project should plan to have 2 or 3 checkins with the security team.

Concept review (optional)
When considering a new project, if there is any doubt that the feature might not be a good idea for security, or might negatively impact user privacy, you can optionally consult with the Security Team during the Concept phase of your project. Typically emailing the description of your project to the security team (security@undefinedwikimedia.org), or a 30 minute meeting with a team member, is enough to identify any potentially serious issues.

As an example, consider an extension that would allow users to include 's in wikipages, to embed content from other sites. This would be a concept that would be inappropriate for Wikimedia, as it would allow leaking user IP addresses to third parties, in violation of our Privacy Policy. Having a concept review before any work is done on the extension would prevent wasted effort on an idea that is not-workable in the context of Wikimedia.

Design review
Currently optional, but may become mandatory in the future.

When you have completed enough planning for your project to know broadly which systems will be involved, what data will be handled by your project, and what new services or endpoints users will interact with, then you should have a design review with the Security Team. This review is to ensure that you have controls in place to address specific threats, based on your architecture. During this review (or the optional Concept review), the Security Team can also suggest way to reduce the attack surface for your project, which will reduce the security requirements for your project.

Typically, this is a 60 minutes meeting between the technical or architectural leads for the project, and a member of the Security Team.

Although this review is optional, doing it allows issues to be identified early in the project, instead of at the end of the project.

Security and privacy review, for deployment (mandatory)
Projects must have a "Security Review" task in Phabricator documenting that they have performed a security review, and addressed any blockers, before they can deploy a new extension or major feature.

This review will ensure that controls identified in the design review have been implemented. Additionally, the team will attempt to ensure that the project avoids common implementation flaws.

There are three possible results of this review:
 * 1) No issues found, extension can be deployed (provided other requirements at Review queue are met). (Example: T148583)
 * 2) Only minor issues found, or any major issues found are straightforward fixes. Extension can be deployed once the found issues are fixed. (Example: T149808)
 * 3) Major or complex security issues found. Once the identified issues are fixed, the extension will have to be re-reviewed. (Example: T133408)

In the near future, the Security Team will also ensure that privacy impact documentation has been completed.

Expectations

 * All code should avoid the top 25 CWE's, 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.
 * Privacy impact has been considered, and mitigated when appropriate.
 * 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 team developing the code has already reviewed it internally, and believes it to be secure.

See also Wikimedia Security Team/Security reviews/What we are looking for

Requesting a review
Use the following link to open a Phabricator task to request a review:

Request a Review

This will create a Phabricator task pre-populated with a template which you may fill in with information about your project.

Alternately, you may manually create a Phabricator task and associate it with the #Security-Reviews project. However, it is greatly preferred that you use the template provided by the link above. Review requests should include:
 * Name of tool/project
 * Description of the tool/project
 * Description of how the tool will be used at WMF
 * Name of individual/group requesting review and primary contact
 * Name of individual/group responsible for tool/project after deployment and primary contact
 * Target date for deployment (or approximate date deployed if already in production or labs)
 * Information from any review of the tool that has already been conducted
 * Working test environment
 * Programming language(s) used
 * Source code repository location
 * Upstream project home page (if applicable)
 * WMF project home page (if applicable)
 * Related phabricator tickets
 * Related patchset(s)

Review schedule
Security reviews will be scheduled on a rolling basis.

See the #Security-Reviews workboard for currently planned reviews. Once you have filed a request, a member of the Security team will usually add it to the calendar after about a week. If your project is not on the schedule and you believe it should be, or if you have any questions about the security review process, please contact a member of the security team (security@undefinedwikimedia.org).