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.
  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 <http://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 <http://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 public disclosure should happen in **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 <http://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 security advisory will be based on below template,
 198 and will be sent signed with a security team's member GPG key.
 199
 200
 201 Pre-Release Mail Template
 202 ~~~~~~~~~~~~~~~~~~~~~~~~~
 203
 204 ::
 205
 206   This is an advance warning of a vulnerability discovered in DPDK,
 207   to give you, as downstream stakeholders, a chance to coordinate
 208   the release of fixes and reduce the vulnerability window.
 209   Please treat the following information as confidential until
 210   the proposed public disclosure date.
 211
 212   { impact_description }
 213
 214   Proposed patches are attached.
 215   Unless a flaw is discovered in them, these patches will be merged
 216   to { branches } on the public disclosure date.
 217
 218   CVE: { cve_id }
 219   Severity: { severity }
 220   CVSS scores: { cvss_scores }
 221
 222   Proposed public disclosure date/time: { disclosure_date } at 15:00 UTC.
 223   Please do not make the issue public (or release public patches)
 224   before this coordinated embargo date.
 225
 226 If the issue is leaked during the embargo, the same procedure is followed
 227 with only a few days delay between the pre-release and the public disclosure.
 228
 229
 230 Private Disclosure
 231 ------------------
 232
 233 If a vulnerability is unintentionally already fixed in the public repository,
 234 a security advisory is sent to downstream stakeholders
 235 (`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
 236 giving few days to prepare for updating before the public disclosure.
 237
 238
 239 Private Disclosure Mail Template
 240 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 241
 242 ::
 243
 244   This is a warning of a vulnerability discovered in DPDK,
 245   to give you, as downstream stakeholders, a chance to coordinate
 246   the deployment of fixes before a CVE is public.
 247
 248   Please treat the following information as confidential until
 249   the proposed public disclosure date.
 250
 251   { impact_description }
 252
 253   Commits: { commit_ids with branch number }
 254
 255   CVE: { cve_id }
 256   Severity: { severity }
 257   CVSS scores: { cvss_scores }
 258
 259   Proposed public disclosure date/time: { disclosure_date }.
 260   Please do not make the vulnerability information public
 261   before this coordinated embargo date.
 262
 263
 264 Public Disclosure
 265 -----------------
 266
 267 On embargo expiration, following tasks will be done simultaneously:
 268
 269 * The assigned bug is filled by a member of the security team,
 270   with all relevant information, and it is made public.
 271 * The patches are pushed to the appropriate branches.
 272 * For long and short term stable branches fixed,
 273   new versions should be released.
 274
 275 Releases on Monday to Wednesday are preferred, so that system administrators
 276 do not have to deal with security updates over the weekend.
 277
 278 The security advisory is posted
 279 to `announce@dpdk.org <mailto:announce@dpdk.org>`_
 280 as soon as the patches are pushed to the appropriate branches.
 281
 282 Patches are then sent to `dev@dpdk.org <mailto:dev@dpdk.org>`_
 283 and `stable@dpdk.org <mailto:stable@dpdk.org>`_ accordingly.
 284
 285
 286 Release Mail Template
 287 ~~~~~~~~~~~~~~~~~~~~~
 288
 289 ::
 290
 291   A vulnerability was fixed in DPDK.
 292   Some downstream stakeholders were warned in advance
 293   in order to coordinate the release of fixes
 294   and reduce the vulnerability window.
 295
 296   { impact_description }
 297
 298   Commits: { commit_ids with branch number }
 299
 300   CVE: { cve_id }
 301   Bugzilla: { bug_url }
 302   Severity: { severity }
 303   CVSS scores: { cvss_scores }
 304
 305
 306 References
 307 ----------
 308
 309 * `A minimal security response process
 310   <https://access.redhat.com/blogs/766093/posts/1975833>`_
 311 * `fd.io Vulnerability Management
 312   <https://wiki.fd.io/view/TSC:Vulnerability_Management>`_
 313 * `Open Daylight Vulnerability Management
 314   <https://wiki.opendaylight.org/view/Security:Vulnerability_Management>`_
 315 * `CVE Assignment Information Format
 316   <https://cve.mitre.org/cve/list_rules_and_guidance/cve_assignment_information_format.html>`_