During the summit in Atlanta, the Vulnerability Management Team gathered in a design session for the upcoming Juno cycle.
What is the VMT
OpenStack, like any other piece of code, has and will have bugs. Those with security implications must be addressed in a special way, as they can lead to numerous nefarious consequences such as data loss, service interruption or system compromise.
Since December 2011, there is a team in OpenStack that has been dedicated to security called the Vulnerability Management Team. Its responsibilities include coordinating the progressive disclosure of a vulnerability. This is all about making sure OpenStack users are as secure as possible. Here is some interesting facts:
- 71 OpenStack Security Advisories (OSSA) released in the past 3 years
- In the Icehouse cycle, out of ~83 security reported bugs, 25 lead to an OSSA (which is about 1 per week)
- ~21 projects are currently supported
The key steps of the vulnerability management process in OpenStack are:
- Once a security bug is reported, the team evaluates if it is an actual security vulnerability with the impacted project core developers. If it turns out to be exploitable, the OSSA task is confirmed.
- Along with development of patches, an impact description is drafted.
- The team requests and assigns a CVE identifier, a common index used by software authors and researchers as a standard method for identifying vulnerabilities.
- Once everything is reviewed, OpenStack stakeholders get an advance notification called pre-OSSA where they are given 3 to 5 business days to fix their setups before the bug is publicly disclosed.
- Finally the OSSA is sent to openstack-announce, openstack and oss-security mailing list.
What has been done for Icehouse
As discussed with maintainers we decided to define stricter “affected” versions. Each vulnerable version of OpenStack is now clearly identified and maintainers can more easily check if they have to update their packages.
Also, as decided during the Icehouse summit, Grizzly support stopped during Icehouse RC cycle. While this has been a hard decision for OpenStack users, the lack of community interest in keeping Grizzly test infrastructure running prevented us from testing fixes for this version.
What is coming for Juno
For this upcoming release of OpenStack here is what has been decided:
- OSSA documents are going to benefit from the OpenStack code review system to approve the final announcement. This will allow OSSG members to have a chance to review those as well. Sadly, due to the lack of private review, this will be at the very final stage of the process. This will also allow us to publish OSSA in a read-only reference location.
- We are going to formalize report types into multiple bug classes, mainly in order to differentiate bugs that require advisories from others that don’t.
- Upcoming OSSAs will now include a “severity” metric in order to help our users to assess if a fix is urgent and must be rapidly deployed.
- Last but not least, stable branch support is now extended to 15 months. The stable maintenance team will now also help us by providing security backports to supported stable branches when additional help is needed.
The VMT is a key part of OpenStack adoption and I am very proud to be part of this team, thanks to eNovance.
[…] During the summit in Atlanta, the Vulnerability Management Team gathered in a design session for the upcoming Juno cycle. What is the VMT OpenStack, like any other piece of code, has and will have … […]
[…] OpenStack: eNovance: Vulnerability Management in Juno During the summit in Atlanta, the Vulnerability Management Team gathered in a design session for the upcoming Juno cycle. Read more. […]
[…] OpenStack: eNovance: Vulnerability Management in Juno During the summit in Atlanta, the Vulnerability Management Team gathered in a design session for the upcoming Juno cycle. Read more. […]
[…] Tristan Cacqueray: Vulnerability Management in Juno […]