Merge branch '4-security-policy' into 'master'

Resolve "Security policy"

Closes #4

See merge request oscom/maintain!5

SECURITY/README.md

@@ -3,17 +3,20 @@
 * Create <opensource-security@ieee.org>
 * Determine how we will obtain CVE numbers
 
-We encourage you to use or adapt our SECURITY.md template. The
-following outlines the general security process for all Official IEEE
-Open Source Projects.
+We encourage you to use the SECURITY.md template we have provided for you. 
+Below is our recommended security process which you may be required to 
+follow if your project has been deemed as needing a formal security 
+reporting process. 
 
 ## Security process
 
-All Official IEEE Open Source Projects should follow the following
-security reporting process. 
+All projects on the IEEE Open Source Platform that have been deemed as needing 
+a formal security reporting process are required to have a SECURITY.md file 
+in the root directory of their project's repository and to follow the following
+seucirty process (or an alternative security process approved by the 
+Open Source Committee and approved for use by your project).  
 
-1. Security vulnerabilities are reported to
-   <opensource-security@ieee.org>. Security reports are confidential.
+1. Security vulnerabilities are reported to <opensource-security@ieee.org>. Security reports are confidential.
 
 2. The Open Source Community Manager will contact the *security
    contact* listed by the Official IEEE Open Source Project and ensure
@@ -29,49 +32,45 @@ security reporting process.
 
 4. If a report is accepted the following protocol shall be followed: 
 
-  a. The Open Source Community Manager will determine if a CVE number
-     should be obtained, and if so, IEEE shall obtain a CVE number.
-
-  b. The project will patch the vulernability and stage a release and
-     draft a short announcement that includes the CVE number,
-     severity, and impact.
-
-  c. The Open Source Community Manager will review the release and
-     announcement and coordinate to schedule a date and time for
-     public releaes. At this time, your project may discuss with the
-     Open Source Community Manager any private disclosures you wish to
-     make in advance of the public disclosure, such as to the reporter
-     of the vulernability or to any identified stakeholders. The Open
-     Source Community Manager will only deny requests if there are any
-     suspicion that permitting such a request would violate IEEE
-     Policy or if the private disclosure would in effect be equivalent
-     of making a public disclosure.
-
-  d. The release shall be made as it normally would, but without
-     disclosing that it is patching a security vulnerability.
-
-  e. The release shall be timed so that a release announcement will be
-     sent out to immediately after the release. The announcement shall
-     go out to all relevant security announcement mailing lists as
-     well as any external security lists or portals the Open Source
-     Community Manager deems appropriate (e.g.,
-     oss-security@lists.openwall.com).
+    a. The Open Source Community Manager will determine if a CVE number should be obtained, and if so, IEEE shall obtain a CVE number.
+
+    b. The project will patch the vulernability and stage a release and draft a short announcement that includes the CVE number, severity, and impact.
+
+    c. The Open Source Community Manager will review the release and
+       announcement and coordinate to schedule a date and time for
+       public releaes. At this time, your project may discuss with the
+       Open Source Community Manager any private disclosures you wish to
+       make in advance of the public disclosure, such as to the reporter
+       of the vulernability or to any identified stakeholders. The Open
+       Source Community Manager will only deny requests if there are any
+       suspicion that permitting such a request would violate IEEE
+       Policy or if the private disclosure would in effect be equivalent
+       of making a public disclosure.
+
+    d. The release shall be made as it normally would, but without
+       disclosing that it is patching a security vulnerability.
+
+    e. The release shall be timed so that a release announcement will be
+       sent out to immediately after the release. The announcement shall
+       go out to all relevant security announcement mailing lists as
+       well as any external security lists or portals the Open Source
+       Community Manager deems appropriate (e.g.,
+       oss-security@lists.openwall.com).
 
 5. If a report is accepted and this project is also an IEEE Standard
    that incorporates an IEEE Open Source Project, then the additional
    standards protocol will be followed as well.
 
-  a. If the project is incorporated through an undated/unversioned
-     reference, then the above protocol suffices with the caveat that
-     there may be additional mailing list or forums where the
-     announcement will be posted.
-
-  b. If the project is incorporated through a versioned reference,
-     then it must be determined if it is an errata or corrigenda. If
-     it is an errata, the above protocol shall be followed with the
-     announcement timed to coincide with the errata. If a corrigenda
-     is required, then the above protocol shall be followed and the
-     corrigenda process shall be followed after the announcement is
-     made, and additional notices shall be placed on apporpriate
-     places warning users about the issue.
-
+    a. If the project is incorporated through an undated/unversioned
+       reference, then the above protocol suffices with the caveat that
+       there may be additional mailing list or forums where the
+       announcement will be posted.
+
+    b. If the project is incorporated through a versioned reference,
+       then it must be determined if it is an errata or corrigenda. If
+       it is an errata, the above protocol shall be followed with the
+       announcement timed to coincide with the errata. If a corrigenda
+       is required, then the above protocol shall be followed and the
+       corrigenda process shall be followed after the announcement is
+       made, and additional notices shall be placed on apporpriate
+       places warning users about the issue.

maintain.md

 # IEEE OPEN SOURCE MAINTAINERS MANUAL
 
+The following manual provides requirements and expectations for all users of the IEEE Open Source Platform. 
+
+All users of the IEEE Platform are granted the right to be maintainers of projects within their own username namespace, which include personal projects and personal forks of projects. As such, whether you are acting as a maintainer on a personal project or you have been granted the role of maintainer or contributor to an Official IEEE Open Source Project, you must follow the rules, requirements, and expectations outlined in this manual. 
+
+The Maintainers Manual open source project is organized into requirements, recommendations, and examples. Requirements are primarily outlined in the following document. Recommendations consist of templates you can used as a basis to help you meet the requirements. And examples relate to good ideas and practices that may or may not tie into any requirements or expectations. 
 
 ## Conduct
 
@@ -90,17 +95,15 @@ approval of Leader(s) of the project.
 
 ## Security and Critical vulnerabilities
 
-* The handling of disclosure of a vulnerability should be done following a responsible process
-* All projects should provide a way of having security vulnerabilities disclosures to be done privately, either thorugh an official private mailing list of the project or via private issues/bug reports. 
-* The Open Source Community Manager may require specific security and critical vulnerability and exposure procedures to be followed
-* In general, the time period for acknowledgin the validity of a critical vulnerability or exposure or similar notification: 15 days
-* Total time period required to resolve the issue: 90 days
+If a project's lead or maintainer, the Open Source Community Manager, or the Open Source Committee decide that a given project on the IEEE Open Source Platform needs to follow a seucity process for handling security reports and CVEs, then the requirements provided in [SECURITY/README.md](SECURITY/README.md) shall be followed and the creation of a SECURITY.md file shall be provided in the top-most level of your project's repository directory structure. A recommended [SECURITY.md](SECURITY/SECURITY.md) file has been provided for you. 
+
+If it is not determined that your project requires a formal security reporting process, then by default, a security bug can be treated as any other issue or bug filed against your project. 
 
 ## Communication
 
 ## Naming, Branding, Trademark, and Tradename 
 
-IEEE Policy on Trademark applies to IEEE Open Source Projects. 
+IEEE Policy on Trademark applies to IEEE Open Source Projects. Please direct all questions or concerns to the IEEE Open Source Community Manager. 
 
 ## Archiving