Regulating issue creation is the process where you decide which findings to persist as issues and how to prioritize those issues. You regulate issue creation using filtering policies.
A filtering policy operates on all findings that match a specified two-part pattern, for example, the set of findings located in the path src/main/c/lib whose compliance type is defined by "MISRA C 2012".
Notice that the pattern consists of two sub-patterns, a Path Pattern and a Compliance Pattern. The Path Pattern (src/main/c/lib, in our example) specifies which findings the policy operates on according to the location of the source files that contain the findings. The Compliance Pattern ("MISRA C 2012", in our example) specifies which findings the policy operates on according to the compliance type of the findings.
A filtering policy can have one or both of its sub-patterns specified. An unspecified sub-pattern matches all findings. A filtering policy matches a finding only if both its sub-patterns match the finding.
The filtering policy operates on findings by either including them or excluding them. Included findings are persisted as issues on commit; excluded findings are not persisted.
Coverity Compliance Filtering provides two types of filtering policies:
Blocking policies – use these to exclude findings that are unimportant and that should be ignored (such as findings in third-party or generated code).
Scoring policies – use these to score findings according to their level of priority (findings with a higher score are deemed higher priority). Findings whose score meets the threshold setting are persisted as issues; those below the threshold are excluded. You can view issue scores in Coverity Connect.
If a finding matches both a blocking and scoring policy, the blocking policy takes precedence.