[mirror_libseccomp.git] / SECURITY.md

The libseccomp Security Vulnerability Handling Process
===============================================================================
https://github.com/seccomp/libseccomp

This document document attempts to describe the processes through which
sensitive security relevant bugs can be responsibly disclosed to the libseccomp
project and how the project maintainers should handle these reports.  Just like
the other libseccomp 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 libseccomp library that are not suitable for immediate public
disclosure should be emailed to the current libseccomp maintainers, the list is
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.

* Paul Moore, paul@paul-moore.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 libseccomp 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
Commit	Line	Data
4bec773f PM	1	The libseccomp Security Vulnerability Handling Process
	2	===============================================================================
	3	https://github.com/seccomp/libseccomp
	4
	5	This document document attempts to describe the processes through which
	6	sensitive security relevant bugs can be responsibly disclosed to the libseccomp
	7	project and how the project maintainers should handle these reports. Just like
	8	the other libseccomp process documents, this document should be treated as a
	9	guiding document and not a hard, unyielding set of regulations; the bug
	10	reporters and project maintainers are encouraged to work together to address
	11	the issues as best they can, in a manner which works best for all parties
	12	involved.
	13
	14	### Reporting Problems
	15
	16	Problems with the libseccomp library that are not suitable for immediate public
	17	disclosure should be emailed to the current libseccomp maintainers, the list is
	18	below. We typically request at most a 90 day time period to address the issue
	19	before it is made public, but we will make every effort to address the issue as
	20	quickly as possible and shorten the disclosure window.
	21
	22	* Paul Moore, paul@paul-moore.com
	23	* Tom Hromatka, tom.hromatka@oracle.com
	24
	25	### Resolving Sensitive Security Issues
	26
	27	Upon disclosure of a bug, the maintainers should work together to investigate
	28	the problem and decide on a solution. In order to prevent an early disclosure
	29	of the problem, those working on the solution should do so privately and
	30	outside of the traditional libseccomp development practices. One possible
	31	solution to this is to leverage the GitHub "Security" functionality to create a
	32	private development fork that can be shared among the maintainers, and
	33	optionally the reporter. A placeholder GitHub issue may be created, but
	34	details should remain extremely limited until such time as the problem has been
	35	fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to
	36	the problem, the GitHub issue title should include the vulnerability tag once
	37	the problem has been disclosed.
	38
	39	### Public Disclosure
	40
	41	Whenever possible, responsible reporting and patching practices should be
	42	followed, including notification to the linux-distros and oss-security mailing
	43	lists.
	44
	45	* https://oss-security.openwall.org/wiki/mailing-lists/distros