As a software company, SUSE follows a well-defined process when handling security incidents. This process has been certified as an augmentation to our Common Criteria certifications at Evaluation Assurance Level 4.

A dedicated security team is responsible for handling all SUSE product-related security incidents. In that team, clear and well-defined roles are assigned for tracking new incidents and coordinating needed updates. The team works together with all SUSE R&D software specialists.

SUSE uses multiple sources to understand security incidents. These sources include the Mitre and NVD CVE databases, various security mailing lists (OSS security, Linux-distros, distros, bugtraq, and full-disclosure), direct reports, and other Linux vendors databases.

We are also part of various pre-notification mailing lists for software components, Like XEN, Samba, X.ORG, the generic distros, and the Linux-distros pre-disclosure mailing lists. Confidential pre-notifications about vulnerabilities will be treated according to established responsible disclosure procedures.

SUSE uses CVE (Common Vulnerability Enumeration) IDs as base identifiers for tracking.

Every incoming incident is evaluated:

  • Do we ship the affected software in any of our products?
  • If yes, which versions and products are affected?
  • What is the severity and impact of this problem?
  • Judging the severity, in which time line do we want to address the issue?
  • Is a CVE ID is assigned?
  • For embargoed incidents, is there a coordinated release date?

We rate the severity of incidents with two different systems, a simplified rating system and the CVSS v3.1 scoring system.

The security incidents are tracked in our own workflow system, technical details are tracked in the SUSE bug-tracking system, and the updated software package is built, processed, and published by our internal "Open Build System."

Internal SLAs corresponding to the severity rating are monitored and reviewed regularly.

Our packagers backport the required security fixes to our version of the software. To protect the stability of our customer setups, we only rarely do minor version upgrades.

After receiving fixes for the affected software, four eye reviews cross-check the source patches. A number of automated checks verify source and binary compatibility and the completeness of patch meta information as well as whether patches can be installed without problems.

Dedicated QA teams provide integration, bugfix, and regression testing for all updates before they are released to our customers.

After the release of an update, automated processes publish the updates, update notices, and cross reference information on our CVE index pages and machine-readable OVAL and CVRF XML information.