Yes, record them, but label each with a scope such as runtime, development or build. Dev and build dependencies often never reach customers, but they execute on developer laptops and in CI, so a compromised one can change what gets built.
The argument for leaving them out
Runtime dependencies decide what vulnerabilities a customer inherits. Mixing hundreds of test and lint packages into that list inflates counts and buries what matters. Many scanners and teams therefore report production dependencies only, and that is a reasonable default for a vulnerability view.
The argument for including them
An acquisition inventory has a second job: understanding how the software is made. The build is where code is assembled, signed and published. Tools and plugins in that path have access to source, tokens and release credentials.
The OpenSSF Scorecard reflects this concern. Its Pinned-Dependencies check looks at whether a project pins what it uses during build and release, in Dockerfiles, shell scripts and GitHub workflows, because mutable references there are a route to compromised dependencies.
The practical answer: scope labels
Keep one inventory with a scope field and let readers filter.
| Scope | Ships to customers | Runs in CI or dev | Typical use in diligence |
|---|---|---|---|
| Runtime | Yes | Yes | Vulnerability and license review |
| Development | No | Yes | Developer environment risk |
| Build | No | Yes | Build integrity and access review |
| Test only | No | Yes | Low priority, record for completeness |
What to ask the seller
- Are build plugins and CI actions pinned to a version or hash?
- Which of them can read release secrets?
- Does the build run on shared or ephemeral machines?
- Is there a list of tools developers install locally?
What to do if only runtime is provided
Accept it as the first pass, then request the build tool list separately. A short document naming the build system, plugin set and CI actions is often enough to start. Record the missing scope as a known gap, which is the practice the NTIA minimum elements report describes when it says unenumerated parts of the graph should be flagged as known unknowns rather than left silent.
Common mistakes
- Dropping dev dependencies entirely, then discovering a build plugin was the weak point.
- Mixing scopes without labels, so vulnerability counts look alarming and meaningless.
- Treating test packages as zero risk because they are not shipped.
Safeguard's dependency scanning and policies can keep scope visible and apply gates in pull requests. You can start with a free scan at gold.safeguard.sh/scan.
Quick check
Should dev dependencies count toward the vulnerability total?
Report them separately. Runtime findings describe customer exposure. Dev and build findings describe build and developer environment exposure.
Do build plugins count as dependencies?
Yes. They are third party code that runs during the build. List them with a build scope.
Sources
Last reviewed: 19 October 2026.
