Dear Dorian_Burihabwa,
Thank you for the response!
SonarQube does not report any other warnings. All the warnings counts are 0, when we checked.
To provide more context about what I am about to ask, my team is conducting academic research on Java Cryptographic API-related misuse. As you and Leonardo_Pilastri mentioned, there are several design decisions and philosophies in SonarQube that results in the false negatives I reported:
- The analyzer avoids evaluating non-constant identifiers, even if they are statically determinable, which is motivated by,
- SonarQube’s priority to not raise FPs.
Based on these, we have the following questions:
- What factors motivated SonarQube to prioritize not raising FPs in this specific context, i.e., by not analyzing for non-constant identifiers?
- Do you prioritize not raising FP for all four Clean Code attributes (Quality, Security, Maintainability, and Reliability) equally, or are there variations? For example, in this case, you mentioned that analyzing non-constant identifiers may raise FPs, but it is still worth investigating to reduce false negatives. Is this somewhat of an exception because it is related to security?
- Are there any additional factors you consider when prioritizing the trade-off between FP and FN?
- What’s the threshold SonarQube aims for when it comes to maintaining the percentage of FP, if there is any (even if informally)?
Please let us know what you think. Thanks again for your very valuable insight!