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