docs: Add security policy.

[ianlewis]

Fixes #541

Inspired by:

• https://kubernetes.io/docs/reference/issues-security/security/
• https://github.com/kubernetes/committee-security-response/blob/main/security-release-process.md

Some that aren't really new but are now formally written in the security policy:

• We don't use memory-unsafe languages.

Some new things:

• Vulnerability reporting process: Basically just reporting via GitHub security advisories.
• Vulnerability fix release process: Adds a list of supported versions. Opens the potential for needing to backport security fixes if we have multiple supported major or minor versions.
• Vulnerability disclosure process: Basically just disclosing via releases and GitHub Security Advisories.
• The "Security Team": (It's just the admins right now)

From OpenSSF best practices:

1. The project MUST publish the process for reporting vulnerabilities on the project site. {Met URL} [vulnerability_report_process] The Security Policy includes info on how to report vulnerabilities
2. Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. [vulnerabilities_critical_fixed] - Added a process for security vulnerability reporting, how we aim to fix rapidly, and added timelines where appropriate, but without setting specific deadlines for a release
3. The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. {N/A justification} [release_notes_vulns] - **Added info to the policy that notes that security releases will be marked clearly, and include info on the vulnerability and upgrade/mitigation.
4. If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. {N/A allowed} {Met URL} [vulnerability_report_private] - Security policy includes a private reporting process
5. The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. {N/A allowed} [vulnerability_report_response] - Security policy includes information that we will respond within 14 days to vulnerability reports
6. The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) [know_secure_design] - Security policy includes info on members of the "security team"
7. At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. [know_common_errors] - Security policy includes info on members of the "security team"
8. All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. {N/A allowed} [static_analysis_fixed] - Security policy includes info on use of code analysis tools
9. It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). {N/A allowed} [dynamic_analysis_unsafe] - Security policy includes info on (non)use of memory-unsafe languages.
10. It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. [dynamic_analysis_enable_assertions] - Security policy includes info and justification on use of static analysis tools

Signed-off-by: Ian Lewis [email protected]

[ianlewis]

Should probably take some inspiration from sigstore's policy: https://github.com/sigstore/.github/blob/main/SECURITY.md

However, it looks like they took inspiration from etcd which shares a lot with Kubernetes.

[ianlewis]

OpenSSF has some security policy templates but these are way too basic
https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/security_policies

However there is a much more detailed guide to gain inspiration from:
https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md

[laurentsimon]

Thank you!

[joshuagl]

This is great, thanks for working on it!