Add new security-policy documentation.

This formally describes our policies on reporting, notification and
disclosure of security issues, and provides a detailed explanation of
our full security-response process, for reference purposes.

1 files changed, 9 insertions, 35 deletions

diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index 76a2bd2374..30c7a5bb72 100644
--- a/docs/internals/contributing/bugs-and-features.txt
+++ b/docs/internals/contributing/bugs-and-features.txt
@@ -2,7 +2,15 @@
 Reporting bugs and requesting features
 ======================================
 
-Before reporting a bug or requesting a new feature, please consider these
+.. Important::
+
+    Please report security issues **only** to security@djangoproject.com.
+    This is a private list only open to long-time, highly trusted Django
+    developers, and its archives are not public.
+
+For further details, please see :doc:`our security policies </internals/security>`.
+
+Otherwise, before reporting a bug or requesting a new feature, please consider these
 general points:
 
 * Check that someone hasn't already filed the bug or feature request by
@@ -55,40 +63,6 @@ To understand the lifecycle of your ticket once you have created it, refer to
 
 .. _reporting-security-issues:
 
-Reporting security issues
--------------------------
-
-.. Important::
-
-    Please report security issues **only** to security@djangoproject.com.
-    This is a private list only open to long-time, highly trusted Django
-    developers, and its archives are not publicly readable.
-
-In the event of a confirmed vulnerability in Django itself, we will take the
-following actions:
-
-* Acknowledge to the reporter that we've received the report and that a
-  fix is forthcoming. We'll give a rough timeline and ask the reporter
-  to keep the issue confidential until we announce it.
-
-* Focus on developing a fix as quickly as possible and produce patches
-  against the current and two previous releases.
-
-* Determine a go-public date for announcing the vulnerability and the fix.
-  To try to mitigate a possible "arms race" between those applying the
-  patch and those trying to exploit the hole, we will not announce
-  security problems immediately.
-
-* Pre-notify third-party distributors of Django ("vendors"). We will send
-  these vendor notifications through private email which will include
-  documentation of the vulnerability, links to the relevant patch(es), and
-  a request to keep the vulnerability confidential until the official
-  go-public date.
-
-* Publicly announce the vulnerability and the fix on the pre-determined
-  go-public date. This will probably mean a new release of Django, but
-  in some cases it may simply be patches against current releases.
-
 Reporting user interface bugs and features
 ------------------------------------------