How to Keep Your CMS, Frameworks and Libraries Up to Date

You cannot protect what you do not know exists. Start by creating a complete catalogue of every software component your application depends on. This includes your CMS core, themes, plugins, server-side frameworks, front-end libraries, and transitive dependencies (the dependencies of your dependencies).

• List your CMS platform and its exact version (e.g., WordPress 6.4.3, Drupal 10.2.1, Joomla 5.0.2).
• Run npm list --depth=0 or yarn list to enumerate Node.js packages and their versions.
• Run composer show to list all PHP packages managed by Composer.
• Run pip list or review requirements.txt / Pipfile.lock for Python dependencies.
• Run bundle list for Ruby Gems or inspect Gemfile.lock.
• Document server-side software versions: web server (Apache, Nginx), PHP version, Node runtime, database engine.
• Record all third-party JavaScript libraries loaded via CDN or inline script tags.
• Store this inventory in version control so changes are tracked over time.

Knowing what you have is only useful if you also know when something becomes vulnerable. Vulnerabilities in popular software are published publicly — often within hours of a patch being released — giving attackers a narrow window to exploit unpatched systems. You need proactive monitoring to close that window.

• Subscribe to the official security advisories for your CMS (e.g., WordPress Security Releases, Drupal Security Advisories, Joomla Security Announcements).
• Monitor the NIST National Vulnerability Database (NVD) for CVEs affecting your stack.
• Use npm audit to check for known vulnerabilities in Node.js dependencies.
• Use composer audit (Composer 2.4+) or the local-php-security-checker tool for PHP packages.
• Use pip-audit or safety check for Python packages.
• Use bundle exec bundler-audit for Ruby Gems.
• Enable GitHub Dependabot or GitLab Dependency Scanning if your code is hosted on those platforms.
• Set up alerts in your package manager or a dependency monitoring service so you are notified automatically. Sensagraph continuously scans your live site to detect outdated or vulnerable software components.

Without a written policy, updates happen inconsistently or not at all. A policy removes ambiguity: every team member knows what needs to be updated, how quickly, and who is responsible. Tailor your timelines to the severity of the risk.

• Define update categories: critical security patches (apply within 24–48 hours), high-severity patches (apply within 7 days), minor/medium patches (apply within 30 days), feature releases (scheduled quarterly or as needed).
• Assign a named owner responsible for monitoring and applying updates for each application.
• Document the update procedure so any team member can execute it.
• Require sign-off from QA or a senior developer before any update goes to production.
• Include third-party managed services and CMS plugins/themes explicitly in the policy — these are frequently overlooked.
• Review and update the policy at least annually.

Manual checks are error-prone and easily skipped under deadline pressure. Integrating automated dependency audits into your CI/CD pipeline means every code push and every build is checked for vulnerable dependencies before anything reaches production.

• Add npm audit --audit-level=high as a CI step; fail the build if high or critical vulnerabilities are found.
• Add composer audit or local-php-security-checker as a CI step for PHP projects.
• Add pip-audit or safety check --full-report as a CI step for Python projects.
• Use bundler-audit in your Ruby CI pipeline.
• Configure Dependabot (GitHub) or Renovate Bot to automatically open pull requests for dependency updates.
• Pin exact dependency versions in lock files (package-lock.json, composer.lock, Pipfile.lock, Gemfile.lock) to ensure reproducible builds and prevent silent version drift.
• Scan Docker base images for known CVEs using tools like docker scout or trivy as part of your container build pipeline.

Applying updates directly to production without testing is a common cause of outages. A staging environment that mirrors production lets you verify that an update does not break functionality before your users are affected.

• Maintain a staging environment that is as close to production as possible (same PHP/Node/Python version, same web server config, same database engine and version).
• Apply all updates to staging first and run your full automated test suite (unit, integration, and end-to-end tests).
• Manually test critical user journeys (login, checkout, form submission, API endpoints) after applying updates.
• Check application logs for new errors or warnings introduced by the update.
• If your CMS has a staging plugin or deployment workflow, use it (e.g., WP Staging for WordPress, Acquia Cloud for Drupal).
• Document any compatibility issues discovered during testing and resolve them before moving to production.

Even well-tested updates can occasionally cause issues in production due to environment differences or edge-case data. A disciplined deployment procedure minimises the blast radius if something goes wrong.

• Take a full backup of your database and file system immediately before applying any update — verify the backup is restorable.
• Enable maintenance mode on your CMS before applying updates to prevent data corruption during the process.
• Apply updates during a low-traffic window to reduce user impact if a rollback becomes necessary.
• For CMS platforms: use built-in updaters (WordPress Dashboard, Drupal's drush updb, Joomla's Update Manager) rather than manual file replacement.
• For code-managed dependencies: update your lock file (npm install, composer update), commit it to version control, and deploy via your standard pipeline.
• Immediately after deployment, check your monitoring dashboards, error logs, and uptime alerts for anomalies.
• Keep a rollback plan ready: know exactly how to restore from backup or revert a deployment within minutes.

Every inactive plugin, unused theme, or abandoned library is an unnecessary attack surface. Attackers regularly exploit vulnerabilities in deactivated but still installed WordPress plugins, for example, because the code is still present on disk even when not in use.

• Audit all installed CMS plugins and themes; completely uninstall (delete, not just deactivate) any that are not actively used.
• Remove unused npm packages: run npm prune and remove explicit entries from package.json.
• Remove unused Composer packages: run composer remove vendor/package for packages no longer needed.
• Replace abandoned libraries (no commits in 2+ years, no response to CVEs) with actively maintained alternatives.
• Consolidate overlapping libraries that serve the same function (e.g., two date-formatting libraries) to reduce surface area.
• Review and remove unused CDN-loaded scripts from your HTML templates.

For low-risk, well-tested updates — particularly CMS minor releases and security patches — enabling automatic updates reduces the window between vulnerability disclosure and patching without requiring manual intervention every time.

• Enable WordPress automatic background updates for core minor and security releases by adding define('WP_AUTO_UPDATE_CORE', 'minor'); to wp-config.php or using a managed hosting plan that handles this.
• Enable auto-updates for individual WordPress plugins that you trust and that have a strong update track record.
• For Drupal, consider using drupal/automatic_updates module for security-only updates.
• Configure Dependabot to auto-merge patch-level dependency updates that pass CI checks.
• Ensure that auto-update notifications are sent to a monitored email or Slack channel so you are always aware of what changed.
• Do NOT enable auto-updates for major version upgrades — these require manual testing due to potential breaking changes.

Even the update process itself can be an attack vector. Supply chain attacks — where malicious code is injected into a legitimate package — are increasingly common. Take steps to verify the integrity of what you are installing.

• Only install plugins, themes, and packages from official repositories (WordPress.org, Packagist, npm, PyPI) or trusted vendors.
• Verify GPG signatures for CMS core releases where available (Drupal and Joomla publish signed release archives).
• Use npm ci instead of npm install in CI environments to install exactly the versions in your lock file.
• Enable Subresource Integrity (SRI) for any JavaScript or CSS loaded from a CDN by adding integrity and crossorigin attributes to your <script> and <link> tags.
• Audit new or unfamiliar packages for suspicious code before adding them to your project (check maintainer history, download counts, and source code).
• Avoid installing packages with typosquatting-risk names (e.g., lodash vs lodahs) — double-check package names before running install commands.

Keeping software up to date is not a one-time task — it is an ongoing operational process. New vulnerabilities are disclosed every day, and your stack will fall behind unless you build continuous monitoring into your regular workflow.

• Schedule a recurring monthly review of your full software inventory against the latest available versions.
• Set calendar reminders or automate alerts for end-of-life (EOL) dates of major components (e.g., PHP version EOL, Node.js LTS end dates).
• Re-run dependency audit commands (npm audit, composer audit, pip-audit) at least weekly, or after every significant dependency change.
• Review your update policy and CI/CD security checks quarterly to ensure they cover your current stack.
• Track your mean time to patch (MTTP) for security vulnerabilities as a KPI and aim to reduce it over time.
• Use continuous automated scanning of your live application to catch version disclosures and outdated components as they appear — Sensagraph monitors your site around the clock for newly disclosed vulnerabilities in your detected software stack.