Please add a security policy

[robrwo]

User story

Someone finds a security vulnerability. They look for a security policy document (usually called SECURITY or SECURITY.md) that explains how to report the issue.

Ideally, it will explain things like how Rex maintainer will handle the issue and what versions of Rex are supported.

Describe the solution you would like

There should be a SECURITY or SECURITY.md file to the distribution and root directory of the git repo that explains how to report a security vulnerability.

Additional context

CPANSec has a guide for adding a security policy [1] and also links to software to generate security policies when you rebuild a distribution for release.

You can enable private vulnerability reporting in your GitHub repository [2]. This allows people to create private issues for security vulnerabilities, and lets your collaborators work on private forks. (GitHub also treats security policies as "first class" files along with the README and LICENSE files.)

[1] https://security.metacpan.org/docs/guides/security-policy-for-authors.html

[2] https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

Note: this issue is part of a project by CPANSec to encourage popular CPAN distributions to add a security policy.

[ferki]

Thanks for starting this discussion, and linking further resources!

In general, I agree with having a SECURITY.md file, and pointing to a primary security contact willing to act as such.

The details I read on the links feel overwhelming already to decide which ones would apply for Rex and how to make those choices in order to make and enforce new policies and promises responsibly.

It feels I would prefer to start with as minimal as possible, and add further details as and when needed.

I would appreciate getting support about these topics and details from experienced security folks, like CPAN Security members.

[robrwo]

The first things are to figure out how people will report a vulnerability. I'd recommend setting up GitHub's vulnerability reporting, and link to that, with access for a subset of maintainers who will work on security issues, i.e. "security team". (You can invite others to access specific issues besides the reporter.) You may also want to have a fallback email address for people without access to GitHub, ideally one that forwards to the security team.

Then think about what version's of Rex you want to support. Only the latest? Are there older versions that you would issue patches for?
(A related issue is what Perl versions you would support, in case a security issue required using a newer Perl.)

From there you can expand it. (You may want to consider adding a version and date to the policy, if it is going to evolve.)

Think about how you would respond to security reports. What is the minimal timeframe to respond? Do you want to come up with a detailed workflow? See the Perl security policy for an example.

Do you want a policy about disclosure? For example, would you notify other downstream software or Linux distributions before making issues public? Do you want to have a minimum embargo time before publishing that is different from the recommended 30 days?

You do not want to delay publishing for too long, especially if it puts users at risk. But one way of addressing issues is to publish mitigation advice first if an actual fix takes longer to develop.

The example documentation refers to "single volunteer" who maintains the code "in their spare time". I would suggest amending that to what is appropriate for Rex.

Elaborate on what the policy applies to: are there certain kinds of issues that you don't consider security issues with Rex but how it's misused? Or how a server is misconfigured? Then outline those.

Consider also a definition of security issues:

Security vulnerabilities are considered anything that allows users to execute unauthorised code, access unauthorised resources, or to have an adverse impact on accessibility, integrity or performance of a system.

It may be worth having a separate section of the doc outlining security issues when using Rex (including system configuration), and refer to those in the larger document.

It may well be that when you get security reports, or you see reports and how they are handled by other software, that you will revise the policy.

[robrwo]

The details I read on the links feel overwhelming already to decide which ones would apply for Rex and how to make those choices in order to make and enforce new policies and promises responsibly.

I am still thinking about this.