Identify framework/IDE defaults. A default rule set is usually written in order to identify simple issues (low hanging fruit, so to say). It also identifies other issues that may be generic in nature across multiple platforms and frameworks. Having said that, this gives way to a lot of false positives during the scanning process. These false positives might seem like legitimate issues, but in practicality are not. For example, there might be a simple rule to look for a “TODO” keyword in all of the code files. Modern frameworks and IDEs often annotate new methods with these kind of comments. This helps the developer easily refer back and provide contextual information. As a result, a tool-based review produces many instances of the TODO keyword. These instances may not always be relevant or produce an attack surface.
One way to reduce such noise from the review results is to customize the rules. This ensures that the tool only provides results for relevant rules.
Enterprise-oriented rules. Most organizations have their own home-grown frameworks or libraries that take care of the typical functions. These include input validation, database connections, and SQL statement creation. In such cases, default rules that come along with the tool may not be entirely relevant. They may need some customization to identify the right issues and to leave out false positives.
Provide consistent guidance. Any large or medium-sized organization can be expected to have a few hundred developers working on various platforms and languages. Customization may not just be restricted to the rules for scanning but also for the guidance that is provided by the results generated to the end users. For example, internal references are beneficial. They help keep the source code consistent across the entire organization and make it easily adoptable for other developers.