Security releases

Important security upgrades for various parts of our technology stack are frequently released outside of our preferred upgrade schedule. In many cases, these need to be applied as soon as possible.

For all sites, we should limit the amount of plugins and extensions that we use to reduce the likelihood that we need need to carry out a security upgrade outside of our planned release.

Once we are aware of a security release of a component, we need to establish which clients are vulnerable to the issue that the security release fixes.

Client are not necessarily vulnerable - it depends on how they are using that component. We can assess whether they are vulnerable by understanding the security release and considering how the client is using the system. If it isn't practical to do this, we should just upgrade them anyway.

For each client that IS vulnerable we:

1. Decide on a upgrade strategy (see below)
2. Do the upgrade
3. Document the upgrade

For each client that is NOT vulnerable

1. Document why the client isn't vulnerable
2. Let the client know why they aren't vulnerable
3. Silence any security warnings if possible

CMS security releases

CMS security releases are usually more straightforward to apply. It is often a case of applying the latest patch release.

The aim is to apply the update as quickly as possible by making minimal code changes to reduce the risk of breakages. In most cases we will apply the update directly to the site without getting client QA and only testing internally.

The process is as follows:

• Perform the update on dev and commit to git
  • Update the civicrm-docker image
  • Update the CMS
  • Check for security releases for plugins/modules (but don't update if no security release)
• Apply update to test
• Minimal internal QA
• Apply update to prod

You can check for WordPress plugin vulnerabilities using Wordfence. For Drupal modules, drush ups will indicate if there are security releases (or look at Available Updates in the UI).

CiviCRM security releases

Because of CiviCRM's release cycle, updates are likely to be more than a simple patch and will involve changing minor version of CiviCRM (e.g. from 5.43 to 5.47). This is more likely to break things. So the upgrade will be similar to a comprehensive upgrade and require client QA.

If possible, we should try to keep the code changes to the minimum necessary. In particular, if the patch is simple, we may be able to patch the affected files rather than performing a full upgrade.

The process is as follows:

• Perform update on dev and commit to git
  • Update the civicrm-docker image
  • Update CiviCRM core
  • Check release notes for CiviCRM extensions - apply if necessary (e.g. older version isn't compatible with latest CiviCRM version)
  • Check for CMS security releases
  • Check for plugin/module security releases
• Apply update to test
• More extensive internal QA
• Client QA
• Apply update to prod

PHP security release

These should be pretty straightforward to apply. A new docker image is created periodically with the latest PHP patch version. This should be rolled out to all clients when a security patch is released.

The process is as follows:

• Update the civicrm-docker image on dev and run a quick check
• Update the image on test
• Minimal internal QA
• Apply update to prod

MySQL security release

As above a new docker image is created periodically with the latest MySQL patch version. There is only one MySQL instance so this only needs to be done once for all clients.

The process is as follows:

• Update the civicrm-mysql image on dev and run a quick check
• Update the image on test
• Minimal internal QA
• Apply update to prod

cd src/civicrm-mysql
docker compose pull
docker compose up -d