Security issue release process

Planning

Schedule

When picking a Wednesday for a release date, be sure to consider major holidays or times when people are unlikely to be working. Holidays or other events to avoid when scheduling a security release include:

• May 1st, when it happens to fall on a Wednesday or Thursday
• DrupalCons
• Thanksgiving in the USA (fourth Thursday in November).
• The end/beginning of the Gregorian year (i.e., around Christmas and New Year's)

Security releases may still be made on these days in rare circumstances, but if it seems safe to postpone the release then the security team and maintainer will aim to do that.

Policy on committing fixes - the release window

Maintainers may commit the fix up to 24 hours in advance of the release time. If the issue is particularly severe and the maintainer is able to coordinate with a security team member in slack or on the private issue, then we can coordinate the commit, the creation of the release node, and publishing of the Security Advisory all happen within minutes of each other.

Draft the advisory

When a Gitlab issue has been tagged "Security advisory needed", drupalbot will automatically add a link prompting maintainers to create an advisory for the issue. These links are in the format https://www.drupal.org/node/add/sa?field_project=[PROJECT_NAME]&issue=[U....

Once a draft has been saved, drupalbot will update the issue with the "Security advisory drafted" label and provide a link to the draft.

Release day preparation

These activities take place at or near the start of the release window for each issue planned to be released.

Place, date and time

For Drupal security team members only, we coordinate in Slack:

• Place: #security (see “Using Security Team Chat” section for more details)
• Date: Advisories are released on most Wednesdays.
• Time: From 12:00 Americas/New York (UTC-5 or UTC-4 depending on daylight savings time)

Confirm pending release(s)

Maintainers are responsible for creating the release draft. Releases of type "Security update" are created as drafts and are only publishable by members of the security team.

Submit a pre-notification message in Slack

As a convention, the security team will share a message in #security-team near the start of the window to confirm any expected releases. The typical messages are:

• Today is a [core|contributed project] security release window. There is at least one [core|contributed project] advisory planned for today.
• Today is a [core|contributed project] security release window. There are no [core|contributed project] advisories planned for today.

Review the issue

Get a sense of the issue and the resolution so that you can validate the security advisory. Also note if there are any additional actions that were planned to occur as part of the release (for example, marking a branch as Unsupported).

Review the draft

The draft should be reviewed for general correctness, typos, and level of information disclosure. Key points to check:

• Is the "Affected versions" correct?
• Is the "Security risk" calculation accurate?
• Has a vulnerability type been listed?
• Have the correct release number(s) been listed under "Solution"? Are the links to the release(s) correct?
• Have the "Reported By", "Fixed By", and "Coordinated By" values been filled in? Was anybody missed?

Source and assign CVEs

Coordinate with @greggles, @yesct, or @mlhess to generate a CVE for the issue. Enter that number in the "CVE IDs" field.

Release process

Once all of the day's expected releases have been prepared, complete the following steps for each advisory. In summary: publish releases, publish advisories, release emails, post a slack notification, assign and save the contribution records, confirm automations worked.Unsupporting a project follows a different process documented separately.

Publish the release(s)

For each unpublished release node, edit it and enable "Published" under publishing options and save. Wait for the release to finish saving before proceeding to the next step. A single advisory may include multiple releases if multiple branches of a project are supported.

Publish the advisory/advisories

Once the release(s) for the project of the advisory have been published, edit it and enable "Published" under publishing options and save. The "Advisory ID" value will be filled in automatically at this time.

Release emails

Notification emails are staged in the security team's email queue. Once all releases and security advisories have been published, ping @greggles, @mlhess, or @drumm to release the emails.

Post Slack notification

Once all releases are complete, post a brief message in #security-team with direct links to the advisories. A typical message is:

The [count] [core|contributed project] security advisories planned for today are:

• Full title of the advisory, linked
• etc.

Edit and save the contribution records

At the bottom of each published security advisory will be a "Contribution record" button. This will open up a new tab and prefill a contribution record with every user listed on the advisory. Click the "Give credit to everyone" checkbox so that the every row is checked (every line is green) and hit Save.

You can ignore the generated commit message.

Confirm automations worked

Keep an eye out to make sure that the notification emails hit inboxes and that social media posts happen within about 30 minutes. Greg manages the social media automations (help from team members is welcome).