The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

openSUSE:Security disclosure policy

Jump to: navigation, search

Icon-security.png

Disclosure policy

The SUSE security team regularly audits software that is included into/changed in (open)SUSE. 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 issue 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 information about security issues available to the public after a maximum 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.

We use the (open)SUSE Bugzilla instance (https://bugzilla.opensuse.org, https://bugzilla.suse.com) to track security audits and the issues we find. When we open a Bugzilla entry about a security issue we start the CRD with a comment that states the coordinated release date (CRD, time the information becomes public) in the 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. It may and should be shorter than 90 days if all involved parties agree that a shorter timeline is doable.

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.

When there's no agreement on the CRD date or the issue itself we will make the information public 90 days at the latest to give the community a chance to act and decide on their own.