EDIT: From now on, EVERY single generic exception must be reported on both integrates and Asserts, so just keep recursively checking the entire repo and reporting all the occurrences. All special scenarios like having to use generic exceptions due to generic throws from third party dependencies or using generic exceptions after using specific exceptions must be either fixed or accepted by the client.
A few days ago we had a discussion on this topic.
Short answer: We are not reporting this specific scenario as a vulnerability in Integrates, hence, files reported by asserts that only have this case, should be taken out from the search pattern by using the exclude list param: https://fluidattacks.com/asserts/fluidasserts.lang.java/#fluidasserts.lang.java.has_generic_exceptions
Long answer: According to CWE-396 and CWE-397 this case DOES represent a vulnerability, as both throwing and catching generic exceptions generate lack of proper logging, even if some other specific exceptions were considered before. For security purposes, all possible exceptional scenarios should be considered and added. We decided not to report this case because never catching a generic exception represents an unrealistic situation for our clients, who: 1. often have to catch generic exceptions thrown by third-party componentes used in their apps and 2. will often not be up to allowing their app to fail every time a non-considered exception is found. As we don’t want this finding to be assumed right away due to the complexity of completely fixing it, we decided to skip this very specific scenario.