Run npm audit on almost any project and you’ll get a list of warnings, some of them critical. That doesn’t always mean your site is at risk. On a static Astro site, it often depends on where the vulnerable code runs.
Three places code can run
- In the visitor’s browser. Anything your site ships as JavaScript. A flaw here can affect visitors directly.
- On a server. On a site with
output: 'server'or on-demand pages, code runs for each request. Flaws here can be exposed to the internet. - At build time only. Compilers, bundlers and dev servers. They run on your machine or in CI, and they don’t reach visitors of a static site.
A fully static Astro site sends HTML, CSS and whatever JavaScript you chose to include. Its server-side code ran at build time and is gone by the time anyone visits.
How to triage an advisory
Ask four questions:
- Does it run in production? If the package is only used at build time, the risk to visitors is low. It still matters for your build machine.
- Does the site use that code path? An advisory in server rendering won’t apply to a site that doesn’t render on the server.
- Can an attacker reach it? Some flaws need specific input that a static site never accepts.
- Is there a fix? If updating is cheap, just update. Time spent debating a patch release is often longer than applying it.
Don’t ignore the build
“Build time only” doesn’t mean “safe to ignore”. Your build has access to source code and often to deploy keys, which is why supply chain attacks aim at it. Keep the lockfile committed, and be careful with new dependencies.
Keep the noise down
The goal is a list short enough that a real problem stands out. Em Region checks every package in the lockfile against the open OSV database, puts serious findings first, and shows you which sites are affected across your fleet. Deciding what each advisory means for a site is still a judgment call, and the questions above will help.