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

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

Hi Aniket,

What language are we talking about?

 
Ann

Hi Ann,
Applying on Java code.

Thanks,
Aniket

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

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

factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
Transformer transformer = factory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, “yes”);

Thanks,
Aniket

Hello,

Do you have in your dependencies this one?

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

Thanks

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

Thanks,
Aniket

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(...).

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

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

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

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

Hi SonarQube Team,

Any progress on this issue? We also face it.

Regards
Patrick

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.