summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMarta Rybczynska <rybczynska@gmail.com>2023-10-25 15:12:02 +0200
committerSteve Sakoman <steve@sakoman.com>2023-11-09 04:44:46 -1000
commit05b8a1b5c1f06fd047f428948535c2da63d0c4a6 (patch)
tree2870668eb137bac0e50ec69d1db1fcccae5b970d
parentf2f7ea77d5786122d40961ce4c134b7b58dc5562 (diff)
downloadpoky-05b8a1b5c1f06fd047f428948535c2da63d0c4a6.tar.gz
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 (From yocto-docs rev: 763d66c72bf60dc06195acc6168a9535fdf7b302) Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com> Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
-rw-r--r--documentation/dev-manual/index.rst1
-rw-r--r--documentation/dev-manual/security-subjects.rst189
2 files changed, 190 insertions, 0 deletions
diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst
index 3618e51c8d..e731a70476 100644
--- a/documentation/dev-manual/index.rst
+++ b/documentation/dev-manual/index.rst
@@ -44,6 +44,7 @@ Yocto Project Development Tasks Manual
44 runtime-testing 44 runtime-testing
45 debugging 45 debugging
46 licenses 46 licenses
47 security-subjects
47 vulnerabilities 48 vulnerabilities
48 sbom 49 sbom
49 error-reporting-tool 50 error-reporting-tool
diff --git a/documentation/dev-manual/security-subjects.rst b/documentation/dev-manual/security-subjects.rst
new file mode 100644
index 0000000000..1b02b6a9e9
--- /dev/null
+++ b/documentation/dev-manual/security-subjects.rst
@@ -0,0 +1,189 @@
1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3Dealing with Vulnerability Reports
4**********************************
5
6The Yocto Project and OpenEmbedded are open-source, community-based projects
7used in numerous products. They assemble multiple other open-source projects,
8and need to handle security issues and practices both internal (in the code
9maintained by both projects), and external (maintained by other projects and
10organizations).
11
12This manual assembles security-related information concerning the whole
13ecosystem. It includes information on reporting a potential security issue,
14the operation of the YP Security team and how to contribute in the
15related code. It is written to be useful for both security researchers and
16YP developers.
17
18How to report a potential security vulnerability?
19=================================================
20
21If you would like to report a public issue (for example, one with a released
22CVE number), please report it using the
23:yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`.
24
25If you are dealing with a not-yet-released issue, or an urgent one, please send
26a message to security AT yoctoproject DOT org, including as many details as
27possible: the layer or software module affected, the recipe and its version,
28and any example code, if available. This mailing list is monitored by the
29Yocto Project Security team.
30
31For each layer, you might also look for specific instructions (if any) for
32reporting potential security issues in the specific ``SECURITY.md`` file at the
33root of the repository. Instructions on how and where submit a patch are
34usually available in ``README.md``. If this is your first patch to the
35Yocto Project/OpenEmbedded, you might want to have a look into the
36Contributor's Manual section
37":ref:`contributor-guide/submit-changes:preparing changes for submission`".
38
39Branches maintained with security fixes
40---------------------------------------
41
42See the
43:ref:`Release process <ref-manual/release-process:Stable Release Process>`
44documentation for details regarding the policies and maintenance of stable
45branches.
46
47The :yocto_wiki:`Releases page </Releases>` contains a list
48of all releases of the Yocto Project. Versions in gray are no longer actively
49maintained with security patches, but well-tested patches may still be accepted
50for them for significant issues.
51
52Security-related discussions at the Yocto Project
53-------------------------------------------------
54
55We have set up two security-related mailing lists:
56
57 - Public List: yocto [dash] security [at] yoctoproject[dot] org
58
59 This is a public mailing list for anyone to subscribe to. This list is an
60 open list to discuss public security issues/patches and security-related
61 initiatives. For more information, including subscription information,
62 please see the :yocto_lists:`yocto-security mailing list info page </g/yocto-security>`.
63
64 - Private List: security [at] yoctoproject [dot] org
65
66 This is a private mailing list for reporting non-published potential
67 vulnerabilities. The list is monitored by the Yocto Project Security team.
68
69
70What you should do if you find a security vulnerability
71-------------------------------------------------------
72
73If you find a security flaw: a crash, an information leakage, or anything that
74can have a security impact if exploited in any Open Source software built or
75used by the Yocto Project, please report this to the Yocto Project Security
76Team. If you prefer to contact the upstream project directly, please send a
77copy to the security team at the Yocto Project as well. If you believe this is
78highly sensitive information, please report the vulnerability in a secure way,
79i.e. encrypt the email and send it to the private list. This ensures that
80the exploit is not leaked and exploited before a response/fix has been generated.
81
82Security team
83=============
84
85The Yocto Project/OpenEmbedded security team coordinates the work on security
86subjects in the project. All general discussion takes place publicly. The
87Security Team only uses confidential communication tools to deal with private
88vulnerability reports before they are released.
89
90Security team appointment
91-------------------------
92
93The Yocto Project Security Team consists of at least three members. When new
94members are needed, the Yocto Project Technical Steering Committee (YP TSC)
95asks for nominations by public channels including a nomination deadline.
96Self-nominations are possible. When the limit time is
97reached, the YP TSC posts the list of candidates for the comments of project
98participants and developers. Comments may be sent publicly or privately to the
99YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded
100Technical Steering Committee (OE TSC) and the final list of the team members
101is announced publicly. The aim is to have people representing technical
102leadership, security knowledge and infrastructure present with enough people
103to provide backup/coverage but keep the notification list small enough to
104minimize information risk and maintain trust.
105
106YP Security Team members may resign at any time.
107
108Security Team Operations
109------------------------
110
111The work of the Security Team might require high confidentiality. Team members
112are individuals selected by merit and do not represent the companies they work
113for. They do not share information about confidential issues outside of the team
114and do not hint about ongoing embargoes.
115
116Team members can bring in domain experts as needed. Those people should be
117added to individual issues only and adhere to the same standards as the YP
118Security Team.
119
120The YP security team organizes its meetings and communication as needed.
121
122When the YP Security team receives a report about a potential security
123vulnerability, they quickly analyze and notify the reporter of the result.
124They might also request more information.
125
126If the issue is confirmed and affects the code maintained by the YP, they
127confidentially notify maintainers of that code and work with them to prepare
128a fix.
129
130If the issue is confirmed and affects an upstream project, the YP security team
131notifies the project. Usually, the upstream project analyzes the problem again.
132If they deem it a real security problem in their software, they develop and
133release a fix following their security policy. They may want to include the
134original reporter in the loop. There is also sometimes some coordination for
135handling patches, backporting patches etc, or just understanding the problem
136or what caused it.
137
138When the fix is publicly available, the YP security team member or the
139package maintainer sends patches against the YP code base, following usual
140procedures, including public code review.
141
142What Yocto Security Team does when it receives a security vulnerability
143-----------------------------------------------------------------------
144
145The YP Security Team team performs a quick analysis and would usually report
146the flaw to the upstream project. Normally the upstream project analyzes the
147problem. If they deem it a real security problem in their software, they
148develop and release a fix following their own security policy. They may want
149to include the original reporter in the loop. There is also sometimes some
150coordination for handling patches, backporting patches etc, or just
151understanding the problem or what caused it.
152
153The security policy of the upstream project might include a notification to
154Linux distributions or other important downstream projects in advance to
155discuss coordinated disclosure. These mailing lists are normally non-public.
156
157When the upstream project releases a version with the fix, they are responsible
158for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and
159the CVE record published.
160
161If an upstream project does not respond quickly
162-----------------------------------------------
163
164If an upstream project does not fix the problem in a reasonable time,
165the Yocto's Security Team will contact other interested parties (usually
166other distributions) in the community and together try to solve the
167vulnerability as quickly as possible.
168
169The Yocto Project Security team adheres to the 90 days disclosure policy
170by default. An increase of the embargo time is possible when necessary.
171
172Current Security Team members
173-----------------------------
174
175For secure communications, please send your messages encrypted using the GPG
176keys. Remember, message headers are not encrypted so do not include sensitive
177information in the subject line.
178
179 - Ross Burton: <ross@burtonini.com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__
180
181 - Michael Halstead: <mhalstead [at] linuxfoundation [dot] org>
182 `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__
183 or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__
184
185 - Richard Purdie: <richard.purdie@linuxfoundation.org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__
186
187 - Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__
188
189 - Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__