I had the pleasure of attending DrupalCamp Atlanta 2016 in October. It was great to catch up with old friends, meet new people, and checkout some excellent presentations. I would like to thank the organizers and sponsors for making this event happen.

If you missed the event, I encourage you to checkout the session videos that were just posted. I also want to mention my presentation "The Story of an Insecure Module". I have included the abstract, video, and slide deck below. I am especially excited about the sandbox project Security Examples, which I hope will be something that the community can develop to show good and bad Drupal secure coding practices.

Abstract

There once was a Drupal module who wanted so badly to have a stable release, but they were insecure. As a useful and promising module to the Drupal community, they were so afraid that poor coding standards and lack of community reviews could lead to XSS, information disclosure, sql injection, and other vulnerabilities for their users.

The Drupal community is one of sharing and support. As a result, the module in this story takes the opportunity to learn and grow from the lessons of other modules and contributors to become much more secure and confident. The module becomes capable of being promoted to a full project and having a stable release. The community rejoices!

Come take a journey through this module's security audit and how their developer resolved each and every finding, following Drupal best practices for writing secure code.

Related drupal.org Security Examples sandbox https://www.drupal.org/sandbox/shrop/2821723

Most DNS tools (like dig and nslookup) perform IP lookups against DNS servers, ignoring /etc/hosts entries. Luckily, OS X provides the dscacheutil command to perfom a number of functions including checking local host entries. Below is an example that I used to verify the hostname/IP address combo that my system had registered in /etc/hosts.

I use drush aliases between Drupal VM and Drupal hosting services quite a bit. It was great to learn that drush site-set allows me to set the alias to use for the current session, so I don't have to type the alias name over and over again. For instance, I can set an alias like this: $ drush site-set @drupalvm.drupal8.dev, allowing me to check the status of the site on the Drupal VM with $ drush status.