From 522b8c8bc65e9614e5583e4b52d9bee7a56b023a Mon Sep 17 00:00:00 2001
From: Marta Rybczynska <marta.rybczynska@huawei.com>
Date: Wed, 16 Jun 2021 09:53:54 +0200
Subject: [PATCH] Add the CVE policy
Add the place for security-related policies and the CVE policy describing the
way of handling security vulnerabilities.
Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
---
definitions.rst | 2 +
index.rst | 1 +
security/cve_policy.rst | 253 ++++++++++++++++++++++++++++++++++++++++
security/index.rst | 15 +++
4 files changed, 271 insertions(+)
create mode 100644 security/cve_policy.rst
create mode 100644 security/index.rst
diff --git a/definitions.rst b/definitions.rst
index a3fd838..0b9b9ed 100644
--- a/definitions.rst
+++ b/definitions.rst
@@ -3,3 +3,5 @@
.. SPDX-License-Identifier: CC-BY-4.0
.. |main_project_name| replace:: All Scenarios OS
.. |contact_info| replace:: <TBD>
+.. |security_contact| replace:: <TBD>
+.. |security_public_key| replace:: <TBD>
diff --git a/index.rst b/index.rst
index a8212cc..b78e807 100644
--- a/index.rst
+++ b/index.rst
@@ -31,6 +31,7 @@ daily life.
repos/index
building-project-documentation
ip-policy/index
+ security/index
code-of-conduct
community-chat-platform
releases/index
diff --git a/security/cve_policy.rst b/security/cve_policy.rst
new file mode 100644
index 0000000..5c7d3ec
--- /dev/null
+++ b/security/cve_policy.rst
@@ -0,0 +1,253 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. include:: ../definitions.rst
+
+Vulnerability Handling Process (draft)
+######################################
+
+|main_project_name| aims to build a secure system from the foundation, applying
+the best industry practices in terms of development quality. However, as in
+every software project, bugs do happen. Some of them will offer a possibility
+to be exploited by an attacker and are called security vulnerabilities. This
+process explains how we handle security issues and extends the more generic bug
+handling process.
+
+We work in the open, including the process of handling security issues. To
+protect deployed products, sometimes we need to delay releasing information
+related to security issues, following the industry best practices. However, all
+information about vulnerabilities is becoming publicly available at the end.
+
+How to report a vulnerability?
+******************************
+
+If you think you have found a security issue in our distribution, please contact
+us immediatelly by posting a confidential issue in our bug tracker in a
+dedicated security project (include details on how to make it confidential), or
+by email using the address |security_contact|.
+
+Your report should contain a description of the issue, the steps you took to
+reproduce the issue (including the image name), affected versions, and, if
+known, any mitigations for the issue.
+
+If desired, you can also use GPG-encrypted email using our public key
+|security_public_key|.
+
+We aim to acknowledge the reception within one working day, and responding with
+a first assessment within three working days. We follow a 90 days disclosure
+timeline.
+
+We will be happy to acknowledge your work in the vulnerability announcement, and
+will do so if you do not object.
+
+This first section is included in the ``SECURITY.md`` file in our high-level
+project repositories.
+
+We use responsible vulnerability disclosure, and you can read more about this
+kind of disclosures in the `Vulnerability Disclosure Cheat Sheet from OWASP
+<https://cheatsheetseries.owasp.org/cheatsheets/
+Vulnerability_Disclosure_Cheat_Sheet.html>`__ or the detailed `CERT Guide to
+Coordinated Vulnerability Disclosure
+<https://vuls.cert.org/confluence/display/CVD/The+CERT+Guide+to+Coordinated+
+Vulnerability+Disclosure>`__ .
+
+Security Response Team (SRT)
+****************************
+
+Our Security Response Team (SRT) is reviewing reported security issues and
+updating the security policies. Members of the team are chosen by the project
+partners and elected by and from the project developers. Ideally, they should
+have security experience. The SRT has a minimum of two members.
+
+The SRT may decide the reported issue is indeed a security vulnerability (with
+assigned severity), a non-confidential bug, a feature request, or the feature is
+working as expected. The team notifies the reporter of the decision and
+provides explanations. If the issue is classified as a bug, the team converts
+it to a normal bug. If it is a feature request, the team asks the reporter to
+create a feature request and closes the issue. If the feature is working as
+expected, the team closes the security issue. The SRT also sets up the issue
+domain (for example compiler, base system etc).
+
+The SRT also makes an initial decision if the issue is in the code maintained by
+the projects (issues where we are upstream) or maintained outside the project
+(issues where we are downstream). This decision can be changed later if new
+information becomes available.
+
+The SRT meets weekly on a status meeting and participates in the general
+Bug triage/prioritization meeting.
+
+Classification of issues
+************************
+
+Security issues are classified as high, medium, and low severity. As a rule of
+thumb, we map the Base CVSS score from v3.1 in the following way:
+
+- 0 to 3.9 - low severity
+
+- 4.0 to 6.9 - medium severity
+
+- 7.0 and above - high severity
+
+When the issue is in the code maintained by the project
+*******************************************************
+
+When the source code where the issue comes from is maintained by the Project,
+the SRT creates a confidential ticket about the issue and
+assigns it to the relevant developer. The security team also verifies which
+versions are affected.
+
+If the security team judges it could be exploited, they request a CVE number for
+the issue and set up the embargo duration. It is by default 90
+days, and may be different if necessary (for example, if the fix will be
+complicated to deploy, or the issue will be known earlier for some reasons).
+
+The CVE number is mentioned in the confidential ticket, but should not be used
+in any other communication until the end of the embargo. The commit messages
+and documentation should be stating what was fixed (a NULL pointer, a missing
+lock, etc).
+
+The fix should be developed in a private repository and the reporter may
+be taking part in the development if they wish so.
+
+When the fix is available, it should be included in the main branch and
+backported to the release branches. If the issue is of 'high' severity, an
+immediate bugfix release should be produced. If it is a 'medium' or 'low'
+severity, the fix waits until the next regular bugfix release. In the case of a
+critical issue, the security team together with the release team may decide in
+distributing patches to the affected users.
+
+Handling upstream security issues
+*********************************
+
+If the issue was identified in upstream code, we do report an upstream security
+issue using the upstream project's process. We track the investigation status
+and the fix in our bug tracking system. When a fix is available, we do an
+update of the affected source, with backporting if necessary.
+
+If the upstream project does not respond, or does respond very slowly, we may
+decide to develop a patch on our own. In this case, the vulnerability is using
+the process for issues where we are upstream.
+
+Detailed workflow
+*****************
+
+Our process contains four phases: monitoring, assessment, remedy, and
+notification.
+
+Monitor
+^^^^^^^
+
+We actively monitor the ecosystem for potential security issues in the code
+developed by us, and in the code we distribute. This includes monitoring the
+official CVE list and other vulnerability databases, running code analysis tools,
+monitoring related blog posts or conference presentations. In addition to that,
+a regular bug might be marked as a potential security issue. If a potential issue appears,
+any project member (or an external observer) may fill in a security issue.
+
+As we depend on much upstream code, we also monitor specific mailing lists
+informing about security issues in those projects, including special
+notification lists for issues under embargo.
+
+This step has no equivalent in our Bug policy.
+
+Assess
+^^^^^^
+
+When we learn about a potential security issue, we start by acknowledging the
+information.
+
+If the issue comes from a CVE database, we verify if we are affected by the
+vulnerability at all (for example, we are not affected by the software we do not
+include directly, nor by a dependency).
+
+The SRT reproduces the issue during the assessment process and documents the
+needed steps, including configuration details (like package versions), system
+(like the processor architecture), and commands used.
+
+The SRT declares a security issue if it compromises one or more of the three
+features: avaliability, integrity, or confidentiality.
+
+When assessing an issue, the SRT may confirm it is a security issue or
+decide it is a regular bug. The team may also decide that a feature is missing
+or it behaves as intentionally designed and specified.
+
+In all cases, the SRT notifies the reporter of the assessment.
+
+Our aim is to acknowledge the reception within one working day, and respond with
+a first assessment within three working days.
+
+This step is an equivalent of the Triage and Prioritize steps of the Bug process.
+
+Remedy
+^^^^^^
+
+When the issue is confirmed as a security issue, the process of developing a fix
+begins. The reporter may be included in the process if they wish so. The SRT
+also applies for a CVE issue number and decides if there will be an embargoed
+notification before the public release.
+
+The SRT notifies the developers who should know about the issue and who should
+develop the fix. The communication happens over a private channel.
+
+Developers create a patch and associated test cases in a private branch. They
+also backport the fix to supported releases. In the case of non-public issues,
+the developer should mention in the patch description only what is fixed, not
+include any reference to the CVE. A fix might have a title like ‘fix a crash in
+module X’ or 'add a missing unlock in module Y'.
+
+They also prepare the release for issues with 'high' severity. 'Medium' and
+'low' severity issues are fixed in regular bugfix releases.
+
+We follow the rules of the upstream projects, if applicable.
+
+This step is an equivalent of the Fix step of the Bug process.
+
+Notify
+^^^^^^
+
+If an embargoed notification happens, it is sent between 5 to 30 days before the
+expected publication date. The actual timeframe depends on the situation and
+affected parties. For example, if deployed devices are affected, the SRT may
+choose a longer time to allow patching of the vulnerable devices. The embargoed
+notification includes the CVE identification number, description of the issue,
+affected versions, the patch itself and the way it will be distributed, the
+public disclosure date, and the reporter credits. The SRT monitors the
+responses to the notification messages to fix any outstanding issues.
+
+When the issue enters this phase, all documentation of the issue needs to be
+ready. The SRT and developers prepare a security advisory (if appropriate),
+the information for the release notes and the release announcement.
+
+This step (with the Publish one described below) is an equivalent of the Release
+step of the Bug process.
+
+Publish
+^^^^^^^
+
+The publication step consits of releasing the information about the issue publicly.
+The information prepared earlier is published on the public disclosure date. The SRT
+updates the CVE information.
+
+The release notes contains a list of all vulnerabilities fixed in the release.
+For issues with important impact, the SRT might decide on a dedicated advisory.
+
+This step (with the Notify one described above) is an equivalent of the Release
+step of the Bug process.
+
+Glossary
+--------
+
+- CVE (Common Vulnerabilities and Exposures) - a common system for vulnerability
+ naming and referencing. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
+- CVSS (Common Vulnerability Score System) - a score standard for security
+ vulnerabilities, ranging from 0.0 (no impact) to 10.0 (critical impact). https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System
+
+Acknowledgements
+----------------
+
+This process was inspired by the `OSS vulnerability guide
+<https://github.com/google/oss-vulnerability-guide/blob/main/guide.md>`__,
+`OpenSSF vulnerability-disclosures WG
+<https://github.com/ossf/wg-vulnerability-disclosures>`__,
+`Zephyr project security policy <https://www.zephyrproject.org/security/>`__.
diff --git a/security/index.rst b/security/index.rst
new file mode 100644
index 0000000..4bafe38
--- /dev/null
+++ b/security/index.rst
@@ -0,0 +1,15 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. include:: ../definitions.rst
+
+Security Policies
+#################
+
+This chapter describes the security policies of |main_project_name|.
+
+.. toctree::
+ :maxdepth: 1
+
+ cve_policy
--
GitLab