openstack
/
governance
Code Issues Proposed changes

Remove the vulnerability:managed tag 

The VMT has moved all relevant information previously conveyed by
the vulnerability:managed governance tag into its own documentation,
so this can be safely removed.

Change-Id: I69c7f73403ddef74078715f72b3548f46b849581
Depends-On: https://review.opendev.org/830476
This commit is contained in:
Jeremy Stanley 2022-02-22 16:13:42 +00:00
parent 0f758605cc
commit c6554fe825
4 changed files with 0 additions and 187 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
reference/legacy.yaml
View File

@ -49,8 +49,6 @@ barbican:
retired-on: 2019-05-22
repos:
- openstack/castellan-ui
tags:
- vulnerability:managed
Chef OpenStack:
ptl:

38
reference/projects.yaml
View File

@ -47,7 +47,6 @@ barbican:
repos:
- openstack/barbican
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
ansible-role-atos-hsm:
@ -72,8 +71,6 @@ barbican:
python-barbicanclient:
repos:
- openstack/python-barbicanclient
tags:
- vulnerability:managed
liaisons:
tc_members: [jungleboyj, diablo_rojo]
blazar:
@ -128,7 +125,6 @@ cinder:
repos:
- openstack/cinder
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
cinder-specs:
@ -147,7 +143,6 @@ cinder:
repos:
- openstack/os-brick
tags:
- vulnerability:managed
- stable:follows-policy
python-brick-cinderclient-ext:
repos:
@ -158,7 +153,6 @@ cinder:
repos:
- openstack/python-cinderclient
tags:
- vulnerability:managed
- stable:follows-policy
rbd-iscsi-client:
repos:
@ -343,7 +337,6 @@ glance:
- openstack/glance
tags:
- assert:follows-standard-deprecation
- vulnerability:managed
- stable:follows-policy
glance-specs:
release-management: none
@ -356,13 +349,11 @@ glance:
repos:
- openstack/glance_store
tags:
- vulnerability:managed
- stable:follows-policy
python-glanceclient:
repos:
- openstack/python-glanceclient
tags:
- vulnerability:managed
- stable:follows-policy
liaisons:
tc_members: [dansmith, jungleboyj]
@ -384,7 +375,6 @@ heat:
repos:
- openstack/heat
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
heat-agents:
@ -418,7 +408,6 @@ heat:
repos:
- openstack/python-heatclient
tags:
- vulnerability:managed
- stable:follows-policy
tosca-parser:
repos:
@ -441,7 +430,6 @@ horizon:
repos:
- openstack/horizon
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
ui-cookiecutter:
@ -643,7 +631,6 @@ keystone:
repos:
- openstack/keystone
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
keystone-specs:
@ -663,7 +650,6 @@ keystone:
- openstack/keystonemiddleware
tags:
- stable:follows-policy
- vulnerability:managed
pycadf:
repos:
- openstack/pycadf
@ -673,7 +659,6 @@ keystone:
repos:
- openstack/python-keystoneclient
tags:
- vulnerability:managed
- stable:follows-policy
ldappool:
repos:
@ -1089,7 +1074,6 @@ neutron:
- openstack/neutron
tags:
- stable:follows-policy
- vulnerability:managed
- assert:follows-standard-deprecation
neutron-dynamic-routing:
repos:
@ -1101,7 +1085,6 @@ neutron:
- openstack/neutron-lib
tags:
- stable:follows-policy
- vulnerability:managed
neutron-specs:
release-management: none
repos:
@ -1118,8 +1101,6 @@ neutron:
python-neutronclient:
repos:
- openstack/python-neutronclient
tags:
- vulnerability:managed
neutron-fwaas-dashboard:
repos:
- openstack/neutron-fwaas-dashboard
@ -1157,7 +1138,6 @@ nova:
repos:
- openstack/nova
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
nova-specs:
@ -1168,7 +1148,6 @@ nova:
repos:
- openstack/python-novaclient
tags:
- vulnerability:managed
- stable:follows-policy
os-vif:
repos:
@ -2146,7 +2125,6 @@ oslo:
- openstack/castellan
tags:
- stable:follows-policy
- vulnerability:managed
cookiecutter:
release-management: none
repos:
@ -2200,7 +2178,6 @@ oslo:
repos:
- openstack/oslo.config
tags:
- vulnerability:managed
- stable:follows-policy
oslo.context:
repos:
@ -2681,73 +2658,62 @@ sahara:
repos:
- openstack/python-saharaclient
tags:
- vulnerability:managed
- stable:follows-policy
sahara:
repos:
- openstack/sahara
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-dashboard:
repos:
- openstack/sahara-dashboard
tags:
- vulnerability:managed
- stable:follows-policy
sahara-extra:
repos:
- openstack/sahara-extra
tags:
- vulnerability:managed
- stable:follows-policy
sahara-image-elements:
repos:
- openstack/sahara-image-elements
tags:
- vulnerability:managed
- stable:follows-policy
sahara-plugin-ambari:
repos:
- openstack/sahara-plugin-ambari
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-cdh:
repos:
- openstack/sahara-plugin-cdh
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-mapr:
repos:
- openstack/sahara-plugin-mapr
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-spark:
repos:
- openstack/sahara-plugin-spark
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-storm:
repos:
- openstack/sahara-plugin-storm
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-vanilla:
repos:
- openstack/sahara-plugin-vanilla
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-tests:
@ -2901,13 +2867,11 @@ swift:
repos:
- openstack/python-swiftclient
tags:
- vulnerability:managed
- stable:follows-policy
swift:
repos:
- openstack/swift
tags:
- vulnerability:managed
- stable:follows-policy
- assert:follows-standard-deprecation
swift-bench:
@ -3150,13 +3114,11 @@ trove:
repos:
- openstack/python-troveclient
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
trove:
repos:
- openstack/trove
tags:
- vulnerability:managed
- assert:follows-standard-deprecation
trove-dashboard:
repos:

1
reference/tags/index.rst
View File

@ -13,5 +13,4 @@ Current tags
:maxdepth: 1
assert_follows-standard-deprecation
vulnerability_managed
stable_follows-policy

146
reference/tags/vulnerability_managed.rst
View File

@ -1,146 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
.. _`tag-vulnerability:managed`:
=======================
vulnerability:managed
=======================
This tag is part of the vulnerability-classification system for
vulnerability reporting and tracking across project
deliverables. ``vulnerability:managed`` indicates that a
deliverable's vulnerability report reception and disclosure are
handled directly by the OpenStack Vulnerability Management team
(VMT).
Application to current deliverables
===================================
.. tagged-projects:: vulnerability:managed
Rationale
=========
The VMT is building out automation and reporting for vulnerability
management processes in order to better accommodate the rapid growth
of the OpenStack ecosystem. In an order to scale availability of
its processes beyond its current charter and capacity, a formal
acknowledgement of the list of project deliverables directly
handled by the VMT (rather than managed independently by individual
project teams) is best maintained through application of a
governance-related tag.
Requirements
============
1. Since the vulnerability:managed governance tag applies to
deliverables, all repos within a given deliverable must meet the
qualifying criteria. This means that if some repos in a
deliverable are in good enough shape to qualify, their
vulnerability management could be held back by other repos in the
same deliverable. It might be argued that perhaps this makes them
separate deliverables, in which case the governance reference
documentation should get an update to reflect that first.
2. The deliverable must have a dedicated point of contact for
security issues (which could be shared by multiple deliverables
in a given project-team if needed), so that the VMT can engage
them to triage reports of potential vulnerabilities. Deliverables
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 the
deliverable. These should be members of a group contact (for
example a <something>-coresec team) in the deliverable's defect
tracker so that the VMT can easily subscribe them to new bugs.
3. The PTL for the deliverable should agree to act as (or delegate)
a vulnerability management 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.
4. The defect tracker for the repos within the deliverable should be
configured to initially only provide access for the VMT to
privately-reported vulnerabilities. It is the responsibility of
the VMT to determine whether suspected vulnerabilities are
reported against the correct deliverable 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 in some cases helps
reduce the number of people who have knowledge of them prior to
public disclosure.
5. Projects are encouraged to undertake a review, audit, or threat
analysis of the deliverable 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). If possible, the results
should be proposed to the :repo:`openstack/security-analysis`
repository in Gerrit and reviewed or refined there. 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 requirement for
adding the tag.
6. All repos for the deliverable covered 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.
7. The VMT will not track or issue advisories for external software
components. Only source code provided by official OpenStack
project teams is eligible for support from 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.
8. Deliverables must tag releases to qualify for VMT oversight.
Vulnerabilities warrant advisories if they appear in official
releases or on supported stable branches. Vulnerabilities only
present in master since the last release, or only on branches
under extended maintenance, 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.
9. Embargoes for privately-reported vulnerabilities shall not last
more than 90 days, except under unusual circumstances. Following
the embargo expiration, reports will be publicly visible
regardless of whether an advisory has been issued.
Tag application process
=======================
Proposals to add or remove this tag must be reviewed by the VMT
prior to final approval by the Technical Committee.
Deprecation
===========
The ``vulnerability:managed`` tag should only be removed from
deliverables under extreme circumstances, when the VMT is no longer
able to adequately handle these vulnerabilities. Care should be
taken to only discontinue vulnerability management for future
non-patch releases, while continuing to handle vulnerabilities on
already existing ``stable`` release branches if at all possible
until such time as they reach extended maintenance or end-of-life.