Contacted by the security team. Now what?

When the security team finds a vulnerability in your module or receives a report detailing so, you will be contacted and asked to investigate it.

What you need to do

1. Review the report.
2. Review your module for similar vulnerabilities.
3. Create a patch and send it to the security team for review. Do not commit anything until the advisory is written and you have coordinated a release date with the team.
4. Prepare a draft of the security advisory using the previous Security Advisories as guidelines by creating a new advisory node on security.drupal.org. It will be private while its content is approved by the maintainer and security team.
5. Coordinate with the security team a time when you can do the commit and create a new release (see below).
6. Keep the information a secret to yourself, the security team, and module co-maintainers until the security announcement has been released

It is important to keep the issue confidential during this process, and to coordinate each step with the security team.

Whenever you are not sure what to do, contact security team via your issue on security.drupal.org for advice.

What happens if I don't respond?

The Security Team's priority is to get a good solution published in a timely manner. We are happy to discuss potential solutions or answer questions from maintainers, though we generally will not write the fix for the maintainers. If the maintainers don't make progress on fixing the issue in a timely manner or if communication seems to stall then the Security Team may publish an advisory urging users to uninstall the affected module and the project will be marked as unsupported (aka abandoned) to facilitate a user of the module taking it over and fixing it. Depending on the module, a security team member may take over the module and release a Security Advisory.

"Timely progress" means that the maintainer responds and is making progress on code within 2 weeks of being initially contacted. Should you not respond at all, the security team may also remove your "opt into security coverage" role.

Factors that can play into how quickly this happens include the severity of the bug, the number of sites affected, and whether the reporter presented a publication deadline when the bug was initially reported (uncommon, but it does occasionally happen). The security team does not take this decision lightly, marking a project "unsupported" can lead to problems for site maintainers and the team is aware of this.

Projects marked "unsupported" are then subject to the existing "Taking over an unsupported (abandoned) project" process. It is very common that other members of the community step forward to maintain the project after the SA is published.

What the security team will do

• Help you with questions
• Ensure timely progress
• Help with the coordinated release

Coordinated release and announcement

When a vulnerability has been corrected in coordination with the security team, you have to make a new release. This usually means an increase of the minor version, for example from 7.x-1.0 to 7.x-1.1.

See Managing releases for background information on releases. Any release created to address a security problem should be classified as a Security update release using the Release type category when creating (or editing) the release node. See Types of releases for more information. Release nodes tagged "Security update" do not get published automatically. A member of the team will manually publish it for you.

When you commit the code use a commit message that does not call attention to the security issue. Do not discuss the pending release with anyone outside of the security team and the co-maintainers of the module. If you have created automated tests that test the vulnerability do not commit them at the time of the release, but instead hold onto them for a while (e.g. 2 weeks) before committing them as this helps reduce the likelihood of an attacker creating an exploit for the vulnerability.

We make releases/announcements public on Wednesdays that are not near a major holiday for our user base (e.g. Christmas, right before Gregorian New Years). We prefer if you commit the code and create the release nodes on an agreed Tuesday after 17:00 UTC. You can then update the security advisory adding links to the release nodes and update the issue on security.drupal.org. We try not to create new releases after Wednesday 17:00 UTC, so please do not commit a fix after that time without prior approval from a security team member.

To make sure the release and announcement are published at the same time, contact your security team contact via the security.drupal.org issue queue or via irc. The list of team members includes their irc nicks where available.