Shipped dependencies end up in the files your visitors download and run in their browsers. Build-only dependencies run on your machine or in CI to produce those files and never reach the browser. The split matters because the two groups fail in different ways and need different fixes.
Two groups, two kinds of risk
| Build-only | Shipped | |
|---|---|---|
| Where it runs | Laptop, CI runner | Visitor's browser |
| Examples | Site generator, bundler, minifier, image tools, linters, test runners | UI framework, rendering library, date or markdown parser used at runtime |
| What a flaw can do | Read build secrets, alter output, run code during install | Run script in your visitors' sessions, break pages |
| Who is affected | You and your pipeline | Every visitor |
A vulnerability in a minifier does not put a visitor at risk by itself. It can still matter if the flaw lets a crafted input run code during your build, because CI often holds deploy tokens.
How to tell which is which
- Check the manifest sections. In a Node project, runtime packages are usually listed under dependencies and tooling under devDependencies. Treat that as a hint, not proof. Many projects list everything in one place, and some frameworks expect build tools to be listed as regular dependencies.
- Read the output. Search the built folder for library names or version banners. If a package name appears in the bundle, it shipped.
- Use the bundler report. Most bundlers can emit a stats or analysis file listing which modules entered each chunk.
- Check the source map if you publish one. It lists the original source paths that went into the bundle, which is a convenient proof of what shipped. It also means you should decide deliberately whether to publish it.
Why transitive packages complicate it
A shipped package can pull in other packages that also ship. A build-only package can pull in dozens that do not. A scanner that reports the top level alone misses both. Ask your tool to show the path from your manifest to the vulnerable package, and whether that path touches the bundle.
What to do with the answer
- Shipped, vulnerable, and the vulnerable function is used: fix first, since visitors are exposed.
- Shipped, vulnerable, not used by your code: schedule the update, and record why it is lower priority.
- Build-only, flaw triggers on untrusted input to the build: check whether your build processes any, such as content from contributors or a CMS, and update soon.
- Build-only, flaw needs local misuse: batch it with normal upgrades.
Keep an exception note for anything you defer, with a date to revisit.
Install scripts are their own question
Build-only does not mean harmless at install time. Package install scripts run on the machine doing the install. The npm documentation describes lifecycle scripts, such as install and postinstall, that run during installation. For more on that risk see malicious postinstall scripts in npm packages.
Try it yourself
Open the reachability demo and compare the raw finding list with the list after reachability is applied. Look for findings that move from urgent to low once the vulnerable code path is shown to be unused.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans dependencies and applies reachability analysis, so a long advisory list can be sorted by whether the vulnerable code is actually called. You can try it on a repository with the free scan at gold.safeguard.sh/scan.
Quick check
Is a devDependency always safe to ignore?
No. It does not ship to visitors, but it runs in your build and can still be an entry point to your pipeline.
Can a build-only flaw end up affecting visitors?
Yes, if it lets an attacker change the generated output, for example by injecting script into pages during the build.
Sources
- npm Docs, scripts: https://docs.npmjs.com/cli/v10/using-npm/scripts
Last reviewed: 19 October 2026.
