Apply security fixes as soon as you can test them, take patch and minor releases on a regular schedule such as monthly, and plan major version upgrades as small projects. The generator itself matters, but so do its plugins and the packages underneath.
Three tracks
| Track | Trigger | Target |
|---|---|---|
| Security fix | Advisory that affects a package you use | Days, after a test build |
| Routine updates | Calendar | Monthly batch of patch and minor releases |
| Major upgrades | Release plus end of support for your version | Planned, with a branch and a rollback |
Why not "update when something breaks"
Sites like this tend to be left alone because they work. The risk grows quietly. Older versions fall out of support, plugin authors stop publishing fixes, and jumping three majors at once is far harder than taking each one. A regular rhythm keeps each change small.
A real example of why version awareness matters: CVE-2025-29927 affected a popular framework when authorization checks lived in middleware. The National Vulnerability Database record lists the fixed versions as 12.3.5, 13.5.9, 14.2.25 and 15.2.3 for their respective lines. A team on an old minor of a supported line had a small upgrade. A team on a long abandoned line had a rewrite. Both could be told apart by how often they updated.
A monthly routine
- List outdated packages with your package manager's outdated command.
- Split them into patch and minor versus major.
- Update the first group together on a branch.
- Run the build, the link checker and your smoke tests.
- Review the preview deployment, especially pages that use plugins.
- Merge, deploy and note the date.
For a security advisory
- Confirm whether the package is installed and which version.
- Check whether the vulnerable code is used. Reachability helps here.
- Update to the fixed version, rebuild and test.
- If no fix exists, look for a workaround in the advisory and record a review date.
Know your support window
Before choosing a generator version, check how long its maintainers support each major. If the project does not publish a policy, assume a short window and plan for it. Put the end date in your calendar.
Automate what you can
Dependency update bots open pull requests for new versions. They are most useful when combined with a scan that says which updates fix known vulnerabilities, so reviewers handle those first. Pin versions with a lockfile and install with the lockfile in CI so builds are repeatable.
Plugins deserve extra care
A plugin is code that runs in your build with the same access as the generator. Prefer maintained plugins with recent releases, check how many maintainers they have, and remove any you no longer use. See is your bundler plugin trusted code for a related look.
Try it yourself
In the vulnerability management demo, follow a finding from detection to fix. Note how severity, fixed version and ownership sit on the same screen.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans dependencies, flags which findings have a fix available, and can raise fix pull requests when you switch that on. Free scan: gold.safeguard.sh/scan.
Quick check
Should I update on the day a new major is released?
Not necessarily. Wait for early bug reports, then schedule the upgrade within your support window.
What if a plugin has not been updated in years?
Plan a replacement or fork. An unmaintained plugin will not get security fixes.
Sources
- NVD, CVE-2025-29927: https://nvd.nist.gov/vuln/detail/CVE-2025-29927
Last reviewed: 19 October 2026.
