User:CSteipp (WMF)/Secure development

This is a plan for improving our secure development process.

Security reviews take place at 5 stages during the development lifecycle:

Security architecture reviews for new projects, or high-risk features

The security team will work with other developers or groups to discuss architecture decisions to minimize risk early in development Security_for_developers/Architecture.

Static code analysis

Before a new extension is extension is deployed, it will be added to the regular set of code being scanned by various static analysis tools.

Before a new extension can be deployed, it must meet the minimum security criteria for static analysis. Existing extensions that contain too many flaws will not be deployed during the normal deployment cycle.

Manual code review

Code that has a high security risk will be reviewed manually by someone on the security team. Check Does_my_application_need_a_security_review to see if your code needs a manual review.

Security scanning in beta

New and existing extension will be scanned by a set of vulnerability scanners in beta. New extensions need to meet a minimum threshold of issues found before they can be enabled on production.

For existing extensions, private security bugs will be opened and assigned to the owner when a regression causes a new security issue in one of the scanners. The security team might verify these before opening bugs, or that might fall to the team's security enthusiast.

The scanning depends on selenium / browser tests to discover all of the entry points into a feature, so it important to have tests that exercise all inputs.

Security bugs

Security issues will continue to be reported in bugzilla. When possible, they will be assigned to the responsible team to fix.

For deployed extension, once a fix is developed, someone from the security team will verify the fix, patch the cluster, and release the patch with the next mediawiki release.