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

Commit ae4151e4 authored by Joshua Gay's avatar Joshua Gay 💾
Browse files

Resolve "Security policy"

parent 0f2ccb4e
......@@ -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.
# 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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment