Intranet security

As you might already know, security is (very) important to Drupal. All components of Drupal core are extensively tested by the Drupal community, and the code even passes several thousands of automated tests whenever a single byte is changed. Contributed modules that are hosted on Drupal.org pass a lot of eyeballs too before they are released, although not as many as Drupal core.

An (undisclosed) client contacted us to do a security audit of a number of modules their development team had selected for an intranet project. Because access control and selective file access was key to their application, the client wanted to be assured that the (contributed as well as custom modules') code did not leave any holes open for unauthorized access.

We were able to conclude that the client's development methodology was top notch, that the code was well written, and that we did not find any issues.

A few months later, when one of the modules used in their project was updated on Drupal.org, the client contacted us again for a review of the module's newest release. Since we were not involved in the project's development itself, we were able to look at the code with fresh eyes, and managed to identify one minor security issue. The issue was reported to the module maintainer and to the Drupal security team, to make sure all future versions of this module will be safer.
Also, the client was happy, because they got the garantee that their development team had done a very good job.

Intranet security screenshot