openSUSE:Security disclosure policy
Disclosure policy
The SUSE security team regularly audits software that is included into/changed in (open)SUSE distributions and related products. For some details of how and when we do this please read this.
During these audits we sometimes find security problems. This includes (but is not limited to):
- security issues in the code itself
- weak configuration defaults
- problematic interaction with other components
We practice coordinated disclosure for these issues. This means that we notify internal and external stakeholders via private channels to give them a chance to discuss the reported issues with us and prepare a fix.
To ensure that issues found by us don't remain private for too long we have a policy that mandates making the reported information available to the public after a maximum embargo time of 90 days. This includes cases where no fixes are readily available for end users. We do this to ensure that no known security issue stays private for too long, giving users the information they need to judge the security posture of the software they're using. If we don't receive replies to our inquiries we reserve the right to shorten the embargo period arbitrarily.
When there's no agreement on the CRD date or the issue itself we will make the information public after 90 days at the latest to give the community a chance to act and decide on their own.
We use the openSUSE Bugzilla instance to track security audits and the issues we find. When we open a Bugzilla entry about a security issue we mark the current coordinated release date (CRD, time the information becomes public) in a bug comment of the following format:
Internal CRD: 2020-12-12 [or earlier | preliminary]
An optional or earlier denotes cases where we're free to make it public at any time (e.g. SUSE internal code with no external upstream). We use the preliminary tag at the end when upstream has not agreed to a specific date yet. In these cases we update the bug with a definite CRD (often earlier) once it is agreed upon.
The CRD doesn't start with the creation of the bug itself, but only after it is explicitly stated. In the initial report we usually suggest a shorter embargo period of 14 to 30 days, depending on the complexity and further context of the findings. In private discussions prolonged embargo periods can be established, the 90 days maximum is a hard limit, however.
We also communicate these deadlines via other means (mostly email). For non (open)SUSE parties we'll notify them 30 and 15 days (might shift slightly since this is currently done manually, so this happens on German workdays) before the CRD elapses if we have a suitable communications channel.
When a SUSE employee is responsible for fixing the security issue (e.g. because it is part of SUSE maintained code or configuration) we involve - the manager of the employee 15 days before the CRD - the next person in the reporting chain 5 days before the CRD if there is no fix available for internal testing for all affected products. This helps with situations where a packager is not responding, e.g. because he's away.
For packages that are only on openSUSE that have no (active) maintainer we file delete requests to openSUSE Factory if security issues are not fixed within the given time span. This is done to ensure that packages with known security issues are not carried in new products.
Should the established or offered embargo be violated by upstream or another involved party by not following the coordinated disclosure process, for example by publishing bugfix commits or updates ahead of the currently assigned CRD, then the SUSE security team may consider to publish all relevant information immediately.