Add a security policy for the project

[apyrgio]

Add a SECURITY.md file for the project, where we document the communication channels for disclosing security vulnerabilities. Also, make sure to set the severity cutoff to "High" when performing scans, on a biweekly basis.

Closes #1278
Closes #1395

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[almet]

Thanks!

I added a few notes in there. The main thing is related to our point of contact, where I'm making the proposal to use a Signal Group as a first point of contact (where we don't have to discuss there, but can use the approbation flow as a way to get notified)

Here is, for instance, a text that's being generated by disclose.io. I find some interesting parts there, like the "Our commitments" and "Our expectations"

# Freedom of the Press Foundation Vulnerability Disclosure Policy

## Introduction

Freedom of the Press Foundation welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us.

## Systems in Scope

This policy applies to any digital assets owned, operated, or maintained by Freedom of the Press Foundation.

## Out of Scope

- Assets or other equipment not owned by parties participating in this policy. 

Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority.

## Our Commitments

When working with us, according to this policy, you can expect us to:

- Respond to your report promptly, and work with you to understand and validate your report;
- Strive to keep you informed about the progress of a vulnerability as it is processed;
- Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and
- Extend Safe Harbor for your vulnerability research that is related to this policy.

## Our Expectations

In participating in our vulnerability disclosure program in good faith, we ask that you:

- Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail;
- Report any vulnerability you’ve discovered promptly;
- Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience;
- Use only the Official Channels to discuss vulnerability information with us;
- Provide us a reasonable amount of time (at least 60 days from the initial report) to resolve the issue before you disclose it publicly;
- Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
- If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information;
- You should only interact with test accounts you own or with explicit permission from the account holder; and
- Do not engage in extortion.  

## Official Channels 

Please report security issues via mailto:security@dangerzone.rocks, providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue.

## Safe Harbor

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

- Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
- Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
- Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
- Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

> Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.

https://policymaker.disclose.io/

[almet]

I would put Signal first, and name this "Signal". I believe putting the signal contacts here might be useful.

Another way to handle it is to provide a group link with a requirement for admins to approve new members, so we can review the folks before going further.

[apyrgio]

I'm very curious how the group link will work in practice, let's chat!

I'm fine with putting Signal first, but I still think we need to support at least email, for several reasons:

1. People may want to send longer reports with code. Signal is not good for that.
2. People may not want to use Signal for privacy concerns (no shade).
3. Email is ubiquitous.

Regarding the "Report a vulnerability" avenue, I put it there because it's the path of least resistance, for GitHub users who want to report low to moderate vulnerabilities. If you feel it may confuse things, I'm fine with removing it, since its functionality is covered by the other two means of communication.

[almet]

I believe having a clear path, without too many options will be simpler for us to handle in the long run. If we have different communication channels, we might want to explain why, and when to use them. To me, having email for general reach and signal for encrypted communication seems enough.

[apyrgio]

I pushed an update in this PR. It's not complete yet, but addresses some of your concerns. Take a look.

[almet]

I very much like this second version! Let's decide how we want people to reach to us on Signal, and then let's merge this :-)