SECURITY.md: Add security file

Add a SECURITY.md file that outlines the process for handling
security-related vulnerabilities.

Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Reviewed-by: Kamalesh Babulal <kamalesh.babulal@oracle.com>
(cherry picked from commit 47543c98f9a4d3c8e971951da6f25609aa3a868f)

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644 (file)
index 0000000..54f91be
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,45 @@
+The libcgroup Security Vulnerability Handling Process
+===============================================================================
+https://github.com/libcgroup/libcgroup
+
+This document describes the processes through which sensitive security relevant
+bugs can be responsibly disclosed to the libcgroup project and how the project
+maintainers should handle these reports.  Just like the other libcgroup process
+documents, this document should be treated as a guiding document and not a
+hard, unyielding set of regulations; the bug reporters and project maintainers
+are encouraged to work together to address the issues as best they can, in a
+manner which works best for all parties involved.
+
+### Reporting Problems
+
+Problems with the libcgroup library that are not suitable for immediate public
+disclosure should be emailed to the current libcgroup maintainers; see below.
+We typically request at most a 90 day time period to address the issue before
+it is made public, but we will make every effort to address the issue as
+quickly as possible and shorten the disclosure window.
+
+* Dhaval Giani, dhaval.giani@gmail.com
+* Tom Hromatka, tom.hromatka@oracle.com
+
+### Resolving Sensitive Security Issues
+
+Upon disclosure of a bug, the maintainers should work together to investigate
+the problem and decide on a solution.  In order to prevent an early disclosure
+of the problem, those working on the solution should do so privately and
+outside of the traditional libcgroup development practices.  One possible
+solution to this is to leverage the GitHub "Security" functionality to create a
+private development fork that can be shared among the maintainers, and
+optionally the reporter.  A placeholder GitHub issue may be created, but
+details should remain extremely limited until such time as the problem has been
+fixed and responsibly disclosed.  If a CVE, or other tag, has been assigned to
+the problem, the GitHub issue title should include the vulnerability tag once
+the problem has been disclosed.
+
+### Public Disclosure
+
+Whenever possible, responsible reporting and patching practices should be
+followed, including notification to the linux-distros and oss-security mailing
+lists.
+
+* https://oss-security.openwall.org/wiki/mailing-lists/distros
+* https://oss-security.openwall.org/wiki/mailing-lists/oss-security