Yes. A static site has no application server to patch, but it still depends on a build toolchain, packages that ship to visitors, third-party scripts, serverless functions and hosting settings. Any of those can carry known vulnerabilities, so scanning dependencies and configuration is still worth doing.
Myth vs fact
| Claim | What is true |
|---|---|
| No server means no attack surface | The attack surface moves to the build, the CDN settings and the browser |
| Static files cannot be exploited | The files can contain vulnerable JavaScript that runs in every visitor's browser |
| Hosting is managed, so security is managed | The host runs the platform. Your packages, plugins and configuration are still yours |
| Nothing dynamic, nothing to scan | Forms, search, comments and auth usually arrive through functions or third-party services |
The shared responsibility idea is the same one that applies to any cloud service. The provider secures the platform. You secure what you put on it.
Where the risk actually lives
A typical static site has four layers worth looking at.
The build. Your site generator, its plugins and every transitive package run on a developer laptop or in CI. A malicious or vulnerable package here can read environment variables and tokens available to the build.
The shipped bundle. Front-end libraries that end up in the output run in visitors' browsers. A vulnerable version of a rendering or parsing library can become cross-site scripting on your own pages.
Third-party scripts and embeds. Analytics, chat widgets, video players and tag managers run with the full privileges of your page unless you restrict them. See your tag manager is a second deployment pipeline and CDN supply chain security risks.
Serverless functions and form handlers. These are real code with real dependencies, and they often hold API keys. Treat them like any backend service.
What a scan should cover
- Dependencies from your lockfile, including build-only packages, with a clear label for which ones ship to visitors.
- The functions directory, scanned as its own project with its own manifest.
- Scripts loaded from outside your domain, listed so someone owns each one.
- Hosting configuration: redirects, headers and any custom domain records that point at services you no longer use. See dangling DNS and subdomain takeover.
How often
Run it on every pull request, and again on a schedule. New advisories are published against packages you already deployed, so a site that passed last month can fail today with no code change. A weekly or daily rescan of the stored dependency list catches those.
Try it yourself
Open the dependency inventory demo and look at how direct and transitive packages are listed together. Notice how many packages sit two or three levels down from anything you chose yourself.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard can build an SBOM from a repository, scan its dependencies, and apply reachability analysis so you can see which findings sit in code that actually runs. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a site built with a static generator safer than a CMS-driven one?
It usually exposes less at runtime, because there is no database or admin login to attack. It does not remove supply chain risk from the build or from third-party scripts.
Do I need to scan if I have just a handful of packages?
Yes, because the count you chose is small and the count you installed is not. Transitive packages are where most surprises live.
Last reviewed: 19 October 2026.
