CodeQL incorrect documentation encourages vulnerable Cryptographic Java API Usage

Hi,

My team is conducting academic research on Java Cryptography API based misuse using your tool. We found that we could not detect some potential cryptographic misuses, as CodeQL (And LGTM) has incorrect documentation (and rule) that encourages Java cryptographic API misuse resulting in vulnerabilities.

In https://lgtm.com/rules/7870098/ and https://github.com/github/codeql/blob/main/java/ql/src/Security/CWE/CWE-327/BrokenCryptoAlgorithm.java, it is stated that "Using broken or weak cryptographic algorithms can allow an attacker to compromise security." and two examples are given, one using "DES", and the other using "AES".

However, in the case of SunJCE provider, the Cipher.getInstance("AES") and Cipher.getInstance("AES/ECB/PKCS5Padding") are equivalent as documented in Oracle's Java Cryptography Architecture (JCA) Reference Guide (https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-2BCFDD85-D533-4E6C-8CE9-29990DEB0190). Note that this is the default provider for many Java Developers.

ECB mode is considered insecure as this is vulnerable to simple attacks such as frequency analysis (https://rules.sonarsource.com/java/tag/cwe).

We also found that in the query file Encryption.ql for java, ECB mode is not mentioned under insecure algorithm names (
https://github.com/github/codeql/blob/768e5190a1c9d40a4acc7143c461c3b114e7fd59/java/ql/src/semmle/code/java/security/Encryption.qll#L95 )

All of these will result in developers being encouraged to use "AES" with "ECB" mode for encryption when they use LGTM/CodeQL, resulting in cryptographic vulnerabilities.