...

• Cloudstack Vulnerabilty Response Procedure  (another similar page  for Cloudstack)
• Mozilla Vulnerability Response Procedure
• IETF Draft Responsible Vulnerability Disclosure Process

Current process:

1. 1. Don't open JIRA Issues
   2. Don't open pull requests; do a direct commit
   3. Cut the security releases including release notes.
   4. Community Notification
   5. After announcement, create JIRA's.
   6. Three possibilities: 
      1. No grace period - Everyone knows before people can patch + poeople  who follow many projects on bugtraq know right away
      2. 15 business day grace period - People watching bugtraq will be unhappy with what looks sloppy reporting + Lets adopters try to patch first
      3. short grace period  - People don't really have time to benifit.
   7. Public disclosure: bugtraq

Draft Vulnerability Response Standard (derived form Cloudstack)

...

The security team asks that you please do not create publicly-viewable JIRA tickets related to the issue. If validated, a JIRA ticket with the security flag set will be created for tracking the issue in a non-public manner.

Current process:

...

.

...

Standard

• Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
• Security team investigates the issue to confirm/deny the presence of a vulnerability within CAS
• If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid.
• If issue is confirmed as a CAS vulnerability:
  • Security team notifies the Apereo Security team (happens automatically - they're on security@ list Is this true for cAS?)
  • Security team creates a Jira issue to document and track the issue, marking it private
  • Security team notifies release manager for target release version (need to modify for CAS)
  • Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
  • Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue
  • Security team works with Apereo Security Team ??? to reserve a CVE Identifier for future public release
  • Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
  • Testing is conducted to verify patch mitigates issue and does not cause regression errors.
  • Once fix is confirmed, notify release manager to ensure the fix is in the appropriate release.
  • Security team creates a vulnerability announcement
  • Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability. ??? Do we need a private repo for this
  • A new CAS release or hotfix is prepared and tested, containing the new security patch.
  • Distributor coordination is implemented to enable a coordinated announcement.
  • Security team posts vulnerability announcement to...
    • CAS dev list
    • CAS users list
    • CAS downloads page
    • CAS alerts web page???
    • The Bugtraq mailing list
  • After announcement, create JIRA's and update the release notes. This must happen AFTER the announcement.
  • Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
• After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.
  

...