This document discusses Drupal security and how to automate security updates. It describes how security patches are released for Drupal and the need to quickly update sites within hours. It outlines different automation solutions like Drop Guard for monitoring modules, automatically applying security patches based on risk level, and integrating with automated testing and deployment systems. The solutions aim to automate the security update process that currently requires manual work to reduce risk from attacks targeting known vulnerabilities.
5. How a security patch is released
● User submits patch on special issue queue
● Security team reviews it
● Security team contacts maintainer
● Patch released by security team & maintainer
6. Security patch release
● patch is publicly available
● conspicuous vulnerability
→ hackers know how & where to hack
the several versions now
● site update needed in time!
7. The security levels
● Not Critical: scores between 0 and 4
● Less Critical: 5 to 9
● Moderately Critical: 10 to 14
● Critical: 15 to 19
● Highly Critical: 20 to 25
9. Why do we need to update?
Update even not enabled
modules!
DrupalGeddon:
first attacks just 7h after
security update release
Drupal 8 & Front-End
Build systems:
external libraries
10. Every library as an item
of any upcoming software
needs individual protection
11. How to stay informed
● Drupal.org
● Newsletter/ Mailinglists
● RSS Feed
● Social media (Twitter, LinkedIn..)
12. Manual process
● “drush updb”, check patched core/ modules
● Manual QA
● Ticketing system
● Stakeholder communication
● Deployments
● and so on!
17. Needs for automation
● Monitoring
○ Current Module Version
○ Available Module Version, plus security level
● Patching
○ Regular Patching, Patch detection, Composer,
Git Submodules
○ Failure Handling -> Ticketing system
● Git support
○ Push into different Git branches based on
security level
18. Needs for automation
● Testing
○ Integration into Continuous Integration System
● Fully Automated Deployments
○ Running Deployment tasks
● Reporting
○ Ticketing system
20. Drop Guard Monitoring
● Installed Drop Guard Module on each production site
● Monitors each Module for version
● Compares to available Modules from drupal.org
21. Drop Guard Patching
● If new Module version available
○ Check against security levels
○ Automated applying of security patch to
Core or Contrib Module
○ Commits into Git production branch
● Supports plain code, git submodules,
composer
● Reports into Jira (errors or success)
amazee.io deployments
● Full automatic deployment on new
push into branches
● Possible deployment tasks
○ drush updb, etc
22. Drop Guard
● different processes based on security
levels
● non-highly critical patches applied to
another branch
amazee.io
● syncs database and files from
production to testing site
process
● after testing done, manual merge into
production branch
43. FIND US
there will be demos!
Drop Guard - Booth #105
amazee.io - Booth #700
44. JOIN US FOR
CONTRIBUTION SPRINTS
First Time Sprinter Workshop - 9:00-12:00 - Room Wicklow 2A
Mentored Core Sprint - 9:00-18:00 - Wicklow Hall 2B
General Sprints - 9:00 - 18:00 - Wicklow Hall 2A