Yes, but they matter differently. Compile and runtime dependencies ship with your application, so findings there are your risk. Test scope never reaches production, so findings are lower priority. Provided scope is supplied by a container, so the container's version decides your exposure, not your POM.
Definition: what a Maven scope does
Maven describes scope as a way to limit the transitivity of a dependency and to decide when it is included in a classpath. Every dependency has one, and compile is the default.
| Scope | On which classpaths | Passed on to consumers? |
|---|---|---|
| compile | compile, runtime, test | Yes |
| provided | compile, test (not runtime) | No, not transitive |
| runtime | runtime, test (not compile) | Through the dependency graph |
| test | test only | No, not transitive |
| system | Local jar at a given path, not recommended | Not stated |
The Maven guide describes provided as something you expect the JDK or a container to supply at runtime, and test as available only for test compilation and execution.
How to read a finding by scope
Compile and runtime. These are in the packaged application. A vulnerable version here needs a decision: upgrade, constrain, exclude or accept with a reason.
Test. A flaw in a test library can still matter on a build machine, since tests run code with the privileges of your CI job. It rarely matters to your customers. Rank it below shipped code, but do not hide it.
Provided. Your POM names a version only for compilation. At runtime the application server or servlet container brings its own copy. The question to ask is which version the deployed container actually has. A clean POM can sit on top of an old container.
System. Maven does not download these from a repository. It reads a jar from a local path, which means a scanner reading coordinates may miss it entirely. Treat each one as a manual inventory item.
Steps to triage a scan by scope
- Export the dependency tree with scope shown. In Maven,
mvn dependency:treeprints it. - Filter findings to compile and runtime first.
- For provided findings, record the container version in your asset inventory and check it separately.
- For test findings, batch them into routine upgrades.
- For every system scope entry, find out where that jar came from.
Many scanners flatten scope away. If yours does, you lose the cheapest prioritisation signal you have.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component and look at how it entered the project. Direct and transitive entries need different fixes.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning for Java projects, with reachability analysis to separate code your application can call from code that is only present. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a test scope vulnerability safe to ignore?
Not always. It will not ship, but tests run on developer and CI machines. Lower the priority and fix it in routine upgrades.
Does a provided dependency count as my vulnerability?
It counts as your exposure only if the deployed container carries the vulnerable version. Check the container, not just the POM.
Sources
Last reviewed: 19 October 2026.
