User:Legoktm/Community security audits

Security is probably one of MediaWiki's biggest strengths, and we have a pretty good security review process. However, it doesn't really scale for the entire MediaWiki ecosystem, since the WMF security team doesn't have the peoplepower to review everything.

We should have a process in which other developers are designated as community security reviewers for extensions that aren't deployed to Wikimedia sites, and extension developers can request security reviews from them.

People are already doing security audits of MediaWiki extensions (example), so we really encourage security champions among the wider ecosystem, in a more standardized and systematic fashion.

Here's my proposal. I'm using the terminology security "audit" to differentiate it from the pre-existing Wikimedia security review practice.

  • Auditors should be active MediaWiki core or extension developers. Before becoming an auditor, interested people should perform two security audits of MediaWiki extensions, which will then be reviewed by Wikimedia Security Team members for completeness. If the security team member is satisfied with their work, then they'll be approved to be an auditor.
    • The use of having the Wikimedia Security Team do reviews is mostly a bootstrapping mechanism. At some point if we feel comfortable, we should let the group of auditors be self-sufficient.
  • Auditors can pick whatever they want to work on (they're volunteers!), and there will be a wiki page for developers/sysadmins to make requests for security audits.
  • MediaWiki developers and the Wikimedia Security Team should work together to create a security review checklist (similar to Best practices for extensions), both intended for developers to use when writing code, as well as for auditors to base their audits on.
  • Once completed, all security audits will be posted on, as a subpage of the extension page. The most recent review will be linked from the extension infobox.
  • If the audit turns up security issues, the auditor will contact the extension author/maintainer, and file a private Phabricator task for tracking. If feasible, the auditor will help resolve the issues.
    • Regardless of whether the issues are fixed, the security audit should be made public within 30 days (it helps no one if we do a security audit, find issues, and then don't tell anyone).
  • Depending on how well this goes, we should consider having security audits "expire" after a year, and require a re-audit. (Even if the extension hasn't changed, the MediaWiki core security model could have).

Issues for discussion:

  • Should we give security auditors information about existing security bugs in whatever they're reviewing? Maybe with extension maintainer approval. Note that there is intentionally no NDA/identification/etc. requirement for auditors.