How Often Should You Update Dependencies on a Marketing Site?

How often should you update dependencies on a marketing site?

Security patches the day they land. Everything else on a slow, batched schedule with a deliberate delay. The advice to always be on the latest version was written for a world where the main risk was an old bug. The main risk now is a fresh package, and that changes the answer.

This is a shift we have made in our own practice over the last couple of years, and we have found it hard to explain without sounding careless. Nobody wants to be the studio that argues against updating. So here is the reasoning, with the evidence, and the policy we actually run.

It matters most for marketing sites specifically, because their risk profile is different from an application's and almost nobody treats it differently.

What changed about the risk?

The attack moved upstream. It used to be that an out of date package carried a known vulnerability someone might exploit. Now the more common story is that a maintainer account gets compromised and a malicious version is published, which means the newest release is the dangerous one and the stale one is fine.

Red Hat's own security bulletin on the compromise of its cloud services npm packages is a clear example. According to that bulletin, a GitHub account was compromised through a malicious VS Code extension and used to inject malicious code into 32 packages published under the @redhat-cloud-services namespace. The attack occurred on 29 May 2026 and was contained on 1 June 2026.

Read the timeline again. Three days between publication and containment. Any automated pipeline that pulled the latest version inside that window pulled the bad one. Any pipeline that waited took nothing.

Is that just one incident?

No, and more tellingly, the platforms themselves have changed their defaults in response. That is the strongest available signal that this is structural rather than a bad month. GitHub published a detailed account of what it changed across npm and GitHub Actions through 2026, and the list is long.

Among those changes: high impact npm accounts now enter a read only mode for 72 hours when they change their email or use a two factor recovery code, from June 2026. The actions/checkout action stopped checking out untrusted fork code in vulnerable triggers by default, also June 2026. And npm v12 disabled install time scripts and git or remote URL dependencies by default, in June 2026, to stop attackers using install scripts to exfiltrate credentials.

That last one is worth dwelling on. Install scripts were the mechanism by which simply installing a package could run attacker code. Turning them off by default is a large breaking change and npm shipped it anyway. Platforms do not do that over a hypothetical.

What is the three day rule?

It is GitHub's own answer, and it is now the default. As of July 2026, Dependabot version updates wait until a release has been available for at least three days before opening a pull request. Security updates remain immediate.

That split is exactly the policy we recommend, and it is satisfying to be able to point at a default instead of arguing from first principles. A version update is not urgent. A security update is. Treating both the same is what created the problem.

If you run Dependabot, this is already happening for you unless someone turned it off. If you update by hand or through another tool, adopt the same shape. Our guide to website security covers the wider set of habits this belongs to.

Why do marketing sites deserve a different policy?

Because their blast radius is different in both directions. A marketing site usually holds no customer data and no session tokens, so a vulnerable dependency is less catastrophic than the same package in your product. But a marketing site often has fewer eyes on it, deploys less often, and nobody notices a strange script for weeks.

The other asymmetry is build time versus runtime. Most of a static marketing site's dependencies never reach the browser. They run once during the build and produce HTML. A compromised build dependency can steal your deploy credentials, which is worse than a client side bug, and no amount of Content Security Policy will help.

So the exposures to worry about are your CI credentials and your build environment, not the average user's browser. That reframing changes what you actually harden. Our piece on Content Security Policy covers the runtime half that this does not.

What is our actual policy?

Four rules. Security advisories get applied the day we see them. Version updates are batched monthly and delayed by at least three days from release. Major versions get a scheduled slot, never an automatic pull request. And any new dependency has to justify itself against writing the code ourselves.

That last rule is the one that does the heavy lifting over time. Every dependency you do not add is a maintainer account that cannot be compromised into your build. We have removed more packages from client sites in the last two years than we have added, which was not true before.

The monthly batch also has a practical benefit. Ten small updates reviewed and deployed together, on a day someone is watching, is safer than ten updates trickling in over a month and being merged without much attention.

Does the delay not leave you exposed?

To known vulnerabilities, briefly, yes. That is a real cost and we do not pretend otherwise. The judgement is that for a static marketing site, a three day window on a non security version bump is a smaller risk than being first to install whatever was published an hour ago.

The important qualifier is that this only works if security updates really are immediate. A policy of delay that quietly applies to everything is just neglect with a justification. If you cannot ship a security patch the same day, fix that first and then talk about scheduling.

We also keep the lockfile committed and the build reproducible, so we always know exactly what went into a deploy. Without that, none of this is verifiable after the fact.

How do you protect the build pipeline itself?

Reduce long lived credentials and restrict who can trigger workflows. GitHub's own changes point at both. It added CircleCI support for npm trusted publishing in April 2026, describing the goal as removing long lived credentials from your CI/CD pipeline, and shipped opt in staged publishing in May 2026 that requires additional approval and two factor authentication before publishing.

It also added workflow execution policies in June 2026, letting an organisation restrict who can trigger workflows and which trigger types are allowed, and restricted cache modification so less trusted workflows cannot poison cache entries shared with other workflows.

For a typical marketing site you will not use all of that. The two that matter are: no long lived tokens sitting in CI if you can avoid them, and nobody outside your team able to trigger a workflow that touches your deploy credentials. Staging sites and deploy previews are where these pipelines usually leak, so audit those first.

What about sites that are not built from a repository at all?

They inherit a different version of the same problem. A Webflow site has no package.json, which removes this entire category of risk, and replaces it with third party scripts added through the site settings. Those scripts update whenever their vendor pushes, with no review and no delay at all.

That is not obviously better. It is the same trust relationship with less visibility. The advantage is that the blast radius is limited to the browser rather than your build credentials. The disadvantage is that you have no lockfile and no record of what changed.

The practical answer on those sites is to keep the script list short and audited, and to review it on a schedule the way you would review dependencies. Same discipline, different file.

How do you know if something went wrong?

By watching what your site loads, not by watching your dependency list. A compromised package that reaches the browser shows up as a request to a domain you do not recognise. That is detectable with a strict Content Security Policy and a report endpoint, and almost nothing else will catch it.

For build time compromises, the signal is different: unexpected changes to build output, or credential use you cannot account for. Those need logging you probably have not set up. Red Hat's bulletin notes that its deployment process strips installation time scripts, which is the kind of defence that only helps if it was in place before the incident.

Write the response plan while nothing is wrong. Our piece on website incident response plans is the short version we give clients.

So what is the honest summary?

Patch security issues immediately, delay everything else deliberately, and shrink the dependency list until there is less to worry about. GitHub's three day Dependabot default is a reasonable floor rather than a clever trick, and adopting it costs nothing.

The uncomfortable part of this advice is that it asks teams to stop treating a green dependency dashboard as the goal. A site with twelve carefully chosen packages and a monthly cadence is in better shape than one with two hundred packages all updated within the hour.

If you want us to look at what your marketing site actually pulls in at build time, or to help tighten the pipeline around it, we are happy to walk through it. Find us at phoenix.studio.