doc: add tested Intel platforms with Intel NICs
[dpdk.git] / doc / guides / contributing / vulnerability.rst
1 ..  SPDX-License-Identifier: BSD-3-Clause
2     Copyright 2019 The DPDK contributors
3
4 DPDK Vulnerability Management Process
5 =====================================
6
7 Scope
8 -----
9
10 Only the main repositories (dpdk and dpdk-stable) of the core project
11 are in the scope of this security process (including experimental APIs).
12 If a stable branch is declared unmaintained (end of life),
13 no fix will be applied.
14
15 All vulnerabilities are bugs, but not every bug is a vulnerability.
16 Vulnerabilities compromise one or more of:
17
18 * Confidentiality (personal or corporate confidential data).
19 * Integrity (trustworthiness and correctness).
20 * Availability (uptime and service).
21
22 If in doubt, please consider the vulnerability as security sensitive.
23 At worst, the response will be to report the bug through the usual channels.
24
25
26 Finding
27 -------
28
29 There is no pro-active security engineering effort at the moment.
30
31 Please report any security issue you find in DPDK as described below.
32
33
34 Report
35 ------
36
37 Do not use Bugzilla (unsecured).
38 Instead, send GPG-encrypted emails
39 to `security@dpdk.org <https://core.dpdk.org/security#contact>`_.
40 Anyone can post to this list.
41 In order to reduce the disclosure of a vulnerability in the early stages,
42 membership of this list is intentionally limited to a `small number of people
43 <https://mails.dpdk.org/roster/security>`_.
44
45 It is additionally encouraged to GPG-sign one-on-one conversations
46 as part of the security process.
47
48 As it is with any bug, the more information provided,
49 the easier it will be to diagnose and fix.
50 If you already have a fix, please include it with your report,
51 as that can speed up the process considerably.
52
53 In the report, please note how you would like to be credited
54 for discovering the issue
55 and the details of any embargo you would like to impose.
56
57 If the vulnerability is not public yet,
58 no patch or information should be disclosed publicly.
59 If a fix is already published,
60 the reporting process must be followed anyway, as described below.
61
62
63 Confirmation
64 ------------
65
66 Upon reception of the report, a security team member should reply
67 to the reporter acknowledging that the report has been received.
68
69 The DPDK security team reviews the security vulnerability reported.
70 Area experts not members of the security team may be involved in the process.
71 In case the reported issue is not qualified as a security vulnerability,
72 the security team will request the submitter to report it
73 using the usual channel (Bugzilla).
74 If qualified, the security team will assess which DPDK version are affected.
75 A bugzilla ID (allocated in a `reserved pool
76 <https://bugs.dpdk.org/buglist.cgi?f1=bug_group&o1=equals&v1=security>`_)
77 is assigned to the vulnerability, and kept empty until public disclosure.
78
79 The security team calculates the severity score with
80 `CVSS calculator <https://www.first.org/cvss/calculator/3.0>`_
81 based on inputs from the reporter and its own assessment of the vulnerability,
82 and agrees on the score with the reporter.
83
84 An embargo may be put in place depending on the severity of the vulnerability.
85 If an embargo is decided, its duration should be suggested by the security team
86 and negotiated with the reporter.
87 Embargo duration between vulnerability confirmation and public disclosure
88 should be between **one and ten weeks**.
89 If an embargo is not required, the vulnerability may be fixed
90 using the standard patch process, once a CVE number has been assigned.
91
92 The confirmation mail should be sent within **3 business days**.
93
94 Following information must be included in the mail:
95
96 * Confirmation
97 * CVSS severity and score
98 * Embargo duration
99 * Reporter credit
100 * Bug ID (empty and restricted for future reference)
101
102 CVE Request
103 -----------
104
105 The security team develops a security advisory document.
106 The security team may, at its discretion,
107 include the reporter (via "CC") in developing the security advisory document,
108 but in any case should accept feedback
109 from the reporter before finalizing the document.
110 When the document is final, the security team needs to
111 request a CVE identifier from a CNA.
112
113 The CVE request should be sent
114 to `secalert@redhat.com <mailto:secalert@redhat.com>`_
115 using GPG encrypted email
116 (see `contact details <https://access.redhat.com/security/team/contact>`_).
117
118
119 CVE Request Template with Embargo
120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
121
122 ::
123
124   A vulnerability was discovered in the DPDK project.
125   In order to ensure full traceability, we need a CVE number assigned
126   that we can attach to private and public notifications.
127   Please treat the following information as confidential during the embargo
128   until further public disclosure.
129
130   [PRODUCT]:
131   [VERSION]:
132   [PROBLEMTYPE]:
133   [SEVERITY]:
134   [REFERENCES]: { bug_url }
135   [DESCRIPTION]:
136
137   Thanks
138   { DPDK_security_team_member }, on behalf of the DPDK security team
139
140
141 CVE Request Template without Embargo
142 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
143
144 ::
145
146   A vulnerability was discovered in the DPDK project.
147   In order to ensure full traceability, we need a CVE number assigned
148   that we can attach to private and public notifications.
149
150   [PRODUCT]:
151   [VERSION]:
152   [PROBLEMTYPE]:
153   [SEVERITY]:
154   [REFERENCES]: { bug_url }
155   [DESCRIPTION]:
156
157   Thanks
158   { DPDK_security_team_member }, on behalf of the DPDK security team
159
160
161 Fix Development and Review
162 --------------------------
163
164 If the fix is already published, this step is skipped,
165 and the pre-release disclosure is replaced with the private disclosure,
166 as described below. It must not be considered as the standard process.
167
168 This step may be started in parallel with CVE creation.
169 The patches fixing the vulnerability are developed and reviewed
170 by the security team and
171 by elected area experts that agree to maintain confidentiality.
172
173 The CVE id and the bug id must be referenced in the patch.
174
175 Backports to the identified affected versions are done once the fix is ready.
176
177
178 Pre-Release Disclosure
179 ----------------------
180
181 When the fix is ready, the security advisory and patches are sent
182 to downstream stakeholders
183 (`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
184 specifying the date and time of the end of the embargo.
185 The communicated public disclosure date should be **less than one week**
186
187 Downstream stakeholders are expected not to deploy or disclose patches
188 until the embargo is passed, otherwise they will be removed from the list.
189
190 Downstream stakeholders (in `security-prerelease list
191 <https://mails.dpdk.org/roster/security-prerelease>`_), are:
192
193 * Operating system vendors known to package DPDK
194 * Major DPDK users, considered trustworthy by the technical board, who
195   have made the request to `techboard@dpdk.org <mailto:techboard@dpdk.org>`_
196
197 The `OSS security private mailing list mailto:distros@vs.openwall.org>` will
198 also be contacted one week before the end of the embargo, as indicated by `the
199 OSS-security process <https://oss-security.openwall.org/wiki/mailing-lists/distros>`
200 and using the PGP key listed on the same page, describing the details of the
201 vulnerability and sharing the patch[es]. Distributions and major vendors follow
202 this private mailing list, and it functions as a single point of contact for
203 embargoed advance notices for open source projects.
204
205 The security advisory will be based on below template,
206 and will be sent signed with a security team's member GPG key.
207
208
209 Pre-Release Mail Template
210 ~~~~~~~~~~~~~~~~~~~~~~~~~
211
212 ::
213
214   This is an advance warning of a vulnerability discovered in DPDK,
215   to give you, as downstream stakeholders, a chance to coordinate
216   the release of fixes and reduce the vulnerability window.
217   Please treat the following information as confidential until
218   the proposed public disclosure date.
219
220   { impact_description }
221
222   Proposed patches are attached.
223   Unless a flaw is discovered in them, these patches will be merged
224   to { branches } on the public disclosure date.
225
226   CVE: { cve_id }
227   Severity: { severity }
228   CVSS scores: { cvss_scores }
229
230   Proposed public disclosure date/time: { disclosure_date } at 15:00 UTC.
231   Please do not make the issue public (or release public patches)
232   before this coordinated embargo date.
233
234 If the issue is leaked during the embargo, the same procedure is followed
235 with only a few days delay between the pre-release and the public disclosure.
236
237
238 Private Disclosure
239 ------------------
240
241 If a vulnerability is unintentionally already fixed in the public repository,
242 a security advisory is sent to downstream stakeholders
243 (`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
244 giving few days to prepare for updating before the public disclosure.
245
246
247 Private Disclosure Mail Template
248 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
249
250 ::
251
252   This is a warning of a vulnerability discovered in DPDK,
253   to give you, as downstream stakeholders, a chance to coordinate
254   the deployment of fixes before a CVE is public.
255
256   Please treat the following information as confidential until
257   the proposed public disclosure date.
258
259   { impact_description }
260
261   Commits: { commit_ids with branch number }
262
263   CVE: { cve_id }
264   Severity: { severity }
265   CVSS scores: { cvss_scores }
266
267   Proposed public disclosure date/time: { disclosure_date }.
268   Please do not make the vulnerability information public
269   before this coordinated embargo date.
270
271
272 Public Disclosure
273 -----------------
274
275 On embargo expiration, following tasks will be done simultaneously:
276
277 * The assigned bug is filled by a member of the security team,
278   with all relevant information, and it is made public.
279 * The patches are pushed to the appropriate branches.
280 * For long and short term stable branches fixed,
281   new versions should be released.
282
283 Releases on Monday to Wednesday are preferred, so that system administrators
284 do not have to deal with security updates over the weekend.
285
286 The security advisory is posted
287 to `announce@dpdk.org <mailto:announce@dpdk.org>`_ and to `the public OSS-security
288 mailing list <mailto:oss-security@lists.openwall.com>` as soon as the patches
289 are pushed to the appropriate branches.
290
291 Patches are then sent to `dev@dpdk.org <mailto:dev@dpdk.org>`_
292 and `stable@dpdk.org <mailto:stable@dpdk.org>`_ accordingly.
293
294
295 Release Mail Template
296 ~~~~~~~~~~~~~~~~~~~~~
297
298 ::
299
300   A vulnerability was fixed in DPDK.
301   Some downstream stakeholders were warned in advance
302   in order to coordinate the release of fixes
303   and reduce the vulnerability window.
304
305   { impact_description }
306
307   Commits: { commit_ids with branch number }
308
309   CVE: { cve_id }
310   Bugzilla: { bug_url }
311   Severity: { severity }
312   CVSS scores: { cvss_scores }
313
314
315 References
316 ----------
317
318 * `A minimal security response process
319   <https://access.redhat.com/blogs/766093/posts/1975833>`_
320 * `fd.io Vulnerability Management
321   <https://wiki.fd.io/view/TSC:Vulnerability_Management>`_
322 * `Open Daylight Vulnerability Management
323   <https://wiki.opendaylight.org/view/Security:Vulnerability_Management>`_
324 * `CVE Assignment Information Format
325   <https://cve.mitre.org/cve/list_rules_and_guidance/cve_assignment_information_format.html>`_