False Negative: Weak Algorithm Spec from Object changed Inter-procedurally is not reported

We ran SonarQube with Java to scan the following code snippet:

package com.minimals.Cipher.baseCaseInterProc;
import java.security.NoSuchAlgorithmException;

import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;

public class CipherExample {
    private String cipherName = "AES/GCM/NoPadding";

    public CipherExample methodA() {
        cipherName = "AES/GCM/NoPadding";
        return this;

    public CipherExample methodB() {
        cipherName = "DES";
         return this;

    public String getCipherName(){
        return cipherName;

    public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException {
        Cipher c = Cipher.getInstance(new CipherExample().methodA().methodB().getCipherName());


We scanned the source Java file using the docker. The command we used is:

sonar-scanner \
  -Dsonar.projectKey={PROJECT NAME} \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login={PROJECT KEY}

However, while it is possible to statically compute the value to be passed to Cipher.getInstance(), SonarQube does not report it.

Of course, SonarQube reports the issue when DES is used directly, such as:

Cipher c = Cipher.getInstance("DES");

in a similar source file.

Which is why I think it is a false negative.

Additional Details

Language: Java
Rule: java:S5547, java:S5542
Product Details:
SonarQube Community Edition Version - 9.6.1
Sonar Scanner Version - 4.7
Java Version - Java Eclipse Adoptium (64-bit)
Operating System - MacOS Monterey version 12.6


Thanks for this report!

SonarQube 9.6 is officially EOL. Can you upgrade to the Latest / current LTS: 9.9, and see if this is still replicable?

I know I’ve replied the same thing to two of your posts in a row, but we really do make strides with each release so we need to be sure this is still a problem in the current version first.


Hi Ann,

I can confirm that this problem still persists on SonarQube 9.9 and is replicable. Let me know if there is any other information you or the team may need.


1 Like

Hey @scttmars, thanks for the report but this one looks like it is a lot trickier to detect.

In this example, this use of a weak algorithm is easy to identify for simple human readers.
For our analyzer, this would require resorting to symbolic execution to follow through the program’s flow.
But because this kind of method is expensive, we typically reserve it for issues that cause bugs (such as NPEs) of user-explotiable vulnerabilities.

Since this issue is more of a misconfiguration on the developer’s side, trying to cover this type of case seems a bit out of scope.