..  SPDX-License-Identifier: BSD-3-Clause
    Copyright 2019 The DPDK contributors

DPDK Vulnerability Management Process
=====================================

Scope
-----

This security process covers only the main repositories (dpdk and dpdk-stable)
of the core project (including experimental APIs).
The team will not apply fixes to stable branches declared unmaintained (end of life).

All vulnerabilities are bugs, but not every bug is a vulnerability.
Vulnerabilities compromise one or more of:

* Confidentiality (personal or corporate confidential data).
* Integrity (trustworthiness and correctness).
* Availability (uptime and service).

If in doubt, consider the vulnerability as security sensitive.
At worst, the response will be to report the bug through the usual channels.


Finding
-------

There is no pro-active security engineering effort at the moment.

Report any security issue you find in DPDK as described below.


Reporting
---------

Do not use Bugzilla to report security vulnerabilities,
as it is not secured for such communication.
Instead, send a GPG-encrypted email
to `security@dpdk.org <https://core.dpdk.org/security#contact>`_.
This address is open to all,
but access to its inbox is intentionally limited to a small group
to minimize the risk of early disclosure.

GPG-sign any one-on-one correspondence related to the vulnerability report
as part of maintaining a secure communication process.

As with any bug report, detailed information greatly aids
in diagnosing and resolving the issue.
If you have already developed a fix,
include it in your submission to help accelerate resolution.

In your report, specify how you would like to be credited for the discovery
and mention any embargo period you wish to impose.

If the vulnerability has not yet been made public,
do not disclose patches or related information publicly.
Even if a fix has already been published,
you must still follow the proper reporting process outlined here.


Confirmation
------------

Upon receiving the report, a security team member should reply to the reporter
acknowledging receipt.

The DPDK security team reviews the security vulnerability reported.
Area experts who are not members of the security team may be involved in the process.
If the reported issue does not qualify as a security vulnerability,
the security team will request the submitter to report it
using the usual channel (Bugzilla).
If qualified, the security team assesses which DPDK versions are affected.
A bugzilla ID (allocated from a `reserved pool
<https://bugs.dpdk.org/buglist.cgi?f1=bug_group&o1=equals&v1=security>`_)
is assigned to the vulnerability, and kept empty until public disclosure.

The security team calculates the severity score with the
`CVSS calculator <https://www.first.org/cvss/calculator/3.0>`_
based on inputs from the reporter and its own assessment of the vulnerability,
and agrees on the score with the reporter.

An embargo may be put in place depending on the severity of the vulnerability.
If an embargo is decided, the security team should suggest the duration
and negotiate with the reporter.
Embargo duration between vulnerability confirmation and public disclosure
should be between **one and ten weeks**.
If an embargo is not required, the vulnerability may be fixed
using the standard patch process, once a CVE number has been assigned.

Send the confirmation mail within **3 business days**.

Include the following information in the mail:

* Confirmation
* CVSS severity and score
* Embargo duration
* Reporter credit
* Bug ID (empty and restricted for future reference)

CVE Request
-----------

The security team develops a security advisory document.
The security team may, at its discretion,
include the reporter (via "CC") in developing the security advisory document,
but in any case should accept feedback
from the reporter before finalizing the document.
When the document is final, the security team needs to
request a CVE identifier from a CNA.

Send the CVE request
to `secalert@redhat.com <mailto:secalert@redhat.com>`_
using GPG encrypted email
(see `contact details <https://access.redhat.com/security/team/contact>`_).


CVE Request Template with Embargo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

::

  A vulnerability was discovered in the DPDK project.
  In order to ensure full traceability, we need a CVE number assigned
  that we can attach to private and public notifications.
  Please treat the following information as confidential during the embargo
  until further public disclosure.

  [PRODUCT]:
  [VERSION]:
  [PROBLEMTYPE]:
  [SEVERITY]:
  [REFERENCES]: { bug_url }
  [DESCRIPTION]:

  Thanks
  { DPDK_security_team_member }, on behalf of the DPDK security team


CVE Request Template without Embargo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

::

  A vulnerability was discovered in the DPDK project.
  In order to ensure full traceability, we need a CVE number assigned
  that we can attach to private and public notifications.

  [PRODUCT]:
  [VERSION]:
  [PROBLEMTYPE]:
  [SEVERITY]:
  [REFERENCES]: { bug_url }
  [DESCRIPTION]:

  Thanks
  { DPDK_security_team_member }, on behalf of the DPDK security team


Fix Development and Review
--------------------------

If the fix is already published, skip this step,
and replace the pre-release disclosure with the private disclosure,
as described below.
This should not be considered the standard process.

This step may start in parallel with CVE creation.
The security team and elected area experts who agree to maintain confidentiality
develop and review patches fixing the vulnerability.

Reference the CVE id and the bug id in the patch if there is no embargo,
or if the embargo will be lifted when the release including the patch is published.
If the embargo will be lifted after the release,
omit the CVE and bug ids from the commit message.

Backports to the identified affected versions are done once the fix is ready.


Pre-Release Disclosure
----------------------

When the fix is ready, send the security advisory and patches
to downstream stakeholders
(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
specifying the date and time of the end of the embargo.
The communicated public disclosure date should be **less than one week**.

Downstream stakeholders are expected not to deploy or disclose patches
until the embargo passes; otherwise they will be removed from the list.

Downstream stakeholders (in `security-prerelease list
<https://mails.dpdk.org/roster/security-prerelease>`_) are:

* Operating system vendors known to package DPDK
* Major DPDK users, considered trustworthy by the technical board, who
  have made the request to `techboard@dpdk.org <mailto:techboard@dpdk.org>`_

The `OSS security private mailing list <mailto:distros@vs.openwall.org>`_ will
also be contacted one week before the end of the embargo, as indicated by `the
OSS-security process <https://oss-security.openwall.org/wiki/mailing-lists/distros>`_
and using the PGP key listed on the same page, describing the details of the
vulnerability and sharing the patch[es]. Distributions and major vendors follow
this private mailing list, and it functions as a single point of contact for
embargoed advance notices for open source projects.

The security advisory will be based on the template below,
and will be sent signed with a security team member's GPG key.


Pre-Release Mail Template
~~~~~~~~~~~~~~~~~~~~~~~~~

::

  This is an advance warning of a vulnerability discovered in DPDK,
  to give you, as downstream stakeholders, a chance to coordinate
  the release of fixes and reduce the vulnerability window.
  Please treat the following information as confidential until
  the proposed public disclosure date.

  { impact_description }

  Proposed patches are attached.
  Unless a flaw is discovered in them, these patches will be merged
  to { branches } on the public disclosure date.

  CVE: { cve_id }
  Severity: { severity }
  CVSS scores: { cvss_scores }

  Proposed public disclosure date/time: { disclosure_date } at 15:00 UTC.
  Please do not make the issue public (or release public patches)
  before this coordinated embargo date.

If the issue is leaked during the embargo, follow the same procedure
with only a few days delay between the pre-release and the public disclosure.


Private Disclosure
------------------

If a vulnerability is unintentionally already fixed in the public repository,
send a security advisory to downstream stakeholders
(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
giving a few days to prepare for updating before the public disclosure.


Private Disclosure Mail Template
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

::

  This is a warning of a vulnerability discovered in DPDK,
  to give you, as downstream stakeholders, a chance to coordinate
  the deployment of fixes before a CVE is public.

  Please treat the following information as confidential until
  the proposed public disclosure date.

  { impact_description }

  Commits: { commit_ids with branch number }

  CVE: { cve_id }
  Severity: { severity }
  CVSS scores: { cvss_scores }

  Proposed public disclosure date/time: { disclosure_date }.
  Please do not make the vulnerability information public
  before this coordinated embargo date.


Public Disclosure
-----------------

When the embargo expires, carry out the following actions simultaneously:

* A security team member files the assigned bug with all relevant details
  and makes it publicly accessible.

* Push the associated patches to the appropriate branches.

* Release updated versions for all affected stable branches, both short-term and long-term.

To ease adoption by system administrators,
preferably schedule security releases between Monday and Wednesday, avoiding weekends.

Post the security advisory
to `announce@dpdk.org <mailto:announce@dpdk.org>`_ and to `the public OSS-security
mailing list <mailto:oss-security@lists.openwall.com>`_ as soon as the patches
are pushed to the appropriate branches.

Send patches to `dev@dpdk.org <mailto:dev@dpdk.org>`_
and `stable@dpdk.org <mailto:stable@dpdk.org>`_ accordingly.


Release Mail Template
~~~~~~~~~~~~~~~~~~~~~

::

  A vulnerability was fixed in DPDK.
  Some downstream stakeholders were warned in advance
  in order to coordinate the release of fixes
  and reduce the vulnerability window.

  { impact_description }

  Commits: { commit_ids with branch number }

  CVE: { cve_id }
  Bugzilla: { bug_url }
  Severity: { severity }
  CVSS scores: { cvss_scores }


References
----------

* `A minimal security response process
  <https://access.redhat.com/blogs/766093/posts/1975833>`_
* `fd.io Vulnerability Management
  <https://wiki.fd.io/view/TSC:Vulnerability_Management>`_
* `Open Daylight Vulnerability Management
  <https://wiki.opendaylight.org/view/Security:Vulnerability_Management>`_
* `CVE Assignment Information Format
  <https://cve.mitre.org/cve/list_rules_and_guidance/cve_assignment_information_format.html>`_
