IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

README.md 3.85 KB
Newer Older
Joshua Gay's avatar
Joshua Gay committed
1
2
3
4
5
## TODO

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

Joshua Gay's avatar
Joshua Gay committed
6
7
8
9
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. 
Joshua Gay's avatar
Joshua Gay committed
10
11
12

## Security process

Joshua Gay's avatar
Joshua Gay committed
13
14
15
16
17
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).  
Joshua Gay's avatar
Joshua Gay committed
18

Joshua Gay's avatar
Joshua Gay committed
19
1. Security vulnerabilities are reported to <opensource-security@ieee.org>. Security reports are confidential.
Joshua Gay's avatar
Joshua Gay committed
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

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: 

Joshua Gay's avatar
Joshua Gay committed
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
    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).
Joshua Gay's avatar
Joshua Gay committed
59
60
61
62
63

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.

Joshua Gay's avatar
Joshua Gay committed
64
65
66
67
68
69
70
71
72
73
74
75
76
    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.