[v4] dev-manual: add security team processes

Add the initial version of the section on vulnerability reports,
operations of the Security Team with a
transcription of https://wiki.yoctoproject.org/wiki/Security_private_reporting

Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
---
 documentation/dev-manual/index.rst            |   1 +
 .../dev-manual/security-subjects.rst          | 189 ++++++++++++++++++
 2 files changed, 190 insertions(+)
 create mode 100644 documentation/dev-manual/security-subjects.rst

> -----Original Message-----
> From: docs@lists.yoctoproject.org <docs@lists.yoctoproject.org> On Behalf Of
> Marta Rybczynska
> Sent: Wednesday, October 25, 2023 9:12 PM
> To: docs@lists.yoctoproject.org
> Cc: Marta Rybczynska <rybczynska@gmail.com>; Marta Rybczynska
> <marta.rybczynska@syslinbit.com>
> Subject: [PATCH v4][docs] dev-manual: add security team processes
> 
> Add the initial version of the section on vulnerability reports, operations of the
> Security Team with a transcription of
> https://wiki.yoctoproject.org/wiki/Security_private_reporting
> 
> Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
> ---
>  documentation/dev-manual/index.rst            |   1 +
>  .../dev-manual/security-subjects.rst          | 189 ++++++++++++++++++
>  2 files changed, 190 insertions(+)
>  create mode 100644 documentation/dev-manual/security-subjects.rst
> 
> diff --git a/documentation/dev-manual/index.rst b/documentation/dev-
> manual/index.rst
> index 3106b90a4..9ccf60f70 100644
> --- a/documentation/dev-manual/index.rst
> +++ b/documentation/dev-manual/index.rst
> @@ -42,6 +42,7 @@ Yocto Project Development Tasks Manual
>     runtime-testing
>     debugging
>     licenses
> +   security-subjects
>     vulnerabilities
>     sbom
>     error-reporting-tool
> diff --git a/documentation/dev-manual/security-subjects.rst
> b/documentation/dev-manual/security-subjects.rst
> new file mode 100644
> index 000000000..d96082029
> --- /dev/null
> +++ b/documentation/dev-manual/security-subjects.rst
> @@ -0,0 +1,189 @@
> +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
> +
> +Dealing with Vulnerability Reports
> +**********************************
> +
> +The Yocto Project and OpenEmbedded are open-source, community-based
> +projects used in numerous products. They assemble multiple other
> +open-source projects, and need to handle security issues and practices
> +both internal (in the code maintained by both projects), and external
> +(maintained by other projects and organizations).
> +
> +This manual assembles security-related information concerning the whole
> +ecosystem. It includes information on reporting a potential security
> +issue, the operation of the YP Security team and how to contribute in
> +the related code. It is written to be useful for both security
> +researchers and YP developers.
> +
> +How to report a potential security vulnerability?
> +=================================================
> +
> +If you would like to report a public issue (for example, one with a
> +released CVE number), please report it using the :yocto_bugs:`Security
> +Bugzilla </enter_bug.cgi?product=Security>`.
> +
> +If you are dealing with a not-yet-released issue, or an urgent one,
> +please send a message to security AT yoctoproject DOT org, including as
> +many details as
> +possible: the layer or software module affected, the recipe and its
> +version, and any example code, if available. This mailing list is
> +monitored by the Yocto Project Security team.
> +
> +For each layer, you might also look for specific instructions (if any)
> +for reporting potential security issues in the specific ``SECURITY.md``
> +file at the root of the repository. Instructions on how and where
> +submit a patch are usually available in ``README.md``. If this is your
> +first patch to the Yocto Project/OpenEmbedded, you might want to have a
> +look into the Contributor's Manual section
> +":ref:`contributor-guide/submit-changes:preparing changes for submission`".
> +
> +Branches maintained with security fixes
> +---------------------------------------
> +
> +See the
> +:ref:`Release process <ref-manual/release-process:Stable Release
> +Process>` documentation for details regarding the policies and
> +maintenance of stable branches.
> +
> +The :yocto_wiki:`Releases page </Releases>` contains a list of all
> +releases of the Yocto Project. Versions in grey are no longer actively
> +maintained with security patches, but well-tested patches may still be
> +accepted for them for significant issues.
> +
> +Security-reated discussions at the Yocto Project

minor typo  
 reated -> related



> +------------------------------------------------
> +
> +We have set up two security-related mailing lists:
> +
> +  -  Public List: yocto [dash] security [at] yoctoproject[dot] org
> +
> +    This is a public mailing list for anyone to subscribe to. This list is an
> +    open list to discuss public security issues/patches and security-related
> +    initiatives. For more information, including subscription information,
> +    please see the  :yocto_lists:`yocto-security mailing list info page </g/yocto-
> security>`.
> +
> +  - Private List: security [at] yoctoproject [dot] org
> +
> +    This is a private mailing list for reporting non-published potential
> +    vulnerabilities. The list is monitored by the Yocto Project Security team.
> +
> +
> +What you should do if you find a security vulnerability
> +-------------------------------------------------------
> +
> +If you find a security flaw: a crash, an information leakage, or
> +anything that can have a security impact if exploited in any Open
> +Source software built or used by the Yocto Project, please report this
> +to the Yocto Project Security Team. If you prefer to contact the
> +upstream project directly, please send a copy to the security team at
> +the Yocto Project as well. If you believe this is highly sensitive
> +information, please report the vulnerability in a secure way, i.e.
> +encrypt the email and send it to the private list. This ensures that the exploit is
> not leaked and exploited before a response/fix has been generated.
> +
> +Security team
> +=============
> +
> +The Yocto Project/OpenEmbedded security team coordinates the work on
> +security subjects in the project. All general discussion takes place
> +publicly. The Security Team only uses confidential communication tools
> +to deal with private vulnerability reports before they are released.
> +
> +Security team appointment
> +-------------------------
> +
> +The Yocto Project Security Team consists of at least three members.
> +When new members are needed, the Yocto Project Technical Steering
> +Committee (YP TSC) asks for nominations by public channels including a
> nomination deadline.
> +Self-nominations are possible. When the limit time is reached, the YP
> +TSC posts the list of candidates for the comments of project
> +participants and developers. Comments may be sent publicly or privately
> +to the YP and OE TSCs. The candidates are approved by both YP TSC and
> +OpenEmbedded Technical Steering Committee (OE TSC) and the final list
> +of the team members is announced publicly. The aim is to have people
> +representing technical leadership, security knowledge and
> +infrastructure present with enough people to provide backup/coverage
> +but keep the notification list small enough to minimise information risk and
> maintain trust.
> +
> +YP Security Team members may resign at any time.
> +
> +Security Team Operations
> +------------------------
> +
> +The work of the Security Team might require high confidentiality. Team
> +members are individuals selected by merit and do not represent the
> +companies they work for. They do not share information about
> +confidential issues outside of the team and do not hint about ongoing
> embargoes.
> +
> +Team members can bring in domain experts as needed. Those people should
> +be added to individual issues only and adhere to the same standards as
> +the YP Security Team.
> +
> +The YP security team organizes its meetings and communication as needed.
> +
> +When the YP Security team receives a report about a potential security
> +vulnerability, they quickly analyze and notify the reporter of the result.
> +They might also request more information.
> +
> +If the issue is confirmed and affects the code maintained by the YP,
> +they confidentially notify maintainers of that code and work with them
> +to prepare a fix.
> +
> +If the issue is confirmed and affects an upstream project, the YP
> +security team notifies the project. Usually, the upstream project analyzes the
> problem again.
> +If they deem it a real security problem in their software, they develop
> +and release a fix following their security policy. They may want to
> +include the original reporter in the loop. There is also sometimes some
> +coordination for handling patches, backporting patches etc, or just
> +understanding the problem or what caused it.
> +
> +When the fix is publicly available, the YP security team member or the
> +package maintainer sends patches against the YP code base, following
> +usual procedures, including public code review.
> +
> +What Yocto Security Team does when it receives a security vulnerability
> +-----------------------------------------------------------------------
> +
> +The YP Security Team team performs a quick analysis and would usually

The YP Security Team performs

Marta, Lee,

On 25.10.23 at 16:14, Lee Chee Yang wrote:
> +
> +Branches maintained with security fixes
> +---------------------------------------
> +
> +See the
> +:ref:`Release process <ref-manual/release-process:Stable Release
> +Process>` documentation for details regarding the policies and
> +maintenance of stable branches.
> +
> +The :yocto_wiki:`Releases page </Releases>` contains a list of all
> +releases of the Yocto Project. Versions in grey are no longer actively
> +maintained with security patches, but well-tested patches may still be
> +accepted for them for significant issues.
> +
> +Security-reated discussions at the Yocto Project
> minor typo
>   reated -> related

Fixed, thanks for the review and update!
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Merged into master-next.

Thanks again
Michael.