docs: Propose a security policy (#710)

Propose a security policy (largely
[borrowed](35c71e42cd/docs/SECURITY.md)
from go-tuf) that users should consult in order to report any security
vulnerability.

Note that privately reporting security vulnerabilities requires turning
on a GitHub
[setting](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository).

Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>

SECURITY.md

@@ -0,0 +1,22 @@
+# Security Policy
+
+The `slsa-verifier` community is committed to maintaining a secure-by-default verifier for SLSA.
+If you believe you have identified a security issue in this project, please follow these guidelines for responsible disclosure.
+
+## Supported Versions
+
+You may report issues for the most recent version of `slsa-verifier`. We _may_, at our discretion, retroactively make changes to older, particularly unsupported versions.
+
+## Reporting a Vulnerability
+
+If you discover a potential security issue in this project, we kindly ask that you [privately report it](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). At the minimum, the report must contain the following:
+
+* A description of the issue.
+* A specific version or commit SHA of `slsa-verifier` where the issue reproduces.
+* Instructions to reproduce the issue.
+
+Please do **not** create a public GitHub issue or pull request to submit vulnerability reports. These public trackers are intended for non-time-sensitive and non-security-related bug reports and feature requests. Major feature requests, such as design changes to the specification, should be proposed to the [community](https://slsa.dev/community).
+
+## Disclosure
+
+This project follows a 90 day disclosure timeline.