Aim
The aim of this guide is to help you work out how to create the filters that are most useful to your project. It provides some best-practices, and gives examples of good and bad filters.
Filter creation best practices
Generally, having identified a call to the cryptography library that we do not want to appear in future results, we have to decide: is it just this call that we want to filter? Alternatively, are there a group of similar nearby calls? Or would we like to exclude the whole package? We then need to write a filter that removes the unwanted calls, but no others.
- Filters should be as specific as possible to avoid removing any calls other than those identified for filtering.
- Including both a fully-qualified class name and a method name will reduce the chances of accidentally removing other code.
- If you want to remove multiple methods from a class, consider adding multiple filters rather than filtering out the entire class.
- If you want to remove an entire module, make sure to use its fully-qualified name to avoid accidentally removing other modules.
- Note that filter terms are only applied as prefixes to the fully qualified class name. For example the filter “Does not contain
mypackage.MyClass
” won’t match (and so won’t exclude)org.mypackage.MyClass
. - While “Contains” filters can be useful to restrict your project to a certain package, “Does not contain” filters are often better for targeting specific portions of your code.
- Generally you should avoid applying “Does not contain” filters to inbuilt Java functions, as this is highly likely to obscure other valid results.
- To see which calls are being filtered after you change the filter settings (or at any time), click on “Show filtered” in the report Vulnerabilities tab.
Examples of Filters
- The filter “Does not contain
javax.crypto.Cipher
” is a bad filter, as it will remove all calls to ciphers from your reports. - The filter “Does not contain
toString
” is a bad filter, as it is highly likely to accidentally remove other calls. - The filter “Does not contain
org.myorg.mypackage.MyClass.myMethod
” is a good filter. It is very unlikely to start removing unintended calls.
Further Reading
For more information on how to create and remove filters, please see the support documentation for filters.