Security Process Proposals June 2010
Draft proposals
These are draft proposals presented at the Denver 2010 Project Co-ordination meeting for discussion and community adoption. Please read these proposals in conjunction with the Security Policy. If you have feedback, please comment on this page or contact Former user (Deleted).
Both the 2.x and 3.x working groups at the co-ordination meetings assented to the proposals listed here (as of 18 June 2010).
Security Statement
The Sakai community believes that secure software is of the utmost importance.
As managers, we will prioritize allocating people's time to addressing critical security vulnerabilities above other Sakai activity.
As developers, we will prioritize fixing critical security vulnerabilities above other bug fixes or feature development.
Reactive Security Process
- We aim to address all reported security issues within 7 calendar days (analyse, fix, merge, supply patches and communicate to security contacts).
- If the above is not possible, an initial security advisory will be issued to security contacts within 7 calendar days of a security issue being reported.
- A designated Sakai Security Officer will own the incident process from notification to final resolution (including sending out the initial advisory).
- There will be 4 designated Sakai Security Officers: 1 directly appointed by the Foundation, 3 from the community. The community roles will rotate after 6 or 12 months:
- Anthony Whyte (Foundation)
- Megan May
- To be volunteered
- Stephen Marquard (6 months)
Proactive Security Process
- We will recruit a volunteer for Security WG Lead (or Leads for 2.x and 3.x)
- The Security WG Lead helps focus community attention and effort on security, through promoting and documenting best practices and continuous improvement.
- The Security WG Lead will also seek to promote consensus in the Security WG, or failing that take a decision on appropriate responses to reported security issues (for example where there is a range of possible solutions to an issue).