The processes defined are to report issues against the ONAP platform itself, not the supporting infrastructure that is used by this opensource community.
A time period where key ONAP stakeholders have access to details concerning the security vulnerability, with an understanding not to publish these details or the fixes they have prepared. The embargo ends with a coordinated release date (CRD). (adapted from source)
Subject Matter Expert (SME)
A developer or other specialist who can provide contextual information that helps to determine the validity and impact of a potential security vulnerability.
A security SME is a specialist who is familiar with the ONAP security vulnerability procedures and security in general.
In the context of a patch, the term peer reviewed refers to the patch having been reviewed by the ONAP vulnerability sub-committee and any other relevant key stakeholders. There is not yet a strict definition of the number of people who need to have reviewed the patch, or how they provide sign off.
This document is strongly based on Vulnerability Management Process defined by Open Stack Community.
The whole document is licensed under Creative Commons Attribution 3.0 License.
Additionally, in an attempt to avoid re-inventing the wheel, the ONAP vulnerability management process borrows from the following procedures:
The ONAP vulnerability management subcommittee (VMS) is responsible for coordinating the response to a reported vulnerability from initial reporting until coordinated disclosure.
Members of the team are independent and security-minded people who ensure that vulnerabilities are dealt with in a timely manner and that downstream stakeholders are notified in a coordinated and fair manner. Where a member of the team is employed by a downstream stakeholder, the member does not give their employer prior notice of any vulnerabilities. In order to reduce the disclosure of a vulnerability in the early stages, membership of this team is intentionally limited to a small number of people.
This activity is approved and supported by the ONAP TSC and operates under the ONAP vulnerability sub-committee. The sub-committee functions are as described below. The committee has a chair, appointed by the membership from among the membership, who is responsible for seeing that work proceeds and serves as a point of contact for the TSC and community to the vulnerability sub-committee. The chair and membership, as well as pointers to this charter and the relevant email lists are document at link-to-page.
All ONAP projects are currently in scope for vulnerability support. The participants of the ONAP projects are expected to support the ONAP vulnerability procedures when required.
As ONAP is very young project with a lot of code coming in every release. Even through we are interested in receiving bugs for all ONAP releases that are currently in use, we will develop patches ONLY FOR THE LATEST RELEASE and FOR THE MASTER BRANCH (next version under development) . Unfortunately ensuring security in very early stages of the project is not always possible, that is why we declare three first releases (Amsterdam, Beijing, Casablanca) as unsupported in terms of security bug fixes. Dublin is going to be first version that will be supported as described by above rule.
Third party components (i.e. dependencies) are only in scope for security support if they are statically compiled or otherwise bundled by an ONAP project. Dynamically linked dependencies should patch security issues independent of ONAP.
Vulnerabilities of managed functions (e.g. VNFs) are out of the scope of ONAP, however if an ONAP vulnerability has a dependence with a managed function, the managed functions vulnerability procedures will be used to coordinate the issue.
All the tasks mentioned below should be executed by VMS coordinator who is chosen and assigned by VMS based on their internal agreements on case by case basis.
A report can be received either as a ticket in Vulnerability Reporting Jira Project, email to firstname.lastname@example.org or as a private encrypted email to one of the VMS members .
Steps that has to be completed depend on reception method:
Edit the ticket description by adding embargo notice in the beginning (VMS team)
VMS should do its best to provide a prompt confirmation to the reporter. Bug reception should be confirmed no later than within 3 business days.
It's worth noting that every new bug in the Vulnerability Reporting Jira Project by default is visible only to reporter and VMS members.
The bug must then be confirmed to be a security problem and assigned initial severity level. This may require the inclusion of additional subject matter experts to determine if the problem needs to be treated as a security flaw. If the bug is determined not be a security issue then a statement should be added indicating the justification. The bug should then be opened and fixed by following the normal development process.
The PTL or project security contact point is responsible for fixing the bug or delegating the work to the subject matter experts. Even through patch development can be delegated by PTL or project security contact, only the VMS has a right to add new people to the ticket. Thus, the PTL should explicitly request access for additional developers by adding a comment with their LFID.
A fix should be prepared against current master branch and other supported affected branches and attached to the ticket. Do not sent it to the public code review system (gerrit) unless the ticket is already public.
Security fixes, especially critical should be treated as highest-priority tasks. If project delays are encountered at this or any subsequent stage of the process, the VMS and other interested parties may escalate the issue to the TSC but without providing any details on bug itself apart from reporter, severity, impacted project and versions.
Once the patch has been attached to the ticket, patch should be reviewed and pre-approved by PTL or delegated committers. 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, usual public code review process apply.
While the patch is being developed, the VMS coordinator prepares a vulnerability description that will be communicated to downstream stakeholders, and 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. The VMS coordinator should use the template below.
The description is validated by the reporter and the PTL.
If reporter did not request for a CVE number on his or her own, VMS coordinator should attempt to obtain one to ensure full traceability. This is generally done as the patch gets nearer to final approval. The approved impact description is submitted through MITRE’s CVE Request form. The request type is
Request a CVE ID, the e-mail address should be that of the requester, and for critical reports the coordinator’s OpenPGP key should be pasted into the field provided.
In the required section set the check boxes indicating the product is not CNA-covered and that no prior CVE ID has been assigned, select an appropriate vulnerability type (using
Unknown to enter a free form type if there is nothing relevant on the drop-down), set the vendor to
ONAP, and the product and version fields to match the
affected project name and
version from the impact description. In the optional section set the radio button for confirmed/acknowledged to
Yes, choose an appropriate attack type in the drop-down (often this is
Context-dependent for our cases), check the relevant impact checkboxes, attempt to fill in the affected components and attack vector fields if possible, paste in the suggested description from the prose of the impact description (usually omitting the first sentence as it’s redundant with other fields), put the
$CREDIT details in the discoverer/credits field, and the bug URL (along with Gerrit URLs for patches if already public) in the references field. If the report is still private, note that in the additional information field like
report is currently under embargo and no disclosure date has been
scheduled at this time.
At the bottom of the page, fill in the security code and click the submit request button. If some fields contain invalid data they will be highlighted red; correct these, update the security code and submit request again until you get a confirmation page.
MITRE returns the assigned CVE. VMS coordinator adds it to the jira ticket, and retitles the bug to “$TITLE ($CVE)”.
Once the patches are approved and the CVE is assigned, a signed email with the vulnerability description is sent to the downstream stakeholders by VMS coordinator or other designated VMS member. The disclosure date is set to 3-5 business days, excluding Monday/Friday and holiday periods, at 1400 UTC. No stakeholder is supposed to deploy public patches before disclosure date.
For non-embargoed, public vulnerabilities no separate downstream advance notification is sent.
In preparation for this, make sure you have a PTL available to help pushing the fix at disclosure time.
On the disclosure hour, open ticket to public, push patches to Gerrit for review on master.
PTL and committers who pre-approved the patch should, as soon as possible add +2 on pushed patch and merge it.
Publish the ONAP Security Advisory and update the ticket title to “[OSA-$NUM] $TITLE”.
Embargo reminder can be removed at that point.
MITRE’s CVE Request form should be used again at this point, but instead select a request type of
Notify CVE about a
publication and fill in the coordinator’s e-mail address, provide a link to the advisory (the URL to official OSA), the CVE IDs covered, and the date published. Once more, fill in the security code at the bottom of the page and submit request.
There will be occasions where the vulnerability management process is not followed and the issue is publicly disclosed before reporting it to the vulnerability subcommittee. In this case it's important to properly identify the issue and create a task to make it traceable. As the flaw has been already disclosed there is no need to keep the Jira ticket private so it should be set to publicly available in a very beginning of the process. In general, standard vulnerability management process should be followed, just embargoed disclosure should be skipped.
Occasionally it may happen that the bug reporter or some else break the embargo and disclose details of the flaw before official disclosure date. In this case a timely answer is extremely important.