What breaks if we never update the website?

The risk got renamed, and the new name is the point

Watch what the security profession did with this category, because the change tells you more than any warning would.

OWASP publishes a list of the most critical risks to web applications, and states on its project page which edition is current: "The most current released version is the OWASP Top Ten 2025".

In that edition the category is A03, Software Supply Chain Failures. It used to be about using components with known vulnerabilities. OWASP describes the widening in its own words: "the risk has grown in scope to include all supply chain failures, not just ones involving known vulnerabilities."

The definition is broader than most owners expect: "Software supply chain failures are breakdowns or other compromises in the process of building, distributing, or updating software."

Read the last three words. Updating software is itself named as part of the surface. This is not only about old versions. It is about the whole path a piece of code travels to reach your server.

It is also not a fringe worry inside that profession. OWASP notes the category "was top-ranked in the Top 10 community survey with exactly 50% respondents ranking it #1."

You did not choose most of what your site runs

Here is the part that changes the conversation with whoever maintains your site.

You picked a handful of things: a platform, a theme, some plugins or libraries. Those picked others. Microsoft's documentation for one package manager describes the shape plainly: "Those immediate dependencies might then also have dependencies on their own, which can continue to an arbitrary depth."

The result has a name: "This produces what's called a dependency graph that describes the relationships between packages at all levels."

Arbitrary depth is the phrase to sit with. Nobody signed off on level four. It arrived because something at level three needed it.

OWASP is explicit that tracking has to cover both: "This includes components you directly use as well as nested (transitive) dependencies."

So when somebody says the site has twelve plugins, they have counted decisions. They have not counted software.

Out of date is only one of the ways this goes wrong

The category lists several conditions, and they are worth separating because they have different fixes.

One is age, and OWASP casts the net wide: the software being "vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries."

Unsupported is the one people miss. A component can be current and still be abandoned, which means no fix is coming when a problem is found. That is a different situation from being behind. Being behind has a remedy you can schedule. Being abandoned has no remedy at all until somebody replaces the component, which is a project rather than a maintenance task, and it is worth knowing about long before it becomes urgent.

Another is not watching. OWASP lists as a symptom that "you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use."

That one is about information rather than software. It costs nothing but attention, and it is the check most sites are missing.

And the third is deliberate interference, since the category covers "vulnerabilities or malicious changes in third-party code, tools, or other dependencies that the system relies on."

Malicious changes are a different animal from staleness. Updating faster helps with the first two conditions and does nothing for the third, which is why the professional answer is knowing what you run rather than simply updating everything on sight.

Hard to spot and common at the same time

The measurement problem is stated openly, which is rarer than it should be.

OWASP writes that "supply chain failures continue to be a challenge to identify with only 11 Common Vulnerability and Exposures (CVEs) having the related CWEs. However, when tested and reported in the contributed data, this category has the highest average incidence rate at 5.19%."

Hold those two facts together. This is among the hardest categories to tie to a specific catalogued flaw, and it is also the one found most often when somebody actually looks.

That combination is exactly what produces the false comfort. Nobody reports it, so nobody worries about it. The reason nobody reports it is that it is hard to name, not that it is rare.

The prevention advice is the part that will surprise anyone expecting a lecture about staying current. OWASP recommends that you "Deliberately choose which version of a dependency you use and upgrade only when there is need."

That is not a licence to ignore updates. It rejects the opposite habit. Updating everything on sight, without knowing what changed, is how a compromised release reaches you fastest.

The same list asks you to watch for abandonment: "Monitor for libraries and components that are unmaintained or do not create security patches for older versions." And it asks where things come from: "Only obtain components from official (trusted) sources over secure links."

There is even advice about pacing the rollout itself: "Avoid deploying updates to all systems simultaneously."

So the professional position is neither freeze nor update constantly. It is know what you have, watch for news about it, and move deliberately when there is a reason.

What to check, in order

Five checks, and the first four are free.

• Ask for a list of what the site is built from, including versions. If nobody can produce one, that is the finding, and everything below it is guesswork.
• Ask which of those are still maintained. Unsupported is worse than out of date, and it is not visible from a version number.
• Find out who receives the security bulletins for those components. If the answer is nobody, the site is relying on the problem never being announced.
• Ask when an update was last applied and what broke. A site nobody has ever updated is carrying an unknown amount of change in one go.
• Only then argue about scheduling. The interval matters far less than whether anyone is watching.

The arithmetic is worth doing once, because the number surprises people. Suppose your site has 12 things you actually chose, and each of those pulls in an average of 4 more.

That is 12 plus 48, so 60 pieces of software running your site, of which you selected 12. Twenty percent. The remaining 80 percent arrived by transitive dependency, and every one of them is in scope for the same risk.

The figures are an illustration. The real ratio is usually worse, because level two pulls in level three. The point is not the number. It is that a conversation about updating plugins is a conversation about 20 percent of the problem.

Working out what a site is actually built from, before anybody argues about update schedules, is part of what we do on websites.

Sources

• A03:2025 Software Supply Chain Failures (OWASP Top 10)
• OWASP Top Ten project page (OWASP)
• Dependency resolution (NuGet documentation, Microsoft Learn)

Last reviewed 2026-09-12.