Hello,
we are running SQ v10.5.1 deployed as a VM and initiating the scan via mvn org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121
We have a java file with some functions inside, one of the functions has an issue that is already flagged in the “Overall code” and we don’t object the issue is there.
A developer opens a side branch and adds one import and an annotation (Spring boot annotation to tack time for performance analysis) to the function with the issue .
The only modifications to that file are the import and the annotation being added:
Import <>.measurement.TrackExecutionTime;
@ TrackExecutionTime
Once the SQ scan runs in the side branch (new code discovery method being used is reference branch to the default branch) it flags the analysis as failed due to the issue that is present inside the function and it is already in the Old code.
We would like to know what is the logic behind this being detected and how a developer can avoid being blocked by introducing an annotation?
If it is relevant the issue detected is:
Change this code to not perform redirects based on user-controlled data.
HTTP request redirections should not be open to forging attacks[javasecurity:S5146]
Pull request analysis raises issue on code that was changed in the pull request. So I’d like to see what’s marked new in the PR versus where this issue is raised. Because editing lines where issues were already raised (without fixing those issues) will end up putting those old issues into scope for the PR analysis.
Hi,
thank you for replying and sorry for the delayed answer but I was wasn’t around last week.
Unfortunately I cannot share the code but I can confirm that SQ properly detects that in the respective file there are only 2 new lines (new code) and those 2 lines are indeed what the developer added: the import at the beginning of the file and the annotation to the function.
The old issue that is being detected as part of the new scan is inside the body of the function which does not contain any new code.
I would still like to see where the issue is raised relative to the new code. Feel free to redact what you need to. I’m looking for where the issue is raised, and the new code markings.
Hi,
I have managed to reproduce it in a side branch so I can better visualize it.
This is the QG failing on a side branch scan, as seen on the SS we are using “New Code:
Compared to master”
The structure of the file is 1 class with 2 methods inside the class, the new code annotation is applied to the 2nd method of the class and the “old” issue is part of the very same method being annotated.
Hopefully this brings more context to the issue I`m trying to clarify. Now back to the question:
What is the decision making on bringing up an old issue when the lines are no touched and only the method is annotated?
I wanted to see the issue in context to see if it was related to the method declaration (even if not on the annotation line). Because in a PR analysis context, only issues on changed lines should be shown. But you’re not in a PR context, are you? You said “branch”. So you’ll see all issues, even ones raised on old lines.
So the question is why this new issue is raised on old code. For that, this guide may help.
