Yes, though differently from runtime dependencies. Documentation tools, bundlers and test runners do not load in your users' browsers, but they run on your build machines and write the files you publish. A compromised build tool can change the released package or reach CI credentials.
Two exposure paths
The artifact path. The bundler, transpiler and minifier produce your dist files. If one misbehaves, its output ships inside the library to every app.
The credential path. Dev dependencies run in CI, where publish tokens and registry credentials may be present. A malicious install script or tool plugin executes with whatever the job can access.
For general guidance on the dev versus runtime distinction, see do dev dependencies matter for supply chain security.
Where the line is, practically
| Tool | Ships to users | Runs with secrets | Priority |
|---|---|---|---|
| Bundler and compiler | Its output does | Often in release job | High |
| Storybook and docs site | No, if hosted separately | Sometimes, if deployed from CI | Medium |
| Test and visual runners | No | Rarely | Lower, but they gate releases |
| Linters and formatters | No | Rarely | Lower |
| Publish script and release tooling | Controls what is published | Yes | High |
Controls that fit a design system
- Separate the jobs. Run tests and builds without the publish token. Give only the final publish step access to it, ideally from a protected branch or tag.
- Pin and review tool updates. Update bots should treat bundler bumps as reviewed changes, not automerge. See which frontend dependency updates are safe to automerge.
- Use the lockfile in CI. An install that follows the committed lockfile reduces surprises compared with fresh resolution.
- Compare the artifact. Diff the published file list and bundle contents between releases. A new file or a large size jump deserves a look.
- Scan dev dependencies too, and rank findings by whether the tool touches the artifact or secrets.
The Storybook question
A documentation site is often deployed publicly and linked from internal tools. It rarely needs production data or credentials. Keep it that way: no real keys in stories, no copied production content, and a deploy token scoped to the docs host. If you use a hosted visual testing service, review what repository access you grant it.
What it does not mean
It does not mean every dev dependency advisory is urgent. A finding in a formatter that never sees untrusted input is usually low priority. Use the question: does this tool process untrusted input, hold secrets, or write the artifact? Related reading: should CI gate fail on dev dependency vulnerabilities.
Safeguard's dependency scanning and policies can cover dev dependencies and flag them separately from runtime ones, so you can set different rules for each. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is a dev dependency vulnerability in my library a risk to apps?
Not directly, since dev dependencies do not install for consumers. It becomes a risk if the tool shapes the artifact or runs with secrets.
Should the publish token be available to every CI job?
No. Limit it to the publish step.
Last reviewed: 19 October 2026.
