SonarScanner for Maven should auto-propagate -s settings.xml to the SCA internal process

Suggest new features
, ,
1

When using SonarQube Advanced Security with the SonarScanner for Maven and a private Maven repository (e.g. Artifactory, Nexus), users typically pass their custom settings.xml to the outer Maven command using the standard -s flag:

bash

mvn sonar:sonar -s /path/to/settings.xml

This works fine for the build itself — but the SCA engine spawns its own internal Maven process to resolve the dependency tree, and that process does not inherit the -s argument from the outer command.

As a result, the SCA analysis either fails to resolve dependencies or produces incomplete vulnerability results when those dependencies live in a private repository.

The current workaround is to duplicate the setting using the sonar.sca.mavenOptions property:

bash

mvn sonar:sonar \
  -s /path/to/settings.xml \
  -Dsonar.sca.mavenOptions="-s /path/to/settings.xml"

The proposal

The SonarScanner for Maven already has access to the -s (or --settings) argument the user provided. When launching the internal SCA Maven process, the scanner should automatically forward that value without requiring the user to repeat it manually via sonar.sca.mavenOptions.

In other words, if the user runs:

bash

mvn sonar:sonar -s /path/to/settings.xml

The internal SCA Maven invocation should behave as if -s /path/to/settings.xml was also passed to it — no extra configuration needed.

Why this makes sense

  • Principle of least surprise: a user who sets -s settings.xml reasonably expects the entire analysis — including SCA — to use that settings file. Having to know about a separate internal Maven process and configure it explicitly is a hidden trap.
  • The information is already there: the scanner knows which settings.xml was provided. Forwarding it is trivial compared to the debugging effort users currently go through.
  • It’s a common setup: private repositories are the norm in enterprise environments. This issue affects a large portion of Advanced Security users.
  • The workaround is error-prone: duplicating the path in two places means it can go out of sync, especially in CI/CD pipelines with dynamic paths or injected secrets.

Suggested behavior

Scenario Current behavior Proposed behavior
-s provided, sonar.sca.mavenOptions not set SCA uses default Maven settings → private deps not resolved SCA auto-inherits -s from the outer invocation
-s provided, sonar.sca.mavenOptions also set sonar.sca.mavenOptions takes effect (explicit override) Same — explicit value takes precedence
Neither set SCA uses default Maven settings No change

The explicit sonar.sca.mavenOptions should still take precedence when provided, so users retain full control if they need the SCA process to use a different settings file.

Impact

This change would eliminate a silent, hard-to-diagnose failure mode for any team using Advanced Security with a private Maven repository — which is a very common enterprise configuration.

Has anyone else hit this? And is this something the SonarQube team would consider addressing in the scanner?

4

Seems reasonable, we can take a look at this.