Skip to main content

Security Policy

SchedMD Slurm Security Response Process

SchedMD takes security seriously. We follow a coordinated disclosure process which is outlined below.

While we strongly encourage discoverers to report potential security issues to us and follow our disclosure process, we will respect their wishes and work with them in cases where their preferred process may vary.

View Past Security Disclosures

Contact:
security@schedmd.com

If required, please contact us for GPG keys.

Scope:

This process covers the Slurm workload manager itself. Issues with closely related components — such as MUNGE or third-party SPANK plugins — may be raised with us and we will work with the reporter to identify the appropriate contacts and coordinate disclosure.

Slurm Vulnerability Disclosure Process:

  1. Problem identification and triage.
    1. The issue is identified, and the code base reviewed for similar and related issues.
    2. Potential mitigations and related configuration options identified.
    3. Fix is developed and tested internally.
    4. A CVE number is requested, identifying the original problem reporter. Details are not released until the end of the embargo period.
  2. Pre-advisory embargo period and SchedMD customer notification
    1. Pre-advisory announcement is made to the private SchedMD customer mailing list, and any mitigations and patches are made available upon further request.
    2. Customers requesting fixes and further details on the issue are required to adhere to the embargo period, and not disclose the issue outside of their operational staff and management.
    3. If maintenance outages are required and require notification of system users, we request that customers do not identify the specific issue that is leading to that maintenance outage.
    4. Any fixes prepared in response will not be applied to the main SchedMD/slurm Git distribution until the embargo period has expired.
    5. SchedMD may, at its discretion, notify external Slurm package maintainers (e.g., Debian, EPEL, FreeBSD) during this embargo period that a security fix will be published on the established end of the embargo period. Such notification will not include specifics of the issue, only that a security issue will be leading to the publication of new releases.
    6. In most circumstances, the embargo expiration will be set for two weeks after customer notification.
    7. If, in SchedMD’s opinion, details of the issue have been made publically available, the embargo period may end earlier than the scheduled date.
  3. Advisory public release:
    1. Public release is generally made in conjunction with publication of the next maintenance release of all supported branches. (Currently, this is the major releases made within the past 18 months, which corresponds to the last two major releases.)
    2. Notification is made to the slurm-announce and slurm-users lists of the immediate availability of the fixed releases, alongside disclosure of the security issue they address.
    3. All vulnerable releases will be removed from public download on SchedMD’s website.