Site Guardian

The Site Guardian module securely exposes information relating to your site's core, modules, versions, updates, etc. in JSON so that it can be consumed elsewhere. This allows you to more easily monitor all of the sites that you maintain without having to log in to each of them individually.

Keeping your site secure and up-to-date

Drupal has functionality that helps you monitor the state of your website:

1. The “Available updates” page (at /admin/reports/updates) lists all modules currently enabled, their version and the recommended version, as well as security status. You need to log in to view this.
2. The “Status Report” page (at /admin/reports/status) shows things like the current version of PHP and database engine. You need to log in to view this.
3. An email alert can be configured (via /admin/reports/updates/settings) to alert you that “things are out of date”. You need to log in to check what.

The Drupal.org security working group do an amazing job and regularly send out emails (to those subscribed) detailing any new security updates that are available for core and contrib. This list is also available via an RSS feed at https://www.drupal.org/security/rss.xml. At Cyber-Duck we whack that feed in to Slack, so we know the instant new security updates become available.

When a core security fix is released, it's obvious you need to update core, but for contrib vulnerabilities, you need to log in to every single site you look after to see whether they use that module. That takes a huge amount of time when you're looking after more than a few websites. Each will have their own access credentials (ideally protected by TFA, people!) and perhaps maintained by different teams within your organisation. You could easily miss an important security update, leaving a site vulnerable.

More generally, you should regularly update core and contrib to the latest versions available. That means you're using the latest code, but also means that if/when a security issue is released, it's probably just a minor update to what you already have. If you are jumping from version 1.2 of a module to a security fix at version 1.34, that is a much bigger risk than updating from version 1.33.

What Site Guardian does

The Site Guardian module allows you to securely grab all the info about your site in JSON format so it can be used elsewhere. The endpoints can only be hit if you use the right Site Guardian Key, set up by you beforehand in the module on each individual website.

Having this data accessible from outside the websites makes it quicker to check for security vulnerabilities and keep them up-to-date.

What we can monitor

Having all this info available means we can see:

1. An overview of all sites monitored
2. The current version of Drupal being used
3. What version of PHP is being used, to plan for any EOL dates in advance
4. Any outstanding Drupal core or contrib security issues
5. That modules are being kept up-to-date
6. Which sites are using a particular module when a new security advisory is released, so we can create and deploy a hot fix.

Having all this info for dozens of sites accessible to the whole team is a massive time saving for us and means we keep our clients' websites up-to-date and secure.

Site Guardian Companion modules

The Site Guardian module supports companion modules that can provide additional information to the JSON data returned from the API endpoints.

At present the following companion modules exist...

• Site Guardian User Status
• Site Guardian PHP Status

Companion modules do not depend on the Site Guardian module and will function perfectly well without it. They provide additional information in the core Site Status report as well as enhancing the JSON returned by the API so check please them out.

Similar modules

Vitals and Vitals Extras modules

Vitals and V Extra makes quite a few assumptions and recommended certain modules. While we didn't disagree with those recommendations, we didn't want them to be required on every site and not something we thought should be reported.
We hope to keep this module very lightweight and only show things Drupal is already reporting, but making available externally.
As an example Vitals only reports the modules requiring an update, but Drupal can show all the modules installed.
Our upstream server gathering the data will be making recommendations and highlighting issues rather than the site itself.

drd_agent

This also exposes an endpoint to allow information to be gathered by a third party source.
It seemed to take a different approach to both Site Guardian and Vitals, however, in that it reports very different information than we wanted.

Conclusion

The decision was made to create another module based on the direction that we hope to take with this module.
Site Guardian seems to fit right in the seam between drd_agent and vitals, where it is doing some similar things to both but in slightly different ways.

Configuration management

When exporting the site configuration, the site_guardian_key will be included in the config file with everything else. This is not unusual, as most modules use the configs to store private keys, passwords, etc., but there are any number of reasons why you may not wish to store the exported value and there are several ways to avoid this.
You may try overwriting the value in the settings.php for example. You could also consider the State API or perhaps even the Config Ignore module to help with this.

Drupal versions supported

We have a version of the module for Drupal 7.
We have a version of the module for Drupal 8, 9 and 10.
We're all about keeping sites secure and up-to-date, so as soon as D11 is released....

We're obviously monitoring the awesome Automatic Updates initiative closely, but don't think any agencies or large sites will use that because of tighter Dev, QA and UAT workflows.

Site Guardian Road Map

We do all this work at Cyber-Duck during our Drupal Innovation Programme (or "DRIP") days that happen every second Friday, so we're actively working on this, but slowly.

1. Security assured - DONE. We're concentrating on getting this Site Guardian API covered by Drupal’s security advisory policy.
2. Site Guardian Dashboard - DONE. We have a Laravel dashboard in place, but we want to replace this with a more powerful Drupal version.
3. Dashboard improvements... we have many planned. We intend to offer this Dashboard as a service in the future (hopefully with a free tier) with different levels of access available to "agencies", their clients, AMs, PMs as well us developers.

The aim is to make it easier to keep your client's websites secure and up-to-date, across not only Drupal an contrib modules, but also PHP and other third-party dependencies such as Symfony and CKEditor, that Drupal will no longer warn you of if there's a security vulnerability.