OpenStack engineers met in Austin last week to design the Newton cycle. Here is a report for the Security Project and other associated efforts.
Requirements for the vulnerability:managed governance tag
During Mitaka, the vulnerability management team ("VMT") introduced a new vulnerability:managed tag to help identify supported projects. In essence, this tag indicates that a project’s security bug reports are triaged by the VMT taxonomy. For class A reports, the VMT issues an OpenStack Security Advisory ("OSSA").
The VMT documented a set of requirements to get the tag:
- Deliverable repositories,
- Dedicated point of contact, usualy a subset of the core team called coresec,
- PTL agrees to act as a VMT liaison to escalate severe issues,
- Bug tracker reconfiguration, and
- Third-party review/audit/threat analysis.
The last point (item 5) intends to ensure that the VMT doesn’t become a bottleneck for projects with poor security practices or that have unknown fundamental flaws. By design, the VMT is a small team, composed of 3 volunteers. Thus, new projects must demonstrate that they won’t cause an unmanageable number of security bug reports.
In the next section, I will set-out how we can efficiently increase the number of vulnerability:managed projects as designed during the Newton summit etherpad.
What VMT members need to know
Since day 1, doing VMT work for OpenStack has been a challenging task due to:
- A wide attack surface,
- Source code and api version changes,
- Deployment modes with distinct threats, and
- Coordination between different communities.
Here is the list of questions that need to be answered when managing a new project:
- What are the input data formats and how are they processed ?
- Which actions are restricted to operators ?
- What has been considered a vulnerability in previous bug reports ?
- What can a malicious user do depends on:
- Available services, including the non-obvious ones, such as nova-novncproxy,
- API endpoint paths, including old versions, such as glance v1, and
- Every other network-facing service to which a user can connect.
A document answering the above questions will likely be required for any vulnerability:managed tag application. Moreover, already supported projects will also need to validate the above requirements in order to keep the tag.
This document needs to be maintained within the OpenStack community using open code review. The security-guide or project documentation are appropriate locations to publish it.
Major changes to the OpenStack release process were introduced last cycles:
- Integrated releases, such as 2015.1.2 are now gone,
- Projects may use different release models,
- Unified versions numbers semver, and
- Automated publication to website.
The "stable summit" set new goals for the Newton cycle:
- Increase stable release support to 18 months with an option for 6 additional months,
- Backwards compatibility for libraries, and
- Co-installability requirements.
End of life policy is the most important topic for the VMT since it increases the number of supported branchs. Infra and QA are also directly affected since they have to maintain the CI capacity for supported stable releases. While in theory it’s possible to extend support, here is a list of practical blockers to be addressed:
- Stable branch gates break too often, see openstack-health,
- Backport to old releases is time consuming when the affected code went through several refactors, and
- Long Term Stable (LTS) versions aren’t an option because upgrade process must deploy each versions.
In summary, Kilo release end of life won’t be extended and the branch will likely be closed soon, EOL: 2016-05-02. Further, external dependencies requirements are not supported by the VMT, but it is worth noting that a new Requirement Team will be created to manage this increasingly difficult situation.
Last but not least, there was a design session to discuss issue tracker for OpenStack projects. This is a critical topic for vulnerability management since most VMT work actually happens on the issue tracker.
OpenStack projects currently use launchpad.net to track issues and write blueprints for feature tracking. The workflow being sub-optimal, there is an on-going effort to replace launchpad by something better. Migration issues aside, the real concern is that we may end up with another sub-optimal solution which doesn’t justify the migration cost.
On the other hand, the OpenStack community initiated storyboard which is designed to address the exceptional needs of OpenStack development. Unfortunately, the project stalled due to the lack of reviewers.
The OpenStack community has three main options regarding issue tracking:
- Develop its own issue tracker (e.g. storyboard),
- Operate a ready-to-use solution (e.g. maniphest), or
- Use an external service (e.g. launchpad).
This topic will be discussed in the following weeks. Hopefully it will lead to a long term decision from the TC with Infra approval.
Once again, we have made great progress and I’m looking forward to further developments. Thank you all for the great OpenStack Newton Design Summit!
OpenStack Vulnerability Management Team