Vulnerability Management Process

The OpenNebula Vulnerability Management Team (VMT) is responsible for coordinating the process of evaluating, fixing and disclosing those security vulnerabilities reported by members of the OpenNebula Community. Members of the VMT are all part of the Engineering Team at OpenNebula Systems, the company that manages and coordinates the development of the OpenNebula project. Membership of this team is intentionally limited to a small number of people.

Supported Versions

The VMT coordinates patches fixing vulnerabilities in supported stable branches of OpenNebula, in addition to the master branch (next version under development).

Process

Each security bug is assigned a coordinator among the members of the VMT, who will be in charge of leading the fixing and disclosure process, and will be the main contact point for the member of the OpenNebula community reporting the vulnerability. These are the steps we follow:

Reception

A report should be sent as a private email to [email protected] (preferably encrypted, using our PGP Public Key).

Use the following template for your email and make sure that you complete all the relevant sections before submitting your report:

---

DESCRIPTION: [A clear and concise description of what the bug is]

TO REPRODUCE: [Steps to reproduce the behavior]

EXPECTED BEHAVIOR: [A clear and concise description of what you expected to happen]

DETAILS

- Affected Component: [e.g. Sunstone, Scheduler or Storage]

- Hypervisor: [e.g. KVM]

- Version: [e.g. 5.10]

ADDITIONAL CONTEXT: [Add any other context about the problem here]

---

Validation

The first steps performed by the VMT are to confirm the validity of the report and assign a ticket to the project’s core development team for confirmation of impact and determination of affected branches. During this process, the reported will be contacted by the VMT to confirm that the vulnerability report has been validated and to ask for further details, if necessary.

Once the report has been validated by the VMT, the issue should be treated as a potential security risk. The reporter will be asked not to make any public mention of this security vulnerability before the publication by the VMT of an official OpenNebula Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. However, vulnerability reporters retain final control over the disclosure of their findings. If for some reason they are uncomfortable with our Vulnerability Management Process, their choice of disclosure terms prevails.

For some lower-risk bugs or problems which may only be easy to solve in future releases, the VMT might recommend its re-submission as a non-critical vulnerability issue through the regular channels available on GitHub for reporting bugs and make feature requests.

Patch Development

For private vulnerability reports, the reporter and the projects’ core development review team will be in contact through the VMT coordinator assigned to the issue. A fix will be proposed as a patch to the current master branch and/or any affected supported branches, and evaluated internally only.

For public, non-critical vulnerability issues, once re-submitted through GitHub, patches can be proposed directly to the code review system by OpenNebula developers or Community members.

Patch Review

For a private vulnerability report once the initial patch has been developed, core development reviewers should review it and suggest updates or pre-approve it for merging. Privately-developed patches need to be pre-approved so that they can be fast-tracked through public code review later at disclosure time.

For public reports, OpenNebula’s usual public code review and approval processes apply.

Draft Impact Description

While a patch is being developed, the VMT coordinator will prepare a vulnerability description that will serve as the basis for the Security Advisory that will be finally published.

The description should properly credit the reporter, specify affected versions (including unsupported ones) and accurately describe impact and mitigation mechanisms.

Disclosure

In preparation for this, OpenNebula will make sure that there is a core reviewer and a stable maintainer available to help pushing the fix at disclosure time.

On the disclosure hour, a bug will be opened on GitHub and the patches pushed immediately for review on master and supported stable branches, fast-tracking all the required approvals.

Publish Advisory

Shortly after pushing the patches (potentially waiting for the first test runs to complete), a Security Advisory will be published:

• As a “Known Issue” on the relevant sections of the OpenNebula Documentation site.
• As a “Solved Issue” on the OpenNebula Community Forum.
• As an urgent announcement for OpenNebula Systems’ customers and partners through its Customer Portal.

Maintenance & Patch Releases

Critical vulnerabilities affecting the OpenNebula core will be addressed through an EE Maintenance Release and a CE Patch Release. While we make all our products open source under Apache License Version 2.0, the packages of our Enterprise Edition and the Enterprise Tools we’ve created for Corporate Users are distributed under commercial license terms only to those customers with an active OpenNebula Subscription. For more details, please visit our Release Policy.