Add SECURITY.md

[bluwy]

I'd like to propose adding a security policy to all repos by default. In contrary to https://github.com/changesets/changesets/blob/main/SECURITY.md, this document provides a clearer description of the versions supported and where to report the vulnerability.

If we agree to this, we should enable private vulnerability reports for each repository (in the settings):

[Andarist]

Hm, this kinda implies we'd have to do security updates to all non-latest (within the specified timeframe) majors of all subpackages. This is close to impossible. In the case of Changesets CLI we can only reasonably commit to supporting the CLI itself this way (other subpackages would only get security updates for the versions that the CLI depends on)

[bluwy]

I'm happy to reword this differently, it felt weird with the wording before that when we release v3 than v2 would instantly not have security updates.

I think our subpackages are relatively simple or not-many-majors or security-sensitive to be a problem, we can also reduce the timeframe too.

But I'm ok with anything that makes it so that we still support v2 for a while. Would you suggest some words we can add here?

[beeequeue]

we should also add a section regarding node version support, which i propose to copy from Nuxt;

the latest Changesets versions support the latest node LTS version, no matter what the package manifests say

[bluwy]

Hmm, could our manifest say differently now? It would be easier to track when engines is the single source of truth

[beeequeue]

there is no LTS alias we could use, but it will become a lot easier with the new LTS schedule of 1 node version per year which is LTS for one year

but if we use a statement like "only the LTS version is supported" the engines just restrict installations, and if we forget to drop/add a version it doesn't matter to our official stance

[bluwy]

Is your point that we ONLY support LTS versions? (dynamic/rolling version support) I personally prefer to not do that and stick with static ranges. I don't think it's a lot of churn for us to maintain for previous node versions, and we can always bump majors when it affects us.

[beeequeue]

the current version could only support LTS versions. any backwards support would be set in stone when it's no longer the currently maintained version

but yes, if we support old versions for a year then it might not make as much sense