The way we manage this on CouchDB is that we have a separate, and private, security@ list.
This is where we ask users to submit CVEs to, and where we discuss fixes. We get the fix into a release, along with anything else that needs to go out. Once the release is made, we disclose the CVA in the changelog on master, and in JIRA, and announce. I do not think that we open JIRA tickets for CVEs, but we probably should once they are announced, even if we close them immediately. We don't strictly need the security@ list, but it allows non-PMC members to work on the fix. On Thu, Sep 20, 2012 at 11:54 PM, Clement Chen <[email protected]>wrote: > Hi John, > > Thanks for bring this topic up. I think you lay out the scope of the > security team very well. Just want to comment a little bit on the current > status of security work on CloudStack: > > 1. On the source code review front, Fortify has been run on CloudStack > code since 3.x. Currently license is shared so it is great that you got a > dedicated license for CloudStack. Going forward I think it is worth to > consider integrating Fortify with Jenkins so newly check-in codes will go > through Fortify and potential issues can be assigned automatically. Of > course Fortify also needs to be fine-tuned to lower the number of false > positives. > > 2. On the security testing front, webapp security testing tools such as > IBM AppScan has been used to scan the management server. Vulnerability > scanners such as Nessus have been used to scan the system VMs. Also a > limited amount of manual pen testing has been performed on 3.x. > > Many bugs have been filed as the result of the above activities. But most > of the bugs are "private" due to security reasons. David suggested that we > opened up fixed security bugs and obtained CVEs for them. I think doing so > will improve the security posture of CloudStack in the long term but in the > short term it might put some users at risk. So I guess my question to the > community is "do you think we should open up security bugs (fixed or > unfixed)?" > > Thanks. > > -Clement > > -----Original Message----- > From: John Kinsella [mailto:[email protected]] > Sent: Thursday, September 20, 2012 8:50 AM > To: <[email protected]> < > [email protected]> > Subject: CloudStack Security Team > > As this topic came up again, I wanted to discuss it without stealing from > the IRC channel discussion. > > Basically - should CloudStack have a "security team" as a formal group? I > see real and marketing value for such a thing, but I don't want to create > structure/overhead that isn't needed. So really I guess my question to the > community is "Do you feel the need for such a team?" > > One news point that hasn't been announced, yet: In the last week or two > I've managed to get HP to donate a license for Fortify on Demand to the > CloudStack community. I've run into some small technical bumps in preparing > the code to be scanned but hoping to have a preliminary scan done in the > next week or so. My goal is to get a scan done and catch any low-hanging > fruit before the 4.0 release, but I'm not quite ready to commit to that > yet. We'll see... :) > > I'll lay out what I consider the scope of such a team to be: > * Provide application security expertise - As ACS produces a software > product, most of the work would be here, so I'll break this one out: > * Code review - A security team would participate in performing manual > or tool-assisted security reviews before major releases or after > significant changes were made to the code base. > * Secure coding assistance - either in general practice or when issues > found during a review need to be remediated, the security team would > provide guidance to the development community on best practices in writing > secure code. > * Architecture and design review - when new functionality is being > added, security team could provide guidance (input sanitization, encryption > algorithms, API key management comes to mind) > * Incident response - In the event of a issue being found in ACS software > or the website/etc, this team could help respond and interact with other > Apache groups to respond to issues. > * Define security best practices - Along with having common network and > infrastructure architectures, ACS should also recommend best practices for > setting up management servers, hosts, and the like. This sounds like a > small category, but I suspect there could be a lot of use cases to cover > here. > > Others I'm probably missing, but you get the gist. > > Presuming this may go forward, I'd love to hear from others who have a > security background (or decent exposure and want to grow) and would be > interested in being part of such a team. > > John > -- NS
