Here's an example announcement: http://s.apache.org/469
On Tue, Sep 25, 2012 at 12:06 PM, Noah Slater <[email protected]> wrote: > 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 > -- NS
