External dependency vulnerabilities (SARIF) appear in branch analysis but not in PR analysis

Dilshan_Peiris · April 15, 2026, 10:23am

Hi,

I’m trying to understand the behavior difference between branch analysis and pull request (PR) analysis when importing dependency vulnerability reports.

Setup

SonarQube Server: 2026.1
Edition: Developer Edition
Mode: MQR
Scanner: sonar-scanner
CI: Concourse
Dependency scanning: JFrog (jf audit)
Report format: SARIF

What I’m doing

I run jf audit --mvn=true --format=sarif > target/dependency-check-report.sarif as part of the pipeline to scan source code dependencies.
The scan generates a SARIF file with CVEs.
Use a script to post‑process the generated SARIF file and make it compliant with SonarQube’s supported SARIF format before running the SonarScanner analysis.

I pass the SARIF file to SonarScanner using:

-Dsonar.sarifReportPaths=target/updated-dependency-check-report.sarif

I run:

Branch analysis for main / long‑lived branches

PR analysis using:

-Dsonar.pullrequest.key
-Dsonar.pullrequest.branch
-Dsonar.pullrequest.base

Observed behavior

Branch analysis imports the SARIF file successfully and the dependency vulnerabilities appear in SonarQube.

image1740×808 99.8 KB
PR analysis does not show any dependency vulnerabilities at all (no issues in PR decoration, no dependency‑related issues visible).

There are no errors in the scanner logs; the SARIF file is detected, but the issues simply don’t appear in the PR.

Question

Why does SonarQube allow importing dependency vulnerabilities (via SARIF) in branch analysis, but not show them in pull request analysis, even though the same scanner configuration is used?

Is this:

An expected limitation of PR analysis?
A restriction related to external issues / SARIF in PRs?

Expectation

I’m not trying to use Sonar’s built‑in SCA (I understand that requires Enterprise + Advanced Security).
I’m simply trying to understand why external dependency vulnerabilities can be visible on branches but cannot be surfaced in PR analysis, and whether that is a design decision or a documented limitation.

Any clarification from the Sonar team would be appreciated.

Thanks in advance.

ganncamp · April 16, 2026, 2:26pm

Hi,

PR analysis only raises issues on files that changed in the PR. Did the file in question change in the PR?

Ann

Dilshan_Peiris · April 17, 2026, 8:16am

Yes. I added the following dependency to the pom.xml file:

<dependency>
    <groupId>commons-collections</groupId>
    <artifactId>commons-collections</artifactId>
    <version>3.2.1</version>
</dependency>

And able to detect the vulnerable dependency in jf audit in build step in the pipeline.

Then, I tried running the Sonar Scanner command as shown below and tried only with -Dsonar.sources=src/main/java as well. but no luck.

      sonar-scanner \
        -Dsonar.host.url=((SONAR_URL)) \
        -Dsonar.login=((SONAR_AUTH_TOKEN)) \
        -Dsonar.projectKey=((SONAR_PREFIX)):((build-application)) \
        -Dsonar.projectName=((build-application)) \
        -Dsonar.projectVersion="${MVN_VERSION}" \
        -Dsonar.pullrequest.key="${PR_ID}" \
        -Dsonar.pullrequest.branch="${PR_SOURCE_BRANCH}" \
        -Dsonar.pullrequest.base="${PR_TARGET_BRANCH}" \
        -Dsonar.projectBaseDir=. \
        -Dsonar.sources=src/main/java,pom.xml \
        -Dsonar.sourceEncoding=UTF-8 \
        -Dsonar.sarifReportPaths=target/updated-dependency-check-report.sarif \
        -Dsonar.java.binaries=target/classes \
        -Dsonar.java.libraries=target/dependency/*.jar \
        -Dsonar.java.source=11 \
        -Dsonar.scm.provider=git \
        -Dsonar.coverage.exclusions="${SONAR_COVERAGE_EXCLUSIONS}"

Here is the source code folder structure:

ganncamp · April 17, 2026, 2:14pm

Hi,

Thanks for this run-down. The last commit date on your pom is from last July. I guess this isn’t a screenshot of your actual branch?

And does your pom show up as ‘new’ in your PR?

I was about to ask you to set sonar.maven.scanAll to true rather than explicitly specifying sonar.sources when I realized which scanner you’re using. Can you share why you’re analyzing with sonar-scanner instead of SonarScanner for Maven?

Ann

Dilshan_Peiris · April 20, 2026, 8:36am

Sorry, screenshot was from master branch and here is the actual branch (source branch).

I set sonar.sources=src/main/java,pom.xml it was able to pick pom.xml when I checked in SonarQube

And also I tried sonar.maven.scanAll=true as below and it was unable to pick pom.xml when I checked in SonarQube

      sonar-scanner \
        -Dsonar.host.url=((SONAR_URL)) \
        -Dsonar.login=((SONAR_AUTH_TOKEN)) \
        -Dsonar.projectKey=((SONAR_PREFIX)):((build-application)) \
        -Dsonar.projectName=((build-application)) \
        -Dsonar.projectVersion="${MVN_VERSION}" \
        -Dsonar.pullrequest.key="${PR_ID}" \
        -Dsonar.pullrequest.branch="${PR_SOURCE_BRANCH}" \
        -Dsonar.pullrequest.base="${PR_TARGET_BRANCH}" \
        -Dsonar.projectBaseDir=. \
        -Dsonar.maven.scanAll=true \
        -Dsonar.sourceEncoding=UTF-8 \
        -Dsonar.sarifReportPaths=target/updated-dependency-check-report.sarif \
        -Dsonar.java.binaries=target/classes \
        -Dsonar.java.libraries=target/dependency/*.jar \
        -Dsonar.java.source=11 \
        -Dsonar.scm.provider=git \
        -Dsonar.coverage.exclusions="${SONAR_COVERAGE_EXCLUSIONS}"

We are using emeraldsquad/sonar-scanner docker image in this concourse task. There is no special reason why we are using sonar-scanner instead of SonarScanner for Maven.

ganncamp · April 20, 2026, 11:50am

Hi,

That’s to be expected. That property only works with SonarScanner for Maven.

Does the pom file show up as new in the PR? And did the dependencies show up?

Also is the PR’s target branch analyzed?

Thx,
Ann

Dilshan_Peiris · April 20, 2026, 12:53pm

Hi,

Yes, pom file show up as new in the PR. I have already provided the screenshot of it in the previous reply. And it shows the new line count as 8. But did not show up the dependency.

And PR’s target branch was already analyzed with another pipeline we used for branch analysis. And dependency scanning works fine there.

Thanks,

Dilshan

ganncamp · April 20, 2026, 3:21pm

Hi Dilshan,

You’re right. Sorry I overlooked that.

I’ve flagged this for more expert eyes.

Ann

Dilshan_Peiris · April 20, 2026, 3:26pm

Hi,

Thank you very much for your time and effort on this. Looking forward to get some more inputs from experts.

Thanks

Dilshan

Dilshan_Peiris · April 22, 2026, 12:11pm

Hi,

@ganncamp

I tried using SonarScanner for Maven & still the issue persists. Also can see below in pipeline output (Branch Analysis has 41 vulnerabilities and PR Analysis has 42 vulnerabilities).

[DEBUG] 11:36:02.638 Sensors : Import external issues report from SARIF file. -> JavaProjectSensor -> JavaArchitectureSensor -> Zero Coverage Sensor -> Java CPD Block Indexer
[INFO] 11:36:02.638 Sensor Import external issues report from SARIF file.
[DEBUG] 11:36:02.638 Importing SARIF issues from 'target/updated-dependency-check-report.sarif'
[INFO] 11:36:02.872 File target/updated-dependency-check-report.sarif: 1 run(s) successfully imported (42 vulnerabilities in total).
[INFO] 11:36:02.873 Sensor Import external issues report from SARIF file. (done) | time=235ms

Further I checked on SonarQube server logs and able to see below in ce.log while executing the SonarScanner command.

2026.04.22 13:36:05 INFO  ce[d12a44b9-6734-4a14-b4c3-61bb0afd1e30][o.s.c.t.s.ComputationStepExecutor] Software composition analysis unavailable | status=SUCCESS | time=0ms

“SCA and Advanced SAST with Advanced Security” is unavailable in SonarQube Developer edition and in Enterprise edition also it come up as an add on. Can this be the problem that we are facing?

ganncamp · April 22, 2026, 12:20pm

Hi,

No. By your own reports, it works sometimes:

The feature you don’t have in Developer Edition is us finding SCA issues, not us showing you the issues you found.

Ann

antoine.vinot · May 22, 2026, 2:11pm

Hi @Dilshan_Peiris,

Thank you for bearing with us on this.

In a PR, SonarQube only shows issues on the new code of the PR. So an imported finding may be hidden, depending on where exactly the finding is anchored. A SARIF result with no region, or a region that doesn’t land on any of your 8 added lines, is a likely cause.

Two things would help confirm:

Could you paste one of the findings from your post-processed updated-dependency-check-report.sarif? Specifically a results[] entry with its locations[0].physicalLocation block, so we can see what region, if any, the imported issues carry?
On the branch view, could you open one of the vulnerabilities that’s missing from the PR and check whether it shows a line number on pom.xml, or whether it’s anchored to the file with no line?

Topic		Replies	Views
External reports not showing issues for Pull Request analysis but working for branch analysis SonarQube Server / Community Build coverage	3	175	January 27, 2025
Need help with pull request decorating view SonarQube Server / Community Build sonarqube , gitlab , pull-request	8	2100	October 5, 2020
SARIF import not working for pull request analysis only for master SonarQube Server / Community Build scanner , sarif	3	113	August 27, 2024
Pull request analysis of Java (maven) project does not generate analysis report in Sonar SonarQube Server / Community Build java , sonarqube , coverage	3	69	May 21, 2026
Pull request analysis sometimes doesn't flag issues Report False-positive / False-negative... java , sonarqube , pull-request	21	337	September 9, 2024