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.

2. Drupal Security:
There is a Mini-DrupalGeddon
every week & how to survive it
Michael Schmid & Manuel Pistner

3. Michael Schmid
CTO at Amazee Group
(amazee.io, Amazee Labs, Amazee Metrics)
Welcome

4. The security process
Manuel Pistner, CEO at Drop Guard

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

8. 0 day release idea

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!

13. How it feels like:

15. And now:
Do this in 7 hours.
At 4 am.
With 100 sites.

16. The solution:
Automate every piece of it
the hackers are doing it as well

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

19. our solution

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

23. automated testing
● visual regression testing
● Unit Testing inside Docker containers

24. Demo

25. Highly Critical
directly to production (master)

33. Critical
to dropguard branch (with sync)

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

45. Evaluate This Session
THANK YOU!
events.drupal.org/dublin2016/schedule
WHAT DID YOU THINK?