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

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

  1. I run jf audit --mvn=true --format=sarif > target/dependency-check-report.sarif as part of the pipeline to scan source code dependencies.

  2. The scan generates a SARIF file with CVEs.

  3. 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.

  4. I pass the SARIF file to SonarScanner using:

    -Dsonar.sarifReportPaths=target/updated-dependency-check-report.sarif
    
    
  5. I run:

    • Branch analysis for main / long‑lived branches

    • PR analysis using:

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

Observed behavior

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

  • :cross_mark: 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.

Hi,

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

 
Ann

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.

image

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:

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

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.

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

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

Hi Dilshan,

You’re right. Sorry I overlooked that.

I’ve flagged this for more expert eyes.

 
Ann

Hi,

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

Thanks

Dilshan

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?

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

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:

  1. 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?
  2. 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?