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. 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 <http://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<http://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. 174 175Backports to the identified affected versions are done once the fix is ready. 176 177 178Pre-Release Disclosure 179---------------------- 180 181When the fix is ready, the security advisory and patches are sent 182to downstream stakeholders 183(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_), 184specifying the date and time of the end of the embargo. 185The public disclosure should happen in **less than one week**. 186 187Downstream stakeholders are expected not to deploy or disclose patches 188until the embargo is passed, otherwise they will be removed from the list. 189 190Downstream 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 197The security advisory will be based on below template, 198and will be sent signed with a security team's member GPG key. 199 200 201Pre-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 226If the issue is leaked during the embargo, the same procedure is followed 227with only a few days delay between the pre-release and the public disclosure. 228 229 230Private Disclosure 231------------------ 232 233If a vulnerability is unintentionally already fixed in the public repository, 234a security advisory is sent to downstream stakeholders 235(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_), 236giving few days to prepare for updating before the public disclosure. 237 238 239Private 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 264Public Disclosure 265----------------- 266 267On 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 275Releases on Monday to Wednesday are preferred, so that system administrators 276do not have to deal with security updates over the weekend. 277 278The security advisory is posted 279to `announce@dpdk.org <mailto:announce@dpdk.org>`_ 280as soon as the patches are pushed to the appropriate branches. 281 282Patches are then sent to `dev@dpdk.org <mailto:dev@dpdk.org>`_ 283and `stable@dpdk.org <mailto:stable@dpdk.org>`_ accordingly. 284 285 286Release 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 306References 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>`_ 317