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 <fu...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
