Add SECURITY.md

[alpe]

Containing:

• Supported Versions
• Reporting a Vulnerability

[ethanfrey]

The big open question is a secure manner to submit critical bugs. I will do some research to see what people are using:

• Unecrypted email. Everyone has it, but it seems very insecure. However, this seems good enough for the Cosmos SDK, Polkadot, and Cardano
• GPG encrypted email. More secure, but how many people know how to use this? Is the bar too high? Maybe email with optional GPG key? Ethereum provides an email address with optional GPG key. Monero provides 3 GPG email contracts, as well as a Hacker One site.
• Bug Bountry Program. If we run such a program, they should maintain a secure webapp to allow us to communicate with security researchers (and reward them). Example: Tendermint uses Hacker One
• Keybase? Signal? Both are "widely used" in the crypto/security communities and provide end-to-end encryption. However, it is unclear how to create a "shared account" that multiple people at Confio could use to receive incoming messages from security researchers. (Please post any such solution)
• Custom site with Google forms 🙈 Ethereum bounty program uses google forms (click "submit a vulnerability").

Some other large projects don't even seem to have a clearly visible SECURITY.md file. Such as Avalanche, and Tezos

[ethanfrey]

Given the above research, I see two reasonable approaches (we can do one or both):

• A security email address that is received by multiple team members, along with an optional GPG key that may be used
• Set up a Hacker One bug bounty program

Shall we start with an email address, add a GPG key later, and check out how much it costs to run a Hacker One bug bounty (maybe co-financed by multiple projects using CosmWasm)?

[ethanfrey]

We have security@confio.gmbh set up.

Let's just make a simple SECURITY.md file based on one of the projects linked above to accept unencrypted emails for now. We can add the GPG key as well as a possible hacker one bug bounty link in the future.

I see major projects using similarly insecure reporting methods, so I would not block our 0.18.0 on a better approach (but happy to use a better one in the future)