Add a security policy (community standards)

[paulo-ferraz-oliveira]

Copied, as-is, from https://github.com/erlef/setup-beam/blob/main/SECURITY.md.

Closes #17

[starbelly]

I need to run this by some of the board members within EEF, there might be some very specific legalese we need to put in here, given that the EEF is a formal legal entity (i.e., a company). A non-profit yes, but we need to be sure we are covered in the case that security vulnerability is discovered in an upstream dependency (e.g., openssl) and is attached to this org, so to speak.

[paulo-ferraz-oliveira]

Please do; if changes are required we might need to revisit setup-beam.

[maennchen]

We should probably try to keep the security policies of EEF projects aligned. (Including oidcc, setup-beam etc.)

In oidcc, we're using this: https://github.com/erlef/oidcc/blob/main/.github/SECURITY.md

Main differences:

• We follow the OpenSSF Vulnerability Disclosure Guide
  • Provides a clear framework how finders can expect to have their reports handled
• We allow to send vulnerabilities via GitHub private vulnerability reporting
  • Gives tools to deal with disclosures, requesting CVEs, handling private Patch PRs etc.

I however like the more detailed description of what should be reported exactly. So IMO a combination of the policies would probably be best.

Some additional guidance from OpenSSF Scorecard: https://github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy

[paulo-ferraz-oliveira]

@maennchen, I like it. When you get to update oidcc with what you think is best ping me here and I'll look at it/sync with it. Thanks.

[maennchen]

@paulo-ferraz-oliveira What do you think about this?

# Security Policy

[![OpenSSF Vulnerability Disclosure](https://img.shields.io/badge/OpenSSF-Vulnerability_Disclosure-green)][openssf-cvd-finders-guide]
[![GitHub Report](https://img.shields.io/badge/GitHub-Security_Advisories-blue)][github-advisory-new]
[![Email Report](https://img.shields.io/badge/Email-security%40erlef.org-blue)][email]

We take the security of this software seriously and are committed to ensuring
that any vulnerabilities are addressed promptly and effectively.

This repository follows the OpenSSF
[Vulnerability Disclosure guide][openssf-cvd-guide].
You can learn more about it in the [Finders Guide][openssf-cvd-finders-guide].

## Reporting Security Issues

If you believe you have found a security vulnerability in this repository,
please report it via [GitHub Security Vulnerability Reporting][github-advisory-new]
or via email to [`[email protected]`][email] if that is more suitable for you.

**Please do not report vulnerabilities through public channels** such as GitHub
issues, discussions, or pull requests, to avoid exposing the details of the
issue before it has been properly addressed.

We don't implement a bug bounty program or bounty rewards, but will work with
you to ensure that your findings get the appropriate handling.

When reporting a vulnerability, please include as much detail as possible to
help us triage and resolve the issue efficiently. Information that will be
specially helpful includes:

- The type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source file(s) related to the issue
- The location of the affected source code (e.g., tag, branch, commit, or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if available)
- The potential impact, including how the issue might be exploited by an attacker

Our vulnerability management team will respond within 3 working days of your
report. If the issue is confirmed as a vulnerability, we will open a Security
Advisory. This project follows a 90-day disclosure timeline.

If you have any questions about reporting security issues, please contact our
vulnerability management team at [`[email protected]`][email].

[openssf-cvd-guide]: https://github.com/ossf/oss-vulnerability-guide/tree/main
[openssf-cvd-finders-guide]: https://github.com/ossf/oss-vulnerability-guide/blob/main/finder-guide.md
[github-advisory-new]: https://github.com/erlef/oidcc/security/advisories/new
[email]: mailto:[email protected]

[wojtekmach]

• The type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
• Full paths of source file(s) related to the issue
• The location of the affected source code (e.g., tag, branch, commit, or direct URL)

Are any of these relevant to this project? I believe most if not all security vulnerabilities would happen elsewhere, in OTP, OpenSSL, wxWidgets, etc, so disclosing them here doesn't seem productive. I suppose I could see this project misconfiguring the builds and a fix would be updating build scripts. Or am I thinking about this all wrong?

[maennchen]

@wojtekmach Good point. We should probably switch out the examples of The type of issue depending on the context.

For oidcc, I would go with The type of issue (e.g., spec violation, incomplete token validation, etc.) or something like that.

For this repo it could be more something along the lines of using a malicious action or leaking secrets somewhere.

However the paths as well as the location still apply to this repository IMO. Doesn't really matter if it is Elixir Code or a vulnerable CI .yml.