Include them only if you label them, and label them with scope. CycloneDX has a scope field on each component: required, optional or excluded. Test and build tools belong in excluded if you list them, so a reader does not mistake them for shipped code.
The three scope values
From the CycloneDX 1.7 JSON reference:
- required: the component is needed at runtime. This is the default if scope is not given.
- optional: the component may not be callable at runtime because it is not installed or is otherwise not reachable. The reference adds that installed components blocked only by configuration or restrictions must still be scoped as required.
- excluded: the component is documented for testing or other non runtime use, and is not reachable in a runtime call graph.
Why the default needs care
Because required is the default, a component with no scope is read as a runtime dependency. If your tool dumps dev dependencies with no scope, a reader will count a linter as shipped code and flag its vulnerabilities as production risk.
Should you list dev dependencies at all?
It depends on the question your SBOM answers.
- If the SBOM describes what you ship to customers, runtime components are the core. Build and test tooling is optional context.
- If the SBOM supports your own supply chain risk review, development tooling matters. A compromised build tool can affect what you ship even if it never runs in production.
State your choice. The 2026 CISA guidance, as reported, says there is no minimum depth, and it describes generation context as something that limits what an SBOM can claim. Telling readers whether dev tooling is included fits that spirit.
A decision guide
- Customer facing SBOM: list runtime dependencies as required. Add dev tools only if the customer asked, and mark them excluded.
- Internal SBOM: list everything, with scope set honestly.
- Unsure whether a component is reachable at runtime: do not mark it excluded. Use required, and consider reachability analysis to learn more.
- Always document the rule you applied in the cover note.
Scope is not the same as risk
An excluded component can still be dangerous to your pipeline. Scope describes runtime reachability, not whether it can harm your build.
Click through it at your own pace, or open it full screen.
Quick check
What does a missing scope mean?
Required. The reference says scope defaults to required.
Can I mark a config disabled library as excluded?
No. Installed components blocked only by configuration must be scoped as required.
Sources
Last reviewed: 19 October 2026.
