Usually the code you ship is firmly in scope, and the tools that build it are in scope through your change management and access controls. Dev dependencies are lower risk to customers but not zero risk, because they execute on developer machines and CI with access to credentials. Scope them by exposure, not by label.
Where scope really comes from
SOC 2 scope is set by the system you describe to the auditor: the services, infrastructure, software, people, procedures and data that deliver your product. If a component can affect the security of that system, it is relevant. The label in package.json does not decide that.
So the question is not "is it a devDependency" but "what can it touch."
Three buckets
| Bucket | Examples | Treatment |
|---|---|---|
| Ships to production | Runtime libraries, base image packages | Full vulnerability management and change review |
| Builds the product | Bundlers, test runners, CI actions, compilers | Change review, pinned versions, scanned on a lighter cadence |
| Local convenience | Linters, formatters, editor plugins | Covered by workstation and access controls |
The middle bucket gets overlooked. A malicious or compromised build plugin runs with your CI credentials and can alter the artifact. GitHub's guidance on CI notes that a compromised action can reach repository secrets, which shows why build time code deserves attention.
How to scan without drowning
Dev only packages generate many alerts that never reach production. Handle them with a separate, slower band in your policy, for example a monthly cycle, and say so in writing. Scanning them is cheap. Fixing every low severity alert on a test helper urgently is not worth the effort.
For npm projects, the audit command lets you scope its report. The npm documentation describes the command as sending your dependency list to the registry and requesting a report of known vulnerabilities, with notes that some issues need manual review. Check the current options for omitting dev dependencies when you want a production only view, and keep both views for the record.
Document the choice
Add a short paragraph to your vulnerability policy: production dependencies follow the main timeline, build and CI dependencies follow a defined secondary timeline, local tooling is covered by device controls. Then your scoping is a decision on paper rather than an accident.
Edge cases
- Serverless or edge bundles. Anything bundled into deployed code is production, regardless of label.
- Test fixtures that touch real data. Treat the tooling as in scope.
- Dev containers and shared images. If many engineers pull one image, it is a supply chain component. Pin and scan it.
Try it yourself
Open the demo and look at how an inventory separates components by type and origin. See which entries you would put in each bucket.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning inventory manifests and lockfiles, and its policies can apply different rules to different parts of a project. Free scan: https://gold.safeguard.sh/scan.
Quick check
Can I exclude dev dependencies from SOC 2 entirely?
Not safely by label alone. Exclude only what cannot touch your system, and document why. Build and CI tools usually can.
Should dev alerts follow the same SLA?
Not necessarily. A separate, slower band is reasonable if it is written in policy and followed.
Sources
- npm Docs, npm audit
- GitHub Docs, Security hardening for GitHub Actions
- AICPA and CIMA, SOC suite of services
Last reviewed: 19 October 2026.
