Add a vulnerability management chapter

Change-Id: I4de5b9b24288d56b7322a499096d17d63d5eb92a

doc/source/vulnerability-management.rst

@@ -2,3 +2,122 @@
  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