## TODO

* Create <opensource-security@ieee.org>
* Determine how we will obtain CVE numbers

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 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.

2. The Open Source Community Manager will contact the *security
   contact* listed by the Official IEEE Open Source Project and ensure
   that the security vulnerability is reviewed to determine if it is
   accepted or rejected. You may choose to list the maintainer that is
   the appropraite security contact on your project (such as in your
   SECURITY.md page) or you may provide the contact (or list of
   contacts) to the Open Source Community Manager to maintain
   privately.

3. The Open Source Community Manager will notify the reporter if their
   report has been accepted or rejected

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).

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.