Open Stack

Jeremy, a huge thanks for this fantastic reply! I have taken the liberty of
copying your responses directly into Neutron's "contributing" guide:
https://review.openstack.org/187267

I hope you don't mind.

On Fri, Jul 03, 2015, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2015-07-03 22:01:38 +0200 (+0200), Henry Gessau wrote:
> [...]
>> The question now arises about what to do when a security issue is
>> found in such an external repository that integrates with Neutron.
>>
>>  - How should such security issues be managed?
> 
> The OpenStack Vulnerability Management Team (VMT) follows a
> documented process[1] which can basically be reused by any
> project-team when needed.
> 
>>  - Should the OpenStack security team be involved?
> 
> The OpenStack VMT directly oversees vulnerability reporting and
> disclosure for a subset[2] of OpenStack source code repositories.
> However we're still quite happy to answer any questions you might
> have about vulnerability management for your own projects even if
> they're not part of that set. Feel free to reach out to us in public
> or in private.
> 
> Also, the VMT is an autonomous subgroup of the much larger OpenStack
> Security project-team[3]. They're a knowledgeable bunch and quite
> responsive if you want to get their opinions or help with
> security-related issues (vulnerabilities or otherwise).
> 
>>  - Does a CVE need to be filed?
> 
> It can vary widely. If a commercial distribution such as Red Hat is
> redistributing a vulnerable version of your software then they may
> assign one anyway even if you don't request one yourself. Or the
> reporter may request one; the reporter may even be affiliated with
> an organization who has already assigned/obtained a CVE before they
> initiate contact with you.
> 
>>  - Do the maintainers need to publish OSSN or equivalent documents?
> 
> OpenStack Security Advisories (OSSA) are official publications of
> the OpenStack VMT and only cover VMT-supported software. OpenStack
> Security Notes (OSSN) are published by editors within the OpenStack
> Security project-team on more general security topics and may even
> cover issues in non-OpenStack software commonly used in conjunction
> with OpenStack, so it's at their discretion as to whether they would
> be able to accommodate a particular issue with an OSSN.
> 
> However, these are all fairly arbitrary labels, and what really
> matters in the grand scheme of things is that vulnerabilities are
> handled seriously, fixed with due urgency and care, and announced
> widely--not just on relevant OpenStack mailing lists but also
> preferably somewhere with broader distribution like the Open Source
> Security mailing list[4]. The goal is to get information on your
> vulnerabilities, mitigating measures and fixes into the hands of the
> people using your software in a timely manner.
> 
>>  - Anything else to consider here?
> [...]
> 
> The OpenStack VMT is in the process of trying to reinvent itself so
> that it can better scale within the context of the "Big Tent." This
> includes making sure our policy/process documentation is more
> consumable and reusable even by project-teams working on software
> outside the scope of our charter. It's a work in progress, and any
> input is welcome on how we can make this function well for everyone.
> 
> [1] https://security.openstack.org/vmt-process.html
> [2] https://wiki.openstack.org/wiki/Security_supported_projects
> [3] http://governance.openstack.org/reference/projects/security.html
> [4] http://oss-security.openwall.org/wiki/mailing-lists/oss-security