This work is licensed under a Creative Commons Attribution 3.0
Unported License.


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).


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.


  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. The deliverable’s repos should undergo a review, audit, or threat analysis looking for obvious signs of insecure design or risky implementation which could imply a large number of future vulnerability reports. The review, audit, or threat analysis may be done by the project team itself or an impartial third party. In the event the project team involved in the tagging peforms the review, audit, or threat analysis, the results must be validated by a third party. The VMT doesn’t stipulate which third party would perform this review or validation; for example members of the OpenStack Security Group (OSSG) might volunteer to provide their expertise or some other third party including sponsoring companies of a project may offer assistance. As much as anything this is a measure to keep the VMT’s workload down, since it is by necessity a group of constrained size and some of its processes simply can’t be scaled safely. Finally, the results of the review, audit, or threat analysis must be proposed as a gerrit review in the security-analysis repository. and accepted by the OpenStack Security Group (OSSG). Acceptance by the OpenStack Security Group (OSSG) of the documentation does not constitute a third party approval unless the OpenStack Security Group (OSSG) agrees in advance to acting as a third party approver.
  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.

Tag application process

Proposals to add or remove this tag must be reviewed by the VMT prior to final approval by the Technical Committee.


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 end-of-life.