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.

Aniket Ambi

Hi Aniket,

What language are we talking about?


Hi Ann,
Applying on Java code.



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


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”);



Do you have in your dependencies this one?



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



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

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?



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.


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] ± 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


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.


Hi SonarQube Team,

Any progress on this issue? We also face it.


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.

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

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

Thank you

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