Security for developers/SDLC
This page is currently a draft.
More information and discussion about changes to this draft may be on the discussion page.
This is being developed to come to consensus about how we can continue and improve integrating security into MediaWiki's Software Development Lifecycle (SDLC).
Open questions from training
Q. How do we get security considered at the feature & architecture stages?
- Having a product manager who's empowered to say "this doesn't sound like a good idea" involved is good!
- thinking about threat modelling as a user story
Q. How do we integrate/get developers to use automated tools to catch implementation errors, e.g. for CSRF?
- Have a reusable job for such automated tools running regularly (e.g. on every patch) for Extensions and Services in our continuous integration so that for new Extensions and Service developers can easily enable them?
Security in the MediaWiki SDLC
There seem to be three major development structures where we want to better integrate security into the process:
- Long-term development efforts
- Teams are typically developing a number of small features towards a long-term goal and fixing bugs or refactoring the code
- Development is often organized into sprints (scrum process), or more ad hoc (kanban board, etc).
- Core, Mobile Teams, maybe VE fall into this
- Feature development
- Sprints of varying lengths are developing a single extension or major feature
- Most of the inititives by the Features core team fall into this.
- Volunteer-driven development
- Math, TimedMediaHandler, VipsScaler
For long-term development teams, having an designated security person ("security czar") watching out for issues throughout the normal process might be the best approach. They would need extra, regular training about the security issues that affect them.
For all development teams, having product managers able to identify features and applications that need further security review would help.
For volunteer-driven efforts, liaising and getting early input throughout the design process is important.
Some quick wins that may have a big impact on everyone:
- Having developers input paths for dynamic testing that are run as part of the general browser testing would be helpful.
- Bug template for reporting issues discovered in security architecture. Centralized reporting or the architecture issues we're seeing.
- Static code analysis