Supply chain risk: the packages your website is built from
A website is built from hundreds of open-source packages written by strangers. What can go wrong in that chain and the habits that contain it.
The short answer
A modern website is assembled, not written from scratch. The framework, the build tools, the libraries for images, dates and forms, and everything those depend on: hundreds of packages, written and maintained by people you will never meet, fetched automatically when the site is built. That is how all software works now, and it is enormously productive. It is also a chain, and a chain can be attacked at any link: an old version with a known hole, a malicious package with a look-alike name, a maintainer’s account taken over, a build step that downloads something unexpected. The defence is a set of habits, and the strongest of them is needing fewer links.
Where the chain breaks
| Risk | What happens | Real-world pattern |
|---|---|---|
| Known vulnerabilities in old versions | A fix exists; the site still runs the broken version | The majority of exploited components, by far |
| Look-alike packages | A package named almost like a popular one, installed by mistake, carrying malware | Recurring on every package registry |
| Maintainer account takeover | A trusted package’s new version contains malicious code | Has happened to widely used packages more than once |
| Abandoned packages | No maintainer to fix what is found | Common deep in dependency trees |
| Build-time fetches | A build step downloads a script or binary from a URL that could change | Common in older setups |
| Compromised build environment | The machine building the site is itself compromised | Rare, severe |
The habits that contain it
- A lock file, always committed, so builds are reproducible and changes are visible.
- Automated advisories watching the lock file, with alerts routed to a person.
- Prompt updates: security fixes within days, others on a monthly cadence, through the pipeline with previews.
- Few dependencies. Every package added is a link that must be maintained; add for real value only.
- Well-maintained choices: active maintainers, recent releases, wide use, no single abandoned author deep in the tree.
- Pinned versions and no build-time downloads from arbitrary URLs.
- A clean build environment per build, so nothing persists between builds.
- Review of lock file changes in proposals, not blind acceptance.
Why small stacks are safer
Every dependency is a maintenance obligation and a potential entry point. A stack built from a small number of well-maintained, widely used packages, with as much as possible done in plain code, has fewer links to watch and fewer to break. We choose components that way and add new ones reluctantly. The productivity cost is small; the reduction in things that can go wrong without anyone noticing is large.
What this means for you
Your website is built from other people’s code, and that is fine as long as someone treats the chain as what it is. Insist on a lock file, automated advisories, prompt updates, few well-maintained dependencies and a clean build. Prefer partners who keep stacks small and can tell you what is in them. The chain will always exist; the question is how many links it has and who is watching them.
Frequently asked questions
Is open source less safe than commercial software?
No; it is more visible. Vulnerabilities in open-source packages are found and disclosed publicly, which is why you hear about them. The risk is not openness but neglect: running old versions long after fixes exist, or pulling in packages nobody maintains. The same discipline applies to commercial components; you just see less of it.
How would we know if a package we use had a problem?
Automated advisory tools watch the lock file and raise an alert when a used version has a published vulnerability, often with a suggested update. That is table stakes for any project. What the tools do not catch is a malicious change before it is discovered, which is where fewer dependencies and a clean build help.
Does this affect a finished static site?
Less than a running application, because the built files do not execute dependency code on a server. It affects the build, which produces the site, and any JavaScript shipped to visitors' browsers. A compromised build dependency can still inject code into the pages, which is why the build environment and the lock file matter on static sites too.
Sources
- OWASP Top 10: A06 Vulnerable and Outdated Components (accessed 2026-09-11)