Add a SECURITY.md for Cylc?

[kinow]

See:

• https://github.com/standard/standard/blob/master/SECURITY.md
• https://github.com/electron/electron/blob/master/SECURITY.md
• https://github.com/grpc/grpc-java/blob/master/SECURITY.md

Not sure if needed.

[hjoliver]

I think we should do this, but maybe wait on unbundling and packaging.

[kinow]

Perhaps later we could also get one or two devs familiarised with the process to request CVE's, and start filling (maybe even retroactively) requests for when we find security issues in Cylc. I've never done it myself. But in the Jenkins and the ASF projects, there are teams that deal only with that, and give you the CVE RESERVED ID.

• https://cve.mitre.org/cve/request_id.html
• https://github.com/RedHatProductSecurity/CVE-HOWTO
• https://thoughtbot.com/blog/handling-security-issues-in-open-source-projects

Right now there are no CVE's for Cylc, so users are not able to check which versions have which issues, and then choose a mitigation or update the version. Checked other software used for workflow in NWP, but they were also not listed in the Mitre DB.

Article that covers more about challenges, issues, motivations, etc, for Open Source software & security: https://www.csoonline.com/article/3157377/application-development/open-source-software-security-challenges-persist.html

[kinow]

While reading the docs for JupyterHub in Kubernetes, they mention the process used by JupyterHub/Jupyter for security issues, which is partially related to this issue: https://zero-to-jupyterhub.readthedocs.io/en/latest/security.html#reporting-a-security-issue

[hjoliver]

This would be a good place to document that we are aware of the Jinja2 CVE that we can't take the fix for in cylc-7.8.x (the new Jinja2 version requires Python 3) but that it does not pose a risk in the Cylc context.
cylc/cylc-flow#3115 (comment)

[hjoliver]

@kinow - we can (I hope) close this with my new PRs to the main repo. Might be worth adding your comments above #11 (comment) to a new document in this (admin) repo though, for future reference?

[kinow]

@kinow - we can (I hope) close this with my new PRs to the main repo.

Yup, +1! We can add a link later to that document from other repositories like cylc-web (a possible source of security bugs 😞 ) and cylc-uiserver, etc.

Might be worth adding your comments above #11 (comment) to a new document in this (admin) repo though, for future reference?

Good idea, will do.

In the future if we have a security bug (hoping it will be a veeeery far future :) we can have other discussion about posting it to the CVE public database. But we are quite busy and we made good progress with the neat new SECURITY.md file.

Once we are closer to Cylc 8 we might have more developer bandwidth and be able to support this more bureaucratic CVE security announcement process.

[kinow]

Done in #26