Create a Security Policy

[joycebrum]

Closes #1511

I’ve created the SECURITY.md file considering the report vulnerability through security advisory, which is a new github feature still in beta and that has to be enabled.

If you rather not enabling it there is also the possibility to receive the vulnerability report through an email, in this case just let me know which email it would be and I’ll submit the change.

Besides that feel free to edit or suggest any changes to this document, it is supposed to reflect the amount of effort the team can offer to handle vulnerabilities. I've opted for the standard 7 days to respond and 90 days to make it public but it can also be simply a "All support will be made in a best effort base.", for example.

[dblock]

I don't think any of the maintainers are willing to sign up for responding within 7 working days or follow a disclosure timeline. I certainly am not. Are there at least 2 of the 5 folks with maintain level access who are up for this? For a timely response I propose we use Tidelift (see #1511 (comment)). I can set it up.

For a security policy I'd rather not have "best effort". Would prefer not to have one/say nothing.

[joycebrum]

I've updated the Security Policy to follow https://github.com/slack-ruby/slack-ruby-client/blob/master/SECURITY.md.

Another option you might consider is keeping the disclosure through GitHub new feature or an email (which will have no cost) and removing the response time expectation and keeping only the public disclosure timeline.

See example below:

Security Policy

Supported Versions

Security updates are applied only to the latest release.

Reporting a Vulnerability

If you have discovered a security vulnerability in this project, please report it privately. Do not disclose it as a public issue. This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.

Please disclose it at security advisory.

This project is maintained by a team of volunteers on a reasonable-effort basis. As such, please give us at least 90 days to work on a fix before public exposure.

[dblock]

Thanks. @matthiasblaesing and others should tell me whether Tidelift is a good idea, and then we should talk about the little $ it provides and how we need to go about it.

[joycebrum]

Hi @dblock, any conclusions about using Tidelift or Github Security Advisory? Just let me know which one will be better for jna and I'll update the policy!

Thanks!

[dblock]

Of 7 known maintainers in #1511 (comment) we got only 1 who said anything one way or another. So I am not sure what we can do to move it forward - IMO this is going to be "as is" for the time being. Feel free to add a +1 to that issue and maybe you'll have better success than me?