By default the CycloneDX Maven plugin includes compile, provided, runtime and system scope dependencies and excludes test scope. That fits a shipped product SBOM, but provided and system scope need a second look, because they may not be packaged with your artifact.
The defaults
The plugin README lists these configuration defaults:
| Setting | Default |
|---|---|
| includeCompileScope | true |
| includeProvidedScope | true |
| includeRuntimeScope | true |
| includeSystemScope | true |
| includeTestScope | false |
Each flag maps to a Maven dependency scope, so you can turn any of them on or off.
What each scope means for an SBOM
A short definition of each, and the question it raises.
- Compile: needed to build and normally available at runtime. Include it.
- Runtime: not needed to compile, but needed to run. Include it.
- Provided: needed to compile, but supplied by the runtime environment, such as an application server. It is usually not packaged in your artifact. Including it records what you built against, not necessarily what you ship.
- System: like provided, but points at a file on the local machine. It is unusual and hard to reproduce, so treat any system scope entry as a flag for review.
- Test: only for running tests. Left out by default.
The provided scope is the one that matters most. If your artifact runs inside a container that supplies its own copy of a library, the SBOM entry for your build may name a version that differs from the one actually running. That is a gap between build time and runtime, and an SBOM from the build cannot close it alone.
How to choose
Ask what the file is for.
- A customer facing SBOM of the shipped artifact: keep the defaults, then review provided entries and decide whether to keep or remove them.
- An internal inventory of everything the build touches: also turn on test scope, so you know what runs on developer machines and in CI.
- An SBOM for a library that others will consume: consider whether provided dependencies are part of the contract you want to document.
The point is to decide deliberately. Defaults are reasonable starting points and are not a policy.
A comparison test
Generate once with defaults and once with test scope on, then diff the component lists. The extra entries are your test only dependencies. If any of them surprise you, such as a library you thought was strictly for tests, check how it is declared in the pom.
Do the same for provided: turn it off and see what drops. If a library drops that you know is packaged in the final jar, then its scope in the pom is probably wrong.
Multi-module builds
In a multi-module project, the aggregate goal combines dependencies from the whole build. The README describes flags to exclude modules, for example by excluding any module whose artifactId contains the word test, or by listing artifactIds or groupIds. Use these so that test helper modules do not appear in a shipped file.
After the SBOM exists
Scope settings affect which findings you see. A vulnerability in a test scope library is a different priority from one in a runtime library. Safeguard's reachability analysis helps with the next step, showing which vulnerable components your code actually calls, and a free scan lets you try it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive components are separated, then think about which scope each would carry.
Quick check
Why is test scope off by default?
Test dependencies are not part of the shipped artifact, so a product SBOM normally leaves them out. Turn it on for an internal build inventory.
Is a provided dependency part of my product?
Not necessarily. It is supplied by the runtime, so the version running may differ from the one you built against.
Sources
Last reviewed: 19 October 2026.
