How to Create Good Filters for your Project

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.