The blueprint for secure Drupal 8 platform/builds with composer
This session will focus on what a secure Drupal 8 distribution should look like, and how to use Composer to build, package and deploy a Drupal 8 site.
In a Drupal 8 site, the only code in the repository will be custom code - everything else is defined as a dependency. This makes it clear what the audit surface is. If it's in the repository, it's custom-code. Everything else is added via our composer.json file.
This presents a unique opportunity for security auditors to automate checking of dependencies and allows us to move away from a vetted module list. Anything that has a stable version constraint is automatically covered by the Drupal security team. Anything that does not, is a flag for investigation.
With the proposal of PSR-9 and 10, identifying security risks could become automated. Sensiolabs already runs a composer.lock checking service. This allows you to upload your composer.lock and it will advise you if any of the versions you are running contain security exploits. This is similar to the Drupal security team, or the update.module, but for the wider PHP/composer eco-system.
Moving to this approach lets those building platforms and distributions with Drupal 8 avoid the need to have a 'vetted' module list checked into the repository, or even worse - the need to bypass a 'no custom code' paradigm by adding module code in the theme.
Drupal 8 and Composer are the new era of secure Drupal sites.