Documentation Level: 
Intermediate
Documentation Status: 
No known problems

Do not commit changes until you have coordinated with the Backdrop Security Team.

When the Security Team learns about a vulnerability in your project, you will be contacted and asked to investigate. If you are not able to assist with the problem, please let them know as other arrangements can be made.

Process: from report to release

  1. An issue is reported to the The Security Team.
  2. The Security Team will create a private repository for collaboration
  3. The Security Team will add an issue to that repository containing the relevant information and a TO-DO list.
  4. The Maintainers will review the issue and the TO-DO list, and can begin working on a solution.
  5. The Maintainers should draft a Security Advisory on backdropcms.org  (but the Security Team will be available to assist).
  6. The Maintainers will draft a Pull Request against the private repository for the Security Team to review, and will iterate until all parties are satisfied.
  7. Once the Pull Request is approved, the Maintainers and the Security Team will decide on a release date.
  8. Nothing else will happen until the release date.
  9. At the time of the release, the Maintainers can merge the Pull Request or branch to the public repository, add a tag for the release, and push the tag up as well. 
  10. After the tag is public, three things need to happen at about the same time. (To make sure the release and announcement are published at the same time, you can contact your Security Team contact directly, or email security@backdropcms.org.)
    1. The Maintainers will create a release from the tag on GitHub.
    2. The release must be marked as security release on backdrocms.org by the Backdrop Security Team
    3. The Security Advisory must be published on backdrocms.org  by Backdrop Security Team
  11. After the Security Advisory has be published, the Backdrop Security Team is likely also going to request a CVE that references the Security Advisory. A CVE should only be requested by the Backdrop Security Team, as they are the only ones who know everyone who needs to be credited. 

What you need to do as a project maintainer

  1. Respond to the Security Team promptly (even if it's only to let them know you cannot assist).
  2. Review the information you have been provided by the Security Team. 
    1. The issue should contain a description of the problem, steps you can use to reproduce it, and anything else the reporter initially provided. There will also be a checklist of actions so that you can see which items have already been completed.
  3. Create a Pull Request and push it to the private repository for the Security Team to review. 
    1. Do not work on anything in a public location. The PR should be created on a branch that will only be pushed to the private repository. 
  4. Prepare a draft of the security advisory on backdropcms.org using previous Security Advisories as guidelines. 
    1. The Security Team will provide you with a draft advisory node containing the Advisory ID. This node must be kept un-published until release day.
  5. Coordinate with the Security Team on a date when you can update the public repository.
    1. Security releases/announcements can be made public on any Wednesday that is not near a major holiday.  
    2. Commits, tags, and GitHub releases should be made between 17:00 UTC on Tuesday (the day before the release date) and 22:00 UTC Wednesday.
    3. If it becomes necessary to commit a fix outside that window, please get prior approval from a Security Team member.
  6. On the agreed date, commit the approved changes.
    1. When you commit security changes use a commit message that does not call attention to the exact security issue. Do not discuss the pending release with anyone outside of the Security Team and the co-maintainers of the project. If you have created automated tests that test the vulnerability do not commit these tests at the time of the release, but instead hold onto them for a while (e.g. 1 month) before committing them, as this helps reduce the likelihood of an attacker creating an exploit for the vulnerability.
  7. On the agreed date, create a tag for release.
    1. We encourage Security releases to increase the minor version, for example: from 1.x-1.1.1 to 1.x-1.2.0.
  8. Keep the information a secret between yourself, the reporter, the Security Team, and project co-maintainers until the Security Advisory has been published.

It is very important to keep the issue confidential during this process and to coordinate each step with the Security Team.  If  you are ever not sure what to do, ask a Security Team member 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.  It is always preferable for the maintainer to handle the change themselves. However, if the maintainers are unavailable, don't respond within 2 weeks of being initially contacted, aren't able to make progress on fixing the issue, or if communication and/or progress stalls, then the Security Team is authorized to commit a fix for the problem, and issue a security release for the project along with a Security Advisory.

Factors that can play into how quickly this happens include the severity of the bug, the willingness of the maintainers, and the number of sites affected. 

Security Team Responsibilies

  • Facilitate communication between reporters and maintainers
  • Answer any questions from maintainers
  • Ensure timely progress on the issue
  • Review patches or PRs to resolve the concern
  • Create a draft Security Advisorys on backdropcms.org 
  • Review and publish the Security Advisory on release day
  • Mark the release on backdropcms.org as a security release
  • Request a CVE on behalf of the project

About Releases

When a vulnerability has been resolved in coordination with the Security Team, a new release is required. 

See Creating releases for background information on releases. Any release created to address a security problem must be classified as a Security release. See Types of releases for more information. Releases do NOT get marked as "Security update" automatically. A member of the team must manually make this change for you.

Coordination with the Drupal project

The Backdrop and Drupal communities can make security releases/announcements public on any Wednesday that is not near a major holiday.  

If a problem affects both the Backdrop CMS and Drupal versions of a project, both projects should have releases on the same day. To collaborate with the Drupal maintainers, the Backdrop Security Team will have access to an issue on security.drupal.org.

There are some cases where either Backdrop or Drupal does not learn about a securtiy release ahead of time, and a release comes out for one project but not the other. In these cases, a release should be made as quickly as possible for the lagging project. The changes can be made in public for the sake of efficiency, this is acceptable because the problem itself has also already been made public.

Drupal Security Team collaboration

The Backdrop CMS Security Team collaborates with the Drupal Security Team on matters regarding Drupal core, and contributed projects for supported Drupal versions.

D7 Security Group collaboration

The Backdrop CMS Security Team collaborates with the Drupal 7 Security Group on matters regarding Drupal 7 modules that have reached an official End Of Life, but are still supported by the larger Drupal community.

Original Source: 
Drupal security releases