The Drupal project has been following a responsible disclosure model for more than 12 years. As Drupal has grown from a few thousand installs to more than 1 million, and as the number of contributed projects on Drupal.org has grown from tens to tens of thousands, the Drupal Security Team has continually evolved our processes to scale our security coverage.
We continue to work to ensure that every site owner has the opportunity to install security fixes as soon as security advisories are released, and that whenever possible fixes are available for production use before exploits can be deployed in the wild. With Drupal 8, three important changes have required further improvements to Drupal Security Team processes:
- The adoption of modern PHP libraries as dependencies, modern packaging with Composer, and a "proudly found elsewhere" philosophy (rather than Drupal maintaining its code from the ground up).
- The adoption of semantic versioning and a six-month minor release cycle.
This session will use examples from past Drupal 8 core security advisories to explore some of the following questions:
- How do we handle accelerated innovation with a limited security team? (New code and features => new vulnerabilities and attack vectors)
- How do we handle backwards compatibility and semantic versioning for security releases?
- How do we balance releasing fixes as soon as possible with avoiding disruption to existing contributed projects, custom code, and Drupal 8 sites?
- How do we handle advisories that might implicitly expose other vulnerabilities that are not yet released?
- How do we deal with upstream vulnerabilities, and how can we improve collaboration on responsible disclosure with upstream projects?
