124 lines
5.7 KiB
ReStructuredText
124 lines
5.7 KiB
ReStructuredText
==========================
|
|
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.
|
|
|
|
.. _vulnerability management team:
|
|
https://security.openstack.org/#openstack-vulnerability-management-team
|
|
.. _security-supported subset:
|
|
https://security.openstack.org/vmt-process.html#supported-versions
|
|
.. _processes: https://security.openstack.org/vmt-process.html
|
|
.. _templates:
|
|
https://security.openstack.org/vmt-process.html#templates
|
|
.. _report taxonomy:
|
|
https://security.openstack.org/vmt-process.html#incident-report-taxonomy
|
|
|
|
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.
|
|
|
|
.. _liaisons:
|
|
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
|
|
.. _core Security Team reviewers:
|
|
https://launchpad.net/~ossg-coresec
|
|
.. _security advisory: https://security.openstack.org/ossalist.html
|
|
|
|
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.
|
|
|
|
.. _keys:
|
|
https://security.openstack.org/#how-to-report-security-issues-to-openstack
|
|
|
|
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.
|
|
|
|
.. _security notes: https://wiki.openstack.org/wiki/Security_Notes
|
|
.. _OpenStack Security Guide: http://docs.openstack.org/sec/
|
|
.. _OpenStack Security Team:
|
|
https://wiki.openstack.org/wiki/Security_Teams
|
|
.. _secure development guidelines:
|
|
https://security.openstack.org/#openstack-secure-development-guidelines
|
|
.. _Bandit: https://wiki.openstack.org/wiki/Security/Projects/Bandit
|