Wrote initial security policy.

Related to: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#vulnerability_report_process
Related to: debops/debops#154

When this repo is included in the docs build, a redirect from
`debops.org/security` should point to the security policy.

Additionally I propose to create "DebOps security mailing list
<[email protected]>" or "<[email protected]>"

CHANGES.rst

@@ -26,3 +26,5 @@ Added
 - Added a draft of the organizational structure and explanation of distributed
   development model, as well a draft of the code signing policy used by the
   project. [drybjed, ypid]
+
+- Wrote initial security policy. [ypid]

docs/index.rst

@@ -10,6 +10,7 @@ DebOps Policy and Guidelines
    organizational-structure
    distributed-development
    code-signing
+   security-policy
    references
    copyright
    changelog

docs/security-policy.rst

@@ -0,0 +1,91 @@
+Security policy
+===============
+
+.. Based on: https://www.openssl.org/docs/faq.html#BUILD19
+   Based on: http://rubyonrails.org/security/
+             A: Only legacy HTTP?
+   See also: https://security.stackexchange.com/q/34871
+
+   Big parts of the policy have been copied from http://rubyonrails.org/security/.
+   Thus, this file is licensed under MIT.
+
+   Copyright (c) 2016 http://rubyonrails.org
+   Copyright (C) 2016 Robin Schneider <[email protected]>
+   Copyright (C) 2016 DebOps Project http://debops.org/
+
+   Permission is hereby granted, free of charge, to any person obtaining a copy
+   of this software and associated documentation files (the "Software"), to
+   deal in the Software without restriction, including without limitation the
+   rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+   sell copies of the Software, and to permit persons to whom the Software is
+   furnished to do so, subject to the following conditions:
+
+   The above copyright notice and this permission notice shall be included in
+   all copies or substantial portions of the Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+   AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+   FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+   IN THE SOFTWARE.
+
+Reporting a vulnerability
+-------------------------
+
+If you think your bug has security implications then please send it to the
+Project Leader (Maciej Delmanowski <[email protected]>) and additionally to
+the maintainers of the affected part of the project.
+If you can fix the vulnerability (or have already done so) please consider
+attaching a patch.
+If you wish to use PGP to send
+in a report please use one or more of the keys of the team members listed at
+`debops-keyring <https://github.com/debops/debops-keyring>`_.
+
+Disclosure process
+------------------
+
+#. Security report received and is assigned a primary handler. This person will
+   coordinate the fix and release process. Problem is confirmed and a list of
+   all affected versions is determined. Code is audited to find any potential
+   similar problems.
+
+#. Fixes are prepared for all releases which are still supported. These fixes
+   are not committed to the public repository but rather held locally pending
+   the announcement.
+#. A suggested embargo date for this vulnerability is chosen and potential
+   downstream projects of DebOps are notified. This notification will include
+   patches for all versions still under support and a contact address for
+   packagers who need advice backporting patches to older versions.
+#. On the embargo date, the debops-security list is sent a copy of the
+   announcement. The changes are pushed to the public repository and affected
+   parts of the project are released. Additionally, an GitHub issue is opened
+   against the affected repository on GitHub with the intend to inform people
+   watching the repository.
+
+This process can take some time, especially when coordination is required with
+maintainers of other projects. Every effort will be made to handle the bug in
+as timely a manner as possible, however it’s important that we follow the
+release process above to ensure that the disclosure is handled in a consistent
+manner.
+
+Receiving disclosures
+---------------------
+
+The best way to receive all the security announcements is to subscribe to the
+`DebOps security mailing list
+<https://lists.debops.org/mailman/listinfo/debops-security>`_. The mailing list
+is very low traffic, and it receives the public notifications the moment the
+embargo is lifted. If you produce packages of DebOps and require prior
+notification of vulnerabilities, you should get in touch with the DebOps Project.
+
+No one outside the core team, the initial reporter or downstream projects will be
+notified prior to the lifting of the embargo. We regret that we cannot make
+exceptions to this policy for high traffic or important sites, as any
+disclosure beyond the minimum required to coordinate a fix could cause an early
+leak of the vulnerability.
+
+If you have any suggestions to improve this policy, please get in touch for
+example via
+the `debops-policy repository on GitHub <https://github.com/debops/debops-policy>`_.