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 -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
