Describe the bug
A clear and concise description of what the bug is.

Hello,

I found a suboptimal pattern in java/ecb-cipher that limits constant propagation.
I think this is a misuse, and there may be other instances, so I report it here.

Currently, $MODE matches the entire string literal expression, including quotation marks (e.g., "AES/ECB/NoPadding" rather than just AES/ECB/NoPadding).

  patterns:
  - pattern: |
      Cipher $VAR = $CIPHER.getInstance($MODE);
  - metavariable-regex:
      metavariable: $MODE
      regex: .*ECB.*

While the regex .*ECB.* happens to catch both cases, this approach fails when the algorithm is stored in a variable:

# CASE 1
String algo = "AES/ECB/NoPadding";
Cipher c = Cipher.getInstance(algo);

In this case, $MODE binds to the identifier algo instead of the string content, causing the match to fail despite the code being vulnerable.

To properly leverage Semgrep's constant propagation, the pattern should explicitly match string literals by quoting the metavariable:

Cipher $VAR = $CIPHER.getInstance("$MODE");

With this change, $MODE captures the raw string content (e.g., AES/ECB/NoPadding), enabling constant propagation to resolve variables assigned to string literals and correctly identify the ECB vulnerability.

PS: I also found some rule-specific false positives and false negatives in this rule:

1. In Java, Cipher.getInstance('AES') defaults to AES/ECB/PKCS5Padding, leading to false negatives.
   For reference: https://googlesamples.github.io/android-custom-lint-rules/checks/GetInstance.md.html

# CASE2
Cipher c = Cipher.getInstance("AES"); # FN

2. RSA with ECB is actually safe (\eg~rsa/ecb/oaeppadding), but the rule will report it, leading to a false positive.

# CASE 3
Cipher c = Cipher.getInstance("RSA/ECB/OAEPPadding"); # FP

What is the priority of the bug to you?

• P0: blocking your adoption of Semgrep or workflow
• P1: important to fix or quite annoying
• P2: regular bug that should get fixed