SECURITY: security process
diff --git a/docs/Makefile.am b/docs/Makefile.am
index 56f0926..688d8d0 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -1,7 +1,7 @@
# $Id: Makefile.am,v 1.37 2009/03/26 15:41:15 bagder Exp $
EXTRA_DIST = template.3 BINDINGS INSTALL_AUTOTOOLS INSTALL_CMAKE HACKING TODO \
- AUTHORS CMakeLists.txt HACKING.CRYPTO
+ AUTHORS CMakeLists.txt HACKING.CRYPTO SECURITY.md
dist_man_MANS = \
libssh2_agent_connect.3 \
diff --git a/docs/SECURITY.md b/docs/SECURITY.md
new file mode 100644
index 0000000..562686f
--- /dev/null
+++ b/docs/SECURITY.md
@@ -0,0 +1,100 @@
+libssh2 security
+================
+
+This document is intended to provide guidance on how security vulnerabilities
+should be handled in the libssh2 project.
+
+Publishing Information
+----------------------
+
+All known and public libssh2 vulnerabilities will be listed on [the libssh2 web
+site](https://libssh2.haxx.se/).
+
+Security vulnerabilities should not be entered in the project's public bug
+tracker unless the necessary configuration is in place to limit access to the
+issue to only the reporter and the project's security team.
+
+Vulnerability Handling
+----------------------
+
+The typical process for handling a new security vulnerability is as follows.
+
+No information should be made public about a vulnerability until it is
+formally announced at the end of this process. That means, for example that a
+bug tracker entry must NOT be created to track the issue since that will make
+the issue public and it should not be discussed on the project's public
+mailing list. Also messages associated with any commits should not make any
+reference to the security nature of the commit if done prior to the public
+announcement.
+
+- The person discovering the issue, the reporter, reports the vulnerability
+ privately to `libssh2-security@haxx.se`. That's an email alias that reaches a
+ handful of selected and trusted people.
+
+- Messages that do not relate to the reporting or managing of an undisclosed
+ security vulnerability in libssh2 are ignored and no further action is
+ required.
+
+- A person in the security team sends an e-mail to the original reporter to
+ acknowledge the report.
+
+- The security team investigates the report and either rejects it or accepts
+ it.
+
+- If the report is rejected, the team writes to the reporter to explain why.
+
+- If the report is accepted, the team writes to the reporter to let him/her
+ know it is accepted and that they are working on a fix.
+
+- The security team discusses the problem, works out a fix, considers the
+ impact of the problem and suggests a release schedule. This discussion
+ should involve the reporter as much as possible.
+
+- The release of the information should be "as soon as possible" and is most
+ often synced with an upcoming release that contains the fix. If the
+ reporter, or anyone else, thinks the next planned release is too far away
+ then a separate earlier release for security reasons should be considered.
+
+- Write a security advisory draft about the problem that explains what the
+ problem is, its impact, which versions it affects, solutions or
+ workarounds, when the release is out and make sure to credit all
+ contributors properly.
+
+- Request a CVE number from
+ [distros@openwall](http://oss-security.openwall.org/wiki/mailing-lists/distros)
+ when also informing and preparing them for the upcoming public security
+ vulnerability announcement - attach the advisory draft for information. Note
+ that 'distros' won't accept an embargo longer than 19 days.
+
+- Update the "security advisory" with the CVE number.
+
+- The security team commits the fix in a private branch. The commit message
+ should ideally contain the CVE number. This fix is usually also distributed
+ to the 'distros' mailing list to allow them to use the fix prior to the
+ public announcement.
+
+- At the day of the next release, the private branch is merged into the master
+ branch and pushed. Once pushed, the information is accessible to the public
+ and the actual release should follow suit immediately afterwards.
+
+- The project team creates a release that includes the fix.
+
+- The project team announces the release and the vulnerability to the world in
+ the same manner we always announce releases. It gets sent to the libssh2
+ mailing list and the oss-security mailing list.
+
+- The security web page on the web site should get the new vulnerability
+ mentioned.
+
+LIBSSH2-SECURITY (at haxx dot se)
+--------------------------------
+
+Who is on this list? There are a couple of criteria you must meet, and then we
+might ask you to join the list or you can ask to join it. It really isn't very
+formal. We basically only require that you have a long-term presence in the
+libssh2 project and you have shown an understanding for the project and its way
+of working. You must've been around for a good while and you should have no
+plans in vanishing in the near future.
+
+We do not make the list of partipants public mostly because it tends to vary
+somewhat over time and a list somewhere will only risk getting outdated.
