SonarQube: 7.7 :Issue is already fixed as per Sonar compliant solution but Sonar still reporting the issues

SonarQube
1

Please find below details for 3 vulnerabilities which is found in sonar 7.7 release but not in sonar 7.6 release.

Here 3 vulnerabilities root cause is same ‘ “Transformer" by either disabling external DTDs or enabling secure processing” ’

As sonar suggested compliant solution which is already implemented in our code But sonar still giving the same issues in Sonar Report.

Thanks,
Aniket Ambi

2

Hi Aniket,

What language are we talking about?

 
Ann

3

Hi Ann,
Applying on Java code.

Thanks,
Aniket

4

Hello,

Can you share a reproducer so we can analyze it on our side and try to understand the root cause of this false-positive?

Thanks

5

Hello,
Here is the details,
I have attached one Screen shot with details.
PFB code,
TransformerFactory factory = TransformerFactory.newInstance();

7
Sonar7.7.png1594×690 52.6 KB
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, “yes”);

Thanks,
Aniket

6

Hello,

Do you have in your dependencies this one?

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
        </dependency>

Thanks

7

Hello,
No, we dose not have this or any hibernate related dependency in my project.

Thanks,
Aniket

8

Hello,

We managed to reproduce and better understand the problem: it is linked to a classpath order problem.
You probably have in your dependencies a JAR (which itself can contain another JAR) containing another implementation of javax.xml.transform.TransformerFactory different from the JDK, which does not contain any declaration of a setFeature(...) method. During the scan, the Scanner is relying on this “wrong” version of TransformerFactory and fail to determine that you are correctly calling setFeature(...) method because there is no setFeature(...).

9

Hello,
Many thanks for looking into problem.
I tried to search in my application Jar’s for another implementation of TransformerFactory, but we have only one implementation used, which is of Java(x) only.

Do you suggest any workaround for the issue?
Is Sonar Team will fix this Bug?

Thanks,
Aniket

10

Hello,

Can you share the dependency tree of your project (hide all JARs that are private ones) ?

For the moment, we don’t have a workaround and I confirm we want to find a solution.

Alex

11

Hello Alex,
Here is the dependency tree: It dose not contain any internal Jar.
[INFO] — maven-dependency-plugin:3.0.2:tree (default-cli) @ cmsimulator —
[INFO]
[INFO] ± com.fasterxml.jackson.core:jackson-databind:jar:2.9.6:compile
[INFO] | ± com.fasterxml.jackson.core:jackson-annotations:jar:2.9.0:compile
[INFO] | - com.fasterxml.jackson.core:jackson-core:jar:2.9.6:compile
[INFO] ± commons-lang:commons-lang:jar:2.2:compile
[INFO] ± log4j:log4j:jar:1.2.17:compile
[INFO] ± org.quartz-scheduler:quartz:jar:2.3.0:compile
[INFO] | ± com.mchange:mchange-commons-java:jar:0.2.11:compile
[INFO] | - org.slf4j:slf4j-api:jar:1.7.25:compile
[INFO] ± com.opencsv:opencsv:jar:4.1:compile
[INFO] | ± org.apache.commons:commons-lang3:jar:3.7:compile
[INFO] | ± org.apache.commons:commons-text:jar:1.1:compile
[INFO] | - commons-beanutils:commons-beanutils:jar:1.9.3:compile
[INFO] | ± commons-logging:commons-logging:jar:1.2:compile
[INFO] | - commons-collections:commons-collections:jar:3.2.2:compile
[INFO] ± org.apache.commons:commons-compress:jar:1.5:compile
[INFO] | - org.tukaani:xz:jar:1.2:compile
[INFO] ± commons-io:commons-io:jar:2.4:compile
[INFO] ± org.apache.poi:poi:jar:3.17:compile
[INFO] | ± commons-codec:commons-codec:jar:1.11:compile
[INFO] | - org.apache.commons:commons-collections4:jar:4.1:compile
[INFO] ± org.apache.poi:poi-ooxml:jar:3.17:compile
[INFO] | ± org.apache.poi:poi-ooxml-schemas:jar:3.17:compile
[INFO] | | - org.apache.xmlbeans:xmlbeans:jar:2.6.0:compile
[INFO] | | - stax:stax-api:jar:1.0.1:compile
[INFO] | - com.github.virtuald:curvesapi:jar:1.04:compile
[INFO] ± org.apache.ant:ant:jar:1.9.4:compile
[INFO] | - org.apache.ant:ant-launcher:jar:1.9.4:compile
[INFO] - junit:junit:jar:4.12:test
[INFO] - org.hamcrest:hamcrest-core:jar:1.3:test

Thanks,
Aniket

12

Hi Team,

I’m also facing the same issue in java language code.
we are using jdk1.8.0_66.
Please help us to resolve it.

Thanks,
Manoj

14

Hi SonarQube Team,

Any progress on this issue? We also face it.

Regards
Patrick

15

Hi, @pmjroth This is an issue with how SonarJava handles conflict in the classpath of the analysis and more particularly between classes that are defined in JDK and in a dependency.
This is not a simple issue as a fix here can lead to the same issue but “reversed” elsewhere. We are aware of the issue and currently discussing a solution.
This is clearly an important matter to us and should be addressed in the upcoming releases of SonarJava.
In the meantime you can mark issues as false positives.

Thanks for the feedback.

16

I’m facing the same issue here. Any news on the discussion of the solution?

17

Hello,
I have the same issue.
How can we get sonar to see the right dependency ?

Thank you
Aurélie

19

I’m closing this topic due to lack of traction, and since it contains outdated information.

For the record, this issue was probably related to SONARJAVA-3056, SONARJAVA-3192 and SLI-384.

If you are still facing a similar problem, feel free to create a new topic, with up to date description of your problem (and potentially a link to this topic).

Thanks