doc: prepare security process for vulnerabilities

diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index f90df451e..e2608d3c4 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -13,5 +13,6 @@  Contributor's Guidelines
     versioning
     documentation
     patches
+    vulnerability
     stable
     cheatsheet
diff --git a/doc/guides/contributing/vulnerability.rst b/doc/guides/contributing/vulnerability.rst
new file mode 100644
index 000000000..d16fea9d2
--- /dev/null
+++ b/doc/guides/contributing/vulnerability.rst
@@ -0,0 +1,316 @@ 
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright 2019 The DPDK contributors
+
+DPDK Vulnerability Management Process
+=====================================
+
+Scope
+-----
+
+Only the main repositories (dpdk and dpdk-stable) of the core project
+are in the scope of this security process.
+If a stable branch is declared unmaintained (end of life),
+no fix will be applied.
+
+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, please 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.
+
+Please report any security issue you find in DPDK as described below.
+
+
+Report
+------
+
+Do not use Bugzilla (unsecured).
+Instead, send GPG-encrypted emails
+to `security@dpdk.org <http://core.dpdk.org/doc/security#contact>`_.
+Anyone can post to this list.
+In order to reduce the disclosure of a vulnerability in the early stages,
+membership of this list is intentionally limited to a `small number of people
+<http://mails.dpdk.org/roster/security>`_.
+
+It is additionally encouraged to GPG-sign one-on-one conversations
+as part of the security process.
+
+As it is with any bug, the more information provided,
+the easier it will be to diagnose and fix.
+If you already have a fix, please include it with your report,
+as that can speed up the process considerably.
+
+In the report, please note how you would like to be credited
+for discovering the issue
+and the details of any embargo you would like to impose.
+
+If the vulnerability is not public yet,
+no patch or information should be disclosed publicly.
+If a fix is already published,
+the reporting process must be followed anyway, as described below.
+
+
+Confirmation
+------------
+
+Upon reception of the report, a security team member should reply
+to the reporter acknowledging that the report has been received.
+
+The DPDK security team reviews the security vulnerability reported.
+Area experts not members of the security team may be involved in the process.
+In case the reported issue is not qualified as a security vulnerability,
+the security team will request the submitter to report it
+using the usual channel (Bugzilla).
+If qualified, the security team will assess which DPDK version are affected.
+A bugzilla ID (allocated in 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
+`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, its duration should be suggested by the security team
+and negotiated 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.
+
+The confirmation mail should be sent within **3 business days**.
+
+Following information must be included 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.
+
+The CVE request should be sent
+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, this step is skipped,
+and the pre-release disclosure is replaced with the private disclosure,
+as described below. It must not be considered as the standard process.
+
+This step may be started in parallel with CVE creation.
+The patches fixing the vulnerability are developed and reviewed
+by the security team and
+by elected area experts that agree to maintain confidentiality.
+
+The CVE id and the bug id must be referenced in the patch.
+
+Backports to the identified affected versions are done once the fix is ready.
+
+
+Pre-Release Disclosure
+----------------------
+
+When the fix is ready, the security advisory and patches are sent
+to downstream stakeholders
+(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
+specifying the date and time of the end of the embargo.
+The public disclosure should happen in **less than one week**.
+
+Downstream stakeholders are expected not to deploy or disclose patches
+until the embargo is passed, otherwise they will be removed from the list.
+
+Downstream stakeholders (in `security-prerelease list
+<http://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 security advisory will be based on below template,
+and will be sent signed with a security team's member 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, the same procedure is followed
+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,
+a security advisory is sent to downstream stakeholders
+(`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
+giving 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
+-----------------
+
+On embargo expiration, following tasks will be done simultaneously:
+
+* The assigned bug is filled by a member of the security team,
+  with all relevant information, and it is made public.
+* The patches are pushed to the appropriate branches.
+* For long and short term stable branches fixed,
+  new versions should be released.
+
+Releases on Monday to Wednesday are preferred, so that system administrators
+do not have to deal with security updates over the weekend.
+
+The security advisory is posted
+to `announce@dpdk.org <mailto:announce@dpdk.org>`_
+as soon as the patches are pushed to the appropriate branches.
+
+Patches are then sent 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>`_