|
1 |
| -# Security |
| 1 | +If you believe that you have discovered a security or privacy vulnerability in our open source software, please report it to us using the GitHub private vulnerability feature. Reports should include specific product and software version(s) that you believe are affected; a technical description of the behavior that you observed and the behavior that you expected; the steps required to reproduce the issue; and a proof of concept or exploit. |
2 | 2 |
|
3 |
| -This document specifies the security process for the Swift NIO Oblivious HTTP project. |
| 3 | +The project team will do their best to acknowledge receiving all security reports within 7 days of submission. This initial acknowledgment is neither acceptance nor rejection of your report. The project team may come back to you with further questions or invite you to collaborate while working through the details of your report. |
4 | 4 |
|
5 |
| -## Disclosures |
| 5 | +Keep these additional guidelines in mind when submitting your report: |
6 | 6 |
|
7 |
| -### Private Disclosure Process |
| 7 | +* Reports concerning known, publicly disclosed CVEs can be submitted as normal issues to this project. |
| 8 | +* Output from automated security scans or fuzzers MUST include additional context demonstrating the vulnerability with a proof of concept or working exploit. |
| 9 | +* Application crashes due to malformed inputs are typically not treated as security vulnerabilities, unless they are shown to also impact other processes on the system. |
8 | 10 |
|
9 |
| -The Swift NIO core team asks that known and suspected vulnerabilities be |
10 |
| -privately and responsibly disclosed by emailing |
11 |
| - |
12 |
| -with all the required detail. |
13 |
| -**Do not file a public issue.** |
14 | 11 |
|
15 |
| -#### When to report a vulnerability |
16 |
| - |
17 |
| -* You think you have discovered a potential security vulnerability in Swift NIO Oblivious HTTP. |
18 |
| -* You are unsure how a vulnerability affects Swift NIO Oblivious HTTP. |
19 |
| - |
20 |
| -#### What happens next? |
21 |
| - |
22 |
| -* A member of the team will acknowledge receipt of the report within 3 |
23 |
| - working days (United States). This may include a request for additional |
24 |
| - information about reproducing the vulnerability. |
25 |
| -* We will privately inform the Swift Server Work Group ([SSWG][sswg]) of the |
26 |
| - vulnerability within 10 days of the report as per their [security |
27 |
| - guidelines][sswg-security]. |
28 |
| -* Once we have identified a fix we may ask you to validate it. We aim to do this |
29 |
| - within 30 days. In some cases this may not be possible, for example when the |
30 |
| - vulnerability exists at the protocol level and the industry must coordinate on |
31 |
| - the disclosure process. |
32 |
| -* If a CVE number is required, one will be requested from [MITRE][mitre] |
33 |
| - providing you with full credit for the discovery. |
34 |
| -* We will decide on a planned release date and let you know when it is. |
35 |
| -* Prior to release, we will inform major dependents that a security-related |
36 |
| - patch is impending. |
37 |
| -* Once the fix has been released we will publish a security advisory on GitHub |
38 |
| - and the [SSWG][sswg] will announce the vulnerability on the [Swift |
39 |
| - forums][swift-forums-sec]. |
40 |
| - |
41 |
| -[sswg]: https://github.com/swift-server/sswg |
42 |
| -[sswg-security]: https://www.swift.org/sswg/security/ |
43 |
| -[swift-forums-sec]: https://forums.swift.org/c/server/security-updates/ |
44 |
| -[mitre]: https://cveform.mitre.org/ |
| 12 | +While we welcome reports for open source software projects, they are not eligible for Apple Security Bounties. |
0 commit comments