]>
Commit | Line | Data |
---|---|---|
9f95a23c TL |
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 | |
f67539c2 | 11 | are in the scope of this security process (including experimental APIs). |
9f95a23c TL |
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 | |
f67539c2 | 39 | to `security@dpdk.org <https://core.dpdk.org/security#contact>`_. |
9f95a23c TL |
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 | |
f67539c2 | 43 | <https://mails.dpdk.org/roster/security>`_. |
9f95a23c TL |
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. | |
f67539c2 | 185 | The communicated public disclosure date should be **less than one week** |
9f95a23c TL |
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 | |
f67539c2 | 191 | <https://mails.dpdk.org/roster/security-prerelease>`_), are: |
9f95a23c TL |
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 | ||
f67539c2 TL |
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 | ||
9f95a23c TL |
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 | |
f67539c2 TL |
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. | |
9f95a23c TL |
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>`_ |