This task proposes to formalize how security vulnerabilities reports are handled.
The following text is a proposal for a page describing the process of handling vulnerabilities.
Intended destination: https://wiki.blender.org/wiki/Process/Vulnerability_Reports to be listed along side "Bug Reports" on the communication page.
= Blender Vulnerability Reporting Policy =
== General Process ==
Security issues should be reported to `{security[at]blender.org}`. The security team will typically get back to vulnerability reporters within several days.
== Timelines ==
Since addressing most vulnerabilities in Blender requires coordination between developers the time between initial report of a vulnerability and its public disclosure will vary.
Expectations for handling vulnerabilities:
* All reports responded within 14 days.
* All medium or high severity vulnerabilities patched within 60 days of having been publicly known.
* All critical vulnerabilities fixed shortly after they are reported.
* Updates to official Blender releases available for current and long term support (LTS) releases.
== Vulnerability vs regular bug ==
It is not possible to provide guidance on what constitutes a security vulnerability and what is just an ordinary software bug. When in doubt, please contact the Blender security team.
== Public Disclosure ==
Security related issues are to be disclosed by Blender's security team via blender's issue tracking system
[tagged with "Security"] and sent to a the `{security-announce}` mailing list.
Disclosure may be postponed until a fix is available.
== 3rd Party Libraries ==
The security team actively tracks CVEs for Blender and 3rd party libraries.
When such a vulnerability is determined to impact Blender releases,
updates and public disclosure are handled the same as other security issues.
<!-- For vulnerabilities in 3rd party libraries, see: [See Blender CVE Policy] `{a separate WIP document}` -->Notes:
- These pages were used as references:
- Debian Vulnerability Disclosure Policy some text from this page was used.
- OpenSSF Best Practices Badge Program some of the requirements for handling vulnerabilities here used (responding in a maximum of 14 days, fixing within 60 - both seem reasonable to me).
- The "Public Disclosure" mentions a {security-announce} mailing list. This is most likely to be useful for Linux package maintainers. While I'd rather avoid more mailing lists I don't think it's reasonable to expect Linux package maintainers to follow tagged tasks on Blender's issue tracker.
- This document doesn't cover what we consider medium to high risk (it's implied this is up to the developers involved to decide), the kinds of issues flagged as security concerns by static analysis tools can be handled as regular bugs in practically all cases. We don't need to state these details on the policy though.
- To my knowledge the occurrence of medium or greater risk vulnerabilities is very low, so while our process for handling these should be correct, I'm wary of having more complex processes for something that's infrequent.
Open Topics:
- KDE offers secure PGP encrypted email (in case of email interception) this seems more applicable to system-level software, but we could consider supporting it.
- The {security-announce} list could be used to notify us of CVE's in libraries Blender uses too (no strong opinion on this at the moment).
- Communicating with down-stream Linux package maintainers before public disclosure isn't part of this document - flagging this as something to address.
- When to create CVE's for Blender (again, doesn't have to be handled in this document, but it would be good to have a clear policy on that).