Import VMT oversight information from governance
The OpenStack TC has decided to stop using its "governance tags" mechanism for recording specific details about project deliverables. We previously relied on a vulnerability:managed tag to indicate the deliverables overseen by the VMT, as well as documenting expectations for the teams responsible for them. Tags, being deliverable-specific rather than repository-specific, were never a great fit for us. When bringing this information into our own documentation, it's now reworked as a list of specific Git repositories for simplicity and granularity. The expectations have also been edited and shortened in order to accommodate this change, but are still effectively the same as they were in governance. Change-Id: Ie3c0cc38fc071716420c12b3f6de4a320428bd04
This commit is contained in:
Jeremy Stanley
parent
4b7ca58f75
commit
1aa37b1663
|
|
@ -10,6 +10,7 @@
|
|||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
repos-overseen
|
||||
vmt-process
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,156 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
.. _repositories overseen:
|
||||
|
||||
=======================
|
||||
Repositories Overseen
|
||||
=======================
|
||||
|
||||
Reports of suspected vulnerabilities for the following OpenStack
|
||||
source repositories officially fall under Vulnerability Management
|
||||
Team (VMT) oversight:
|
||||
|
||||
* `openstack/barbican <https://opendev.org/openstack/barbican>`_
|
||||
* `openstack/castellan <https://opendev.org/openstack/castellan>`_
|
||||
* `openstack/cinder <https://opendev.org/openstack/cinder>`_
|
||||
* `openstack/glance <https://opendev.org/openstack/glance>`_
|
||||
* `openstack/glance_store <https://opendev.org/openstack/glance_store>`_
|
||||
* `openstack/heat <https://opendev.org/openstack/heat>`_
|
||||
* `openstack/horizon <https://opendev.org/openstack/horizon>`_
|
||||
* `openstack/keystone <https://opendev.org/openstack/keystone>`_
|
||||
* `openstack/keystonemiddleware <https://opendev.org/openstack/keystonemiddleware>`_
|
||||
* `openstack/neutron <https://opendev.org/openstack/neutron>`_
|
||||
* `openstack/neutron-lib <https://opendev.org/openstack/neutron-lib>`_
|
||||
* `openstack/nova <https://opendev.org/openstack/nova>`_
|
||||
* `openstack/os-brick <https://opendev.org/openstack/os-brick>`_
|
||||
* `openstack/oslo.config <https://opendev.org/openstack/oslo.config>`_
|
||||
* `openstack/python-barbicanclient <https://opendev.org/openstack/python-barbicanclient>`_
|
||||
* `openstack/python-cinderclient <https://opendev.org/openstack/python-cinderclient>`_
|
||||
* `openstack/python-glanceclient <https://opendev.org/openstack/python-glanceclient>`_
|
||||
* `openstack/python-heatclient <https://opendev.org/openstack/python-heatclient>`_
|
||||
* `openstack/python-keystoneclient <https://opendev.org/openstack/python-keystoneclient>`_
|
||||
* `openstack/python-neutronclient <https://opendev.org/openstack/python-neutronclient>`_
|
||||
* `openstack/python-novaclient <https://opendev.org/openstack/python-novaclient>`_
|
||||
* `openstack/python-saharaclient <https://opendev.org/openstack/python-saharaclient>`_
|
||||
* `openstack/python-swiftclient <https://opendev.org/openstack/python-swiftclient>`_
|
||||
* `openstack/python-troveclient <https://opendev.org/openstack/python-troveclient>`_
|
||||
* `openstack/sahara <https://opendev.org/openstack/sahara>`_
|
||||
* `openstack/sahara-dashboard <https://opendev.org/openstack/sahara-dashboard>`_
|
||||
* `openstack/sahara-extra <https://opendev.org/openstack/sahara-extra>`_
|
||||
* `openstack/sahara-image-elements <https://opendev.org/openstack/sahara-image-elements>`_
|
||||
* `openstack/sahara-plugin-ambari <https://opendev.org/openstack/sahara-plugin-ambari>`_
|
||||
* `openstack/sahara-plugin-cdh <https://opendev.org/openstack/sahara-plugin-cdh>`_
|
||||
* `openstack/sahara-plugin-mapr <https://opendev.org/openstack/sahara-plugin-mapr>`_
|
||||
* `openstack/sahara-plugin-spark <https://opendev.org/openstack/sahara-plugin-spark>`_
|
||||
* `openstack/sahara-plugin-storm <https://opendev.org/openstack/sahara-plugin-storm>`_
|
||||
* `openstack/sahara-plugin-vanilla <https://opendev.org/openstack/sahara-plugin-vanilla>`_
|
||||
* `openstack/swift <https://opendev.org/openstack/swift>`_
|
||||
* `openstack/trove <https://opendev.org/openstack/trove>`_
|
||||
|
||||
The `teams`_ responsible for maintenance of the source code within
|
||||
these repositories have agreed to meet the expectations enumerated
|
||||
below.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
1. Embargoes for privately-submitted reports of suspected
|
||||
vulnerabilities shall not last more than 90 days, except under
|
||||
unusual circumstances. Following the embargo expiration, reports
|
||||
will be made publicly visible regardless of whether any advisory
|
||||
has been issued or patch provided.
|
||||
|
||||
2. The VMT will not track or issue advisories for external software
|
||||
components. Only source code provided by official OpenStack
|
||||
project teams is eligible for oversight by the VMT. For example,
|
||||
base operating system components included in a server/container
|
||||
image or libraries vendored into compiled binary artifacts are
|
||||
not within the VMT's scope.
|
||||
|
||||
3. Repositories must have versioned releases to qualify for VMT
|
||||
oversight. Vulnerabilities warrant advisories if they appear in
|
||||
official releases or on `maintained <phases>`_ stable branches.
|
||||
Vulnerabilities only present in master since the last release, or
|
||||
only on branches under `extended maintenance <phases>`_, will not
|
||||
have their disclosure coordinated by the VMT. Pre-releases,
|
||||
release candidates and milestones are not considered official
|
||||
releases for the purpose of this policy.
|
||||
|
||||
4. The defect tracker for each overseen repository must be
|
||||
configured to initially only provide access for the VMT for
|
||||
privately-submitted reports. It is the responsibility of the VMT
|
||||
to determine whether suspected vulnerabilities are reported
|
||||
against the correct repository and redirect them when possible,
|
||||
since reporters are often unfamiliar with our project structure
|
||||
and may choose incorrectly. It implies some loss of control for
|
||||
the project team over initial triage of bugs reported privately
|
||||
as suspected vulnerabilities, but helps minimize the number of
|
||||
people who have unnecessary knowledge of them prior to public
|
||||
disclosure and so reduces the risk of prematurely ending an
|
||||
embargo.
|
||||
|
||||
5. The team must have a dedicated point of contact for security
|
||||
issues, so that the VMT can engage them to triage reports of
|
||||
potential vulnerabilities. Teams with more than five core
|
||||
reviewers should (so as to limit the unnecessary exposure of
|
||||
private reports) settle on a subset of these to act as security
|
||||
core reviewers whose responsibility it is to be able to confirm
|
||||
whether a bug report is accurate/applicable or at least know
|
||||
other subject matter experts they can in turn subscribe to
|
||||
perform those activities in a timely manner. They should also be
|
||||
able to review and provide pre-approval of patches attached to
|
||||
private bugs, which is why at least a majority are expected to be
|
||||
core reviewers for their repositories. These should be members of
|
||||
a group contact in the team's defect tracker so that the VMT can
|
||||
easily subscribe them to new reports.
|
||||
|
||||
6. The team must identify a `security liaison`_, serving as a point
|
||||
of escalation for the VMT in situations where severe or lingering
|
||||
vulnerability reports are failing to gain traction toward timely
|
||||
and thorough resolution. If one is not explicitly delegated, the
|
||||
PTL is that team's implicit liaison.
|
||||
|
||||
7. Repositories should have automated testing for important
|
||||
features. Tests need to be feasible for the VMT and security
|
||||
reviewers to run locally while evaluating patches under embargo,
|
||||
and must also run within the context of OpenStack's official
|
||||
continuous integration infrastructure. This helps reduce the risk
|
||||
of approved security fixes creating new bugs when rushed through
|
||||
public code review at the time of disclosure, and also decreases
|
||||
the chance of creating additional work for the VMT issuing errata
|
||||
later.
|
||||
|
||||
8. Projects are encouraged to undertake a review, audit, or threat
|
||||
analysis of their software in order to proactively identify
|
||||
likely security weaknesses. In the event the project team
|
||||
performs it, the results should ideally also be validated by a
|
||||
third party (which could just be other members of the community
|
||||
not involved directly in that project). Refreshing the analysis
|
||||
immediately following each major release is suggested, but an
|
||||
outdated analysis is still more useful than none at all. This is
|
||||
a recommendation in order to keep the VMT's workload to a
|
||||
necessary minimum, but is not a strict requirement.
|
||||
|
||||
Updating
|
||||
--------
|
||||
|
||||
Proposals to add or remove repositories in the oversight list will
|
||||
be evaluated by the VMT following OpenStack's code review process.
|
||||
|
||||
Deprecation
|
||||
-----------
|
||||
|
||||
A repository should only be removed from VMT oversight under extreme
|
||||
circumstances, when the VMT is no longer able to adequately handle
|
||||
its vulnerabilities. Care should be taken to only discontinue
|
||||
vulnerability management for future non-patch releases, while
|
||||
continuing to handle vulnerabilities on prior `maintained <phases>`_
|
||||
branches if at all possible until such time as they reach `extended
|
||||
maintenance <phases>`_ or `end of life <phases>`_.
|
||||
|
||||
.. _teams: https://governance.openstack.org/tc/reference/projects/
|
||||
.. _security liaison: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
|
||||
.. _phases: https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
|
||||
|
|
@ -23,12 +23,10 @@ Supported versions
|
|||
------------------
|
||||
|
||||
The Vulnerability Management team coordinates patches fixing
|
||||
vulnerabilities in supported stable branches (corresponding to
|
||||
vulnerabilities in maintained stable branches (corresponding to
|
||||
previous major releases) of OpenStack, in addition to the master
|
||||
branch (next version under development), for all `security supported
|
||||
projects`_.
|
||||
|
||||
.. _security supported projects: http://governance.openstack.org/reference/tags/vulnerability_managed.html
|
||||
branch (next version under development), for all :ref:`repositories
|
||||
overseen`.
|
||||
|
||||
Process
|
||||
-------
|
||||
|
|
@ -97,10 +95,10 @@ in any commit messages so it will be updated automatically).
|
|||
|
||||
If project-side delays are encountered at this or any subsequent
|
||||
stage of the process, the VMT and other interested parties may reach
|
||||
out to that project's `Vulnerability Management Liaison`_ requesting
|
||||
more immediate attention to the issue.
|
||||
out to that project's `security liaison`_ requesting more immediate
|
||||
attention to the issue.
|
||||
|
||||
.. _Vulnerability Management Liaison: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
|
||||
.. _security liaison: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
|
||||
|
||||
Patch review
|
||||
^^^^^^^^^^^^
|
||||
|
|
|
|||
Loading…
Reference in New Issue