Security Patching Is Not a One-Off Task

We see it all the time. A project launches, everything is up to date, and within six months the server is running an outdated OS, PHP has fallen behind a minor version, Laravel has missed a security release, and nobody has run npm audit since go-live. It is not that anyone intended to let things slip. It is that patching was treated as a one-off task rather than an ongoing commitment.

Security patching is not something you do once and forget about. It is a continuous process that needs structure, ownership, and a schedule. In this guide, we will walk through each layer of a typical web stack and show you how to build a practical patching routine that keeps your applications secure without derailing your development roadmap.

Why patching matters more than you think

Every piece of software in your stack has a lifecycle. Maintainers discover vulnerabilities, issue patches, and publish advisories. If you are not applying those patches, you are running software with known, documented weaknesses. Attackers do not need to find new exploits when published CVEs give them a ready-made playbook.

The risk compounds across layers. A vulnerable npm package might seem low-impact on its own, but pair it with an unpatched PHP version and a stale server kernel and you have created a chain of weaknesses that is far easier to exploit than any single vulnerability in isolation.

Layer 1 - The operating system

Your server's OS is the foundation everything else sits on. Whether you are running Ubuntu, Debian, or another distribution, unattended security updates should be your baseline. On Ubuntu, enabling unattended-upgrades ensures that critical security patches are applied automatically without waiting for someone to SSH in and run an update manually.

For most web applications, automatic security updates at the OS level carry minimal risk. These patches are well-tested and narrowly scoped. The real risk is not applying them.

Recommended cadence: Enable automatic security updates. Review and apply non-security OS updates monthly. Schedule a full reboot window quarterly to pick up kernel patches that require a restart.

Layer 2 - PHP

PHP follows a predictable release cycle. Each minor version receives two years of active support and one additional year of security-only fixes. Once a version falls out of security support, you are on your own.

Staying on a supported PHP version is non-negotiable. At the time of writing, PHP 8.1 has already reached end of life for security support. If you are still running it, you are accumulating risk with every passing week. PHP 8.2 and 8.3 are the current supported versions, with 8.4 on the horizon.

Minor version updates within a release (for example, 8.3.10 to 8.3.12) are almost always safe to apply promptly. They contain bug fixes and security patches with no breaking changes. Major version upgrades (8.2 to 8.3) require more planning and testing, but should not be deferred for longer than a few months after a new version stabilises.

Recommended cadence: Apply patch-level PHP updates within two weeks of release. Plan major version upgrades within three to six months of a new release becoming stable. Never run an end-of-life PHP version in production.

Layer 3 - Laravel and Composer dependencies

Laravel itself follows semantic versioning and publishes security releases promptly when vulnerabilities are discovered. The broader Composer ecosystem, however, is where things get interesting. Your project likely pulls in dozens of packages, each with its own maintainers and release schedules.

Running composer audit is the quickest way to check whether any of your dependencies have known vulnerabilities. This command was introduced in Composer 2.4 and queries the Packagist security advisories database. If you are not running it regularly, you should be.

Beyond security, keeping your Laravel version current matters for practical reasons too. Laravel provides bug fixes for eighteen months and security fixes for two years after each major release. Falling behind means losing access to patches, and it makes future upgrades significantly more painful. Smaller, more frequent jumps are always easier than trying to leap across multiple major versions at once.

Recommended cadence: Run composer audit weekly, ideally as part of your CI pipeline. Apply security patches to Laravel and critical packages within a week of release. Schedule a dependency review monthly to update non-critical packages. Plan Laravel major version upgrades within four to six months of release.

Layer 4 - npm and front-end dependencies

The JavaScript ecosystem moves fast, and npm packages are notorious for deep dependency trees. A single npm install can pull in hundreds of transitive dependencies, any one of which could contain a vulnerability.

Running npm audit gives you a clear picture of known issues. The challenge is that npm audit can be noisy, especially with low-severity warnings in development-only dependencies. Focus your attention on production dependencies with high or critical severity ratings. Those are the ones that could actually be exploited in your running application.

If you are using React with Next.js, keep an eye on framework-level security updates too. Next.js occasionally patches vulnerabilities in its server-side rendering pipeline or middleware layer, and these deserve prompt attention.

Recommended cadence: Run npm audit weekly and address critical or high-severity issues immediately. Update front-end framework versions (React, Next.js) within a month of new releases. Review and update the full dependency tree monthly.

Layer 5 - CMS and application platforms

If your stack includes a CMS like Craft CMS, it adds another layer that needs attention. Craft publishes security releases and expects site owners to apply them promptly. The upcoming Craft CMS 6, which adopts the Laravel framework in place of Yii, is an exciting shift that should make maintenance more familiar for Laravel-focused teams. But regardless of the underlying framework, the principle is the same - CMS updates need to be part of your schedule.

The same applies to any other platforms in your stack, whether that is a headless CMS, a queue manager like Horizon, or an admin panel like Nova. If it is deployed, it needs patching.

Recommended cadence: Apply CMS security patches within a week. Plan major CMS version upgrades within the first few months of a stable release. Audit all deployed platforms quarterly to ensure nothing has been overlooked.

Building your patching schedule

The key to making this sustainable is to build a schedule and stick to it. Here is a practical framework that works well for most teams:

Weekly: Run composer audit and npm audit. Address any critical or high-severity findings immediately. Review and apply patch-level updates to PHP, Laravel, and key dependencies.

Monthly: Review and update all Composer and npm dependencies. Apply non-security OS updates. Check for new minor or major versions of frameworks and plan upgrades. Review your CI pipeline to ensure audit checks are running.

Quarterly: Schedule server reboots to apply pending kernel updates. Audit your full stack for end-of-life software. Review your patching process and identify any gaps. Update documentation and runbooks.

Annually: Plan major version upgrades for PHP, Laravel, and your CMS. Review your hosting infrastructure and consider whether your server configuration still reflects best practices. Assess whether your dependency choices are still well-maintained and actively supported.

Automate what you can

Manual processes get forgotten. Wherever possible, automate your patching workflow. A few practical steps to consider:

Add composer audit and npm audit to your CI/CD pipeline so that builds fail if critical vulnerabilities are detected. Use tools like Dependabot or Renovate to automatically create pull requests when dependency updates are available. Enable unattended security upgrades on your servers. Set up notifications for security advisories from Laravel, PHP, and any CMS platforms you use.

Automation does not replace human judgement, but it does ensure that nothing slips through the cracks simply because someone forgot to check.

The cost of doing nothing

It is tempting to deprioritise patching when there are features to build and deadlines to meet. But the cost of a security breach is orders of magnitude greater than the cost of regular maintenance. Data breaches damage trust, trigger regulatory consequences, and can take months to fully remediate. A disciplined patching schedule is one of the most cost-effective investments you can make in your application's long-term health.

Security patching is not glamorous work. It does not ship new features or impress stakeholders in a demo. But it is the work that keeps everything else running safely. Treat it as a first-class responsibility, give it a schedule, and make it part of your team's rhythm.

If you are unsure where to start or need help auditing your current stack, get in touch. We help teams build secure, maintainable applications and would be happy to help you put a patching plan in place.