Vulnerability Management¶
OpenStack projects take security vulnerability reports seriously and handle them with care. The use cases for OpenStack software vary, but include high-profile services and exposed systems which could easily put sensitive data or other resources at risk of compromise if left vulnerable to exploitation.
Vulnerability Management Team¶
OpenStack has a vulnerability management team (VMT) which serves a number of purposes within the project. The OpenStack VMT provides direct vulnerability management for a security-supported subset of OpenStack software meeting established criteria, but more importantly maintains recommended processes, templates, a report taxonomy and similar tools which can be applied by any project team to ease the burden of managing their own vulnerability reports and publish corresponding advisories.
Embargoed Vulnerability Management¶
The vast majority of security vulnerability reports for OpenStack
software begin as private security bugs at
https://bugs.launchpad.net/ visible only to the OpenStack
vulnerability management team and the initial reporter. If the
bug is of sufficient severity (determined subjectively based on a
number of context-specific factors), effort will be taken to keep it
temporarily private while it is researched and necessary fixes are
discussed, developed and reviewed. This temporary secrecy is
referred to as an embargo and serves to allow time to prepare a
solution and communicate it to a vetted group of stakeholders such
as software distributions, deployers and service providers who may
need extra time to have these fixes in place before the
vulnerability becomes known to the general public.
During the embargo period, subject matter experts such as liaisons, project-specific core security review teams and the core Security Team reviewers may be subscribed to the bug to provide insight and assist in bringing it to conclusion. Once a fix has been drafted and downstream stakeholders have been warned, patches are pushed into the normal public code review system and a security advisory (OSSA) is sent to OpenStack and general free/open software mailing lists.
Public Vulnerability Reports¶
Many OpenStack security vulnerabilities start out within public view either as bugs and patches which are later discovered to imply some exploitable condition, or reports which the reporter or subject matter experts deem of minimal criticality, or issues which are simply not easily resolved in private due to the amount of additional community involvement required to thoroughly mitigate the associated risk. There are a variety of circumstances under which the additional resource and efficiency costs of embargoed vulnerability management simply outweigh the benefit of a brief window of secrecy, but which still ultimately end in a security advisory.
Security Contacts¶
If a bug reporter chooses not to file a bug report on their own but
still wishes to report a vulnerability in private, they can send
encrypted E-mail to one or more of the VMT members’ OpenPGP keys to
have a private security bug opened on their behalf.
Security Enhancements¶
It’s not at all uncommon, after review of the circumstances presented in a suspected vulnerability report, to deem it unnecessary to issue an associated security advisory. Factors which weigh on this decision include whether the bug is actually exploitable, whether it’s a common/known condition pervading much of OpenStack software, whether the fix can be safely backported to stable branches without introducing potentially disruptive behavior changes, whether it depends on configurations already documented as insecure, whether it requires the existence of another more significant vulnerability to leverage successfully, and whether it’s a vulnerability of some other dependency rather than within OpenStack software itself.
These can still represent bugs which need to be fixed, and perhaps which increase the overall defense-in-depth security of the software… so-called security hardening opportunities. In many of these cases non-advisory recommendations may still be published in the form of security notes (OSSN), addenda to the OpenStack Security Guide. Also new and existing projects can benefit from a variety of proactive resources provided by the OpenStack Security Team such as the secure development guidelines and the Bandit source code security analyzer.
