How a Security Issue goes from Initial Report to Security Advisory.

Last updated on

22 January 2020

Process for Security Team new issue reports and Security Advisory publication.

Security Team Receives a Report of New Issue #

This section is handled by a different Security Team member each week who is assigned the duty for the week by the Security Team Coordinators.

We receive a new issue in the private queue or an e-mail from someone reporting a problem. We currently encourage all reporters to just file issues directly.
We confirm it is an actual vulnerability and meets our criteria for issues (stable release, no advanced permission required, code on d.o). When in doubt, we invite the module maintainers and ask them to confirm.
- If it is not an issue that needs to be private, we reply to the reporter (to ask them to report this issue in the appropriate public issues queue.)
Optional: If it's from an email to the team mailing list, we manually add the issue to the security team's private issue tracker via http://security.drupal.org/node/add/project-issue
We grant access to the private issue for all module maintainers and the original reporter (if they are d.o users) by adding a comment to the issue. A block with a direct link to the project on Drupal.org, with the maintainers, is available on the right hand side of the issue. This will automatically send them all e-mails with instructions on what to do and subscribe them to future notifications for the issue.
- If the reporter isn’t a d.o user, we respond to them letting them know that we received the report. Provide them with the issue number for reference. (template)
- Additionally, if access should be granted (as for original reporters or dependency maintainers), let them know that they can sign up for a Drupal.org account to be granted access to the report. Once they create an account on s.d.o, it will automatically be synced to s.d.o the first time they log into the site. mlhess, greggles, or drumm can also manually sync the account so that access can be granted to the given issue before they log into s.d.o for the first time.
If necessary the assigned member will drive the report until a SA is released.
Review patches, and schedule security release with maintainer. Note that the latest version of dreditor does not work on security.drupal.org, but you can run an older version of dreditor for greasemonkey which can work in parallel next to the regular dreditor.
As much as possible do this communication via the security.drupal.org issue queue.

If the maintainer commits a fix without prior coordination with the team, the SA can be published the next Wednesday, unless the team judges that it should be released sooner.

Security Team Assignment of Issues #

Any team member interested in the issue can assign themselves to it. Otherwise, a coordinator will assign one Security Team member to drive the report to resolution.
The security team uses the project issue availability module to regulate what types of issues security team members are available to work on, as well as how many they are willing to work on simultaneously. Issues can only be assigned to members who can accept that type and have not exceeded their availability. Security team members who are assigned weekly duty can use this assignment workflow to assign new issues for the week they are providing new issue oversight. They can also assign other issues that are marked need team response but do not have assignee.

Creating a Security Advisory - Maintainer #

The maintainer should create a Security Advisory (SA) draft as a node.
Once the SA is created, leave a link to it in the issue to get review by the team
A team member will approve it and ask you to pick a Wednesday for your release

Creating a release - Maintainer #

Note: These instructions are for contrib maintainers only. Core has separate release procedures.

Patches should be committed within 24 hours before the noon on Wednesdays (GMT-5, America/New York). The git commit message should not call attention to the fact that a security issue was fixed. Example message: "Fixed sanitization of output in overview table" is descriptive but does not contain "security" or "vulnerability".
Create a release node making sure you check the box saying : "Are you sure you want to mark this release as a Security update?"
The release node will remain unpublished.
Update the Security Advisory you created on security.drupal.org to link to this newly created release node.
Leave a comment on the issue on security.drupal.org that you have created the release.

Publishing the SA - Security Team #

Note: The instructions below are out of date. SAs now have their own content type on drupal.org and should be created via the Create Security advisory page instead.

Copy the HTML of the SA by going to the "HTML version" tab on the SA node.
Create a new forum node for "Security advisories for Drupal core" or "Security advisories for contributed projects" or Public Service Announcements.
Uncheck the "Published" field, under the "Publishing Options".
Ensure the SA author is "Drupal Security Team".
Make comments “closed”.
Increment the SA ID and use that for this new SA ID. Double-check this when publishing on drupal.org by asking folks in #drupal-security on IRC. SA ID is used in subject and body (see below)
Set the subject to [Module Name] - [Security risk level] - [Vulnerability] - SA-[CONTRIB or CORE]-YYYY-[SA ID]. See examples for Contrib or Core.
In the body, update the Date, Advisory ID, and Coordinated section.
Switch text format to "Full HTML" so that the color on the risk calculator can appear.
Edit the release node and have it link to the Security Advisory using the SA title as the link anchor text.
Get reviews from other team members in IRC.
Edit the node and publish it and the associated release node (see below); this will trigger the e-mail which must be moderated (lists.drupal.org/mailman/admindb/security-news) by Killes, Heine, Peter Wolanin, Greg Knaddison, Dave Reid, Ben Jeavons or Neil Drumm.
Mark the issue on security.drupal.org as “Closed (fixed)”, create a public issue for the dev version (e.g. 8.x of core) if the issue wasn’t fixed there already.

Final steps (optional) - Security Team #

Rebuild the release history XML feed for the project. There's a jenkins job for this now, "update_release_history_feeds" under the "d.o" tab. You can "build now" and specify the project shortname (or project nid if you know it) and it'll just rebuild the history for that project. Only certain people can trigger this job: Killes, Greggles, Ben Jeavons?
http://localhost:8080/view/d.o/job/update_release_history_feeds/
http://localhost:8081/job/update_release_history_feeds/build?delay=0sec
Get a CVE for the issue (process)

Distribution process #

Distributions under-go the same process as other project SAs but for a few differences. If the security issue is part of the distribution's code and not the code of a module that's packaged with it then undergo SA just as the same. If the security issue is in a module that's part of a distribution then follow these extra steps.

The distribution itself won't get an SA, but the new project's SA should link to the new release of the distribution (example)
The new distribution release should be marked a security update so that installations know to upgrade
It's possible that drush make might complain about not finding the newly released project code, if that happens follow the "rebuild release history XML feed" above