...
THIS IS STILL WIP and has not been approved by TSC yet. If you would like to report a security issue please refer to current procedure .
Glossary
Term | Definition |
Embargo | A time period where vendors 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"). (from source) |
Subject matter expert | A developer or other specialist who can provide contextual information that helps to determine the validity and impact of a potential security vulnerability. |
Security SME | A security SME is a specialist who is familiar with the ONAP security vulnerability procedures and security in general |
Peer reviewed | 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. |
Security Response Procedure
Reference Procedures
Credits
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 In an attempt to avoid re-inventing the wheel, the ONAP vulnerability management process borrows from the following procedures:
- The Linux Kernel process for reporting security issues
- The OpenDaylight vulnerability management process
- Recommendations for a minimal security response process
- The fd.io vulnerability management process
...
Vulnerability Management Process
The ONAP vulnerability management subcommittee (VMS) is responsible for coordinating vulnerabilities during its whole life cycle (from reporting till coordinated disclosure).
Members of the team are independent and security-minded folks 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 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 serving as a point of contact for the TSC and community to the security 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.
...
Supported projects and versions
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.
Security supported versions
All versions of ONAP still supported by the project, and affected by the security issue, must be patched. This will usually start with the latest version of an affected project. Following that, the vulnerability sub-committee will work with downstream maintainers to ensure that the patch is applied to all maintained and affected versions.
/Should be checked with tsc/
As ONAP is very young project with a lot of code coming in every release. That's why for now we support ONLY LATEST RELEASE and MASTER BRANCH (next version under development) Note: The ONAP vulnerability sub-committee needs to provide accurate information about the version the flaw was first introduced so that vendors operating still maintaining older product lines can backport fixes outside of the upstream maintenance window .
Third party components
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.
...
{onap_vulnerability_sub-commitee_member}, on half of the ONAP vulnerability sub-committeeRoadmap
Action Items
Topic | Assignee | Description | Status |
organizational | Stephen | Send out a call for participation and form the ONAP vulnerability sub-committee | |
infrastructure | Phil | Create a private mailing list for vulnerability management sub-committee | |
organizational | Vulnerability committee | Elect a chair | |
infrastructure | Phil | Enable private security issues in JIRA | |
infrastructure | security sub-committee | Create a public page indicating contact information for the ONAP vulnerability sub-committee. | |
documentation | Stephen | Create a public page detailing the vulnerability management process and how to report security problems to ONAP | |
documentation | security sub-committee | Create a single page listing the security issues fixed in ONAP projects (advisories) | |
communication | security sub-committee | Ensure the new security process is announced on all major mailing lists. |
References
- Common Vulnerabilities and Exposure (https://cve.mitre.org/about/faqs.html )
- CVE numbering authorities (https://cve.mitre.org/cve/cna.html)
- CVE FAQ (https://cve.mitre.org/about/faqs.html#what_is_cve_identifier )
...