[Docs] Add a SECURITY.md file documenting the security process. (#8)

[Docs] Add a SECURITY.md file documenting the security process.

### Motivation

In order to allow developers to report suspected security issues confidentially, we need a documented process for reporting issues affecting security.

### Modifications

Added a SECURITY.md inspired by the SwiftNIO one.

### Result

Developers can now follow the process when a suspected security issue is found.

### Test Plan

N/A


Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#8

Author: czechboy0

SECURITY.md

@@ -0,0 +1,43 @@
+# Security
+
+This document specifies the security process for the SwiftOpenAPIGenerator project.
+
+## Disclosures
+
+### Private Disclosure Process
+
+The SwiftOpenAPIGenerator team asks that known and suspected vulnerabilities be privately
+and responsibly disclosed by emailing [[email protected]](mailto:[email protected])
+with the details usually included with bug reports.
+**Do not file a public issue.**
+
+#### When to report a vulnerability
+
+* You think you have discovered a potential security vulnerability in SwiftOpenAPIGenerator or any of the SwiftOpenAPIGenerator projects.
+* You are unsure how a vulnerability affects SwiftOpenAPIGenerator or any of the SwiftOpenAPIGenerator projects.
+
+#### What happens next?
+
+* A member of the team will acknowledge receipt of the report within 3
+  working days (United States). This may include a request for additional
+  information about reproducing the vulnerability.
+* We will privately inform the Swift Server Work Group ([SSWG][sswg]) of the
+  vulnerability within 10 days of the report as per their [security
+  guidelines][sswg-security].
+* Once we have identified a fix we may ask you to validate it. We aim to do this
+  within 30 days. In some cases this may not be possible, for example when the
+  vulnerability exists at the protocol level and the industry must coordinate on
+  the disclosure process.
+* If a CVE number is required, one will be requested from [MITRE][mitre]
+  providing you with full credit for the discovery.
+* We will decide on a planned release date and let you know when it is.
+* Prior to release, we will inform major dependents that a security-related
+  patch is impending.
+* Once the fix has been released we will publish a security advisory on GitHub
+  and the [SSWG][sswg] will announce the vulnerability on the [Swift
+  forums][swift-forums-sec].
+
+[sswg]: https://github.com/swift-server/sswg
+[sswg-security]: https://github.com/swift-server/sswg/blob/main/process/incubation.md#security-best-practices
+[swift-forums-sec]: https://forums.swift.org/c/server/security-updates/
+[mitre]: https://cveform.mitre.org/

scripts/check-license-headers.sh

@@ -50,6 +50,7 @@ read -ra PATHS_TO_CHECK_FOR_LICENSE <<< "$( \
   ":(exclude)NOTICE.txt" \
   ":(exclude)Package.swift" \
   ":(exclude)README.md" \
+  ":(exclude)SECURITY.md" \
   ":(exclude)scripts/unacceptable-language.txt" \
   ":(exclude)docker/*" \
   ":(exclude)**/*.docc/*" \