New issue raised on unchanged code after PR merge

SonarQube Cloud
, ,
1

ALM used: GitLab

CI system used: TeamCity

SonarQube edition: Developer Edition

Scanner used: SonarScanner for .NET 11.2

Languages: Mostly C#

Error observed:

Hi,

The develop branch was analyzed twice on the same day, the first analysis completed with no issues, but after a PR was merged (2 hours later), the second analysis reported a new S5145 issue

The strange part is that the reported line was not modified in the PR, according to git blame, that line hasn’t changed in about 4 months

We also checked that nothing changed between the two analyses:

SonarQube version (2026.1.3.123084)
Scanner for .NET version (11.2)
Analyzer versions (securitycsharpfrontend 11.15.0.42969 and csharpenterprise 10.18.0.131500)
Quality Profile and project configuration

The issue was created only during the second analysis.

Steps to reproduce: We haven’t been able to reproduce it consistently.

What happened was:

Analyze develop → no issues.
Merge a PR that doesn’t touch the affected file.
Analyze develop again.
A new issue is created on a line that wasn’t changed by the PR.

Has anyone seen this before, or is there any reason why SonarQube would create a new issue on unchanged code after a merge?

2

Hi @jvillalpando

Welcome to the Community! Thanks for the detailed information.

Looking at the rule involved, S5145 is a taint-analysis (dataflow) rule rather than a simple line-pattern check. The C# security engine traces data from an untrusted source all the
way through your call graph to the sink (the log call) across the whole analyzed solution, not just the single file.

Because of this, a finding can appear on a line whose text hasn’t changed at all if something upstream in the data-flow path changed. For example, a new/modified caller now passes untrusted input into that path, or a sanitizer/validation step elsewhere in the chain was altered or removed. Git blame on the flagged line won’t show this, since it only reflects when that line’s own text last changed, not when the data flow reaching it changed.

Does that make sense?

Best regards,

Stevan

3

Yes, that makes sense. Thank you so much for the explanation!