1.4.3. Migration to 7.11.6¶
1.4.3.1. Stylechecks¶
Default behavior of rules utilizing taint analysis¶
Taint analysis identifies flows of data originating from particular code locations of interest, called sources, that reach particular (other) code locations, called sinks, that should not be reached from these sources without being sanitized, that is, checked for validity or modified such that the flow is no longer sensitive. As an example, a routine that returns the password a user typed in at a password prompt may be considered a source, writing to a database may be considered a sink and proper password hashing may be considered as sanitizer.
Prior to this release, the logic for deciding which locations are to be considered sources and sinks was defective such that way too many locations could be considered sources or sinks. The following rules were affected:
FaultDetection-TaintAnalysis
CWE-20
CWE-22
CWE-23
CWE-78
CWE-79
CWE-89
CWE-134
CWE-200
CWE-400
CWE-464
CWE-502
CWE-606
CWE-789
MisraC2012Directive-4.14
To address this issue, we introduced new options all_external_functions_as_sources and all_external_functions_as_sources to all of these rules and provided sensible defaults to them. In case they are enabled, non-excluded external functions are considered as sources (sinks), where “external” means “declaration-only within the IR or declared in a system header”. We have implemented reasonable default exclusions, but further exclusions may be configured in the external_source and sinks options of these rules.
Due to these changes, with this release you may initially get substantially more false-positive findings with the aforementioned rules when more locations are spuriously considered as default sources/sinks. In that case, you should add these locations/routines as exclusions. In case you feel that an exclusion is universal (such as a library function that may never produce tainted data) please contact our support so that we can assess your exclusion proposal and implement it internally.