Summary

New CodeQL threat model settings will allow security-minded users to configure additional local sources of taint to use in code scanning if required by their codebase. The first language to support this functionality in CodeQL will be Java.

Intended Outcome

No two codebases are the same and each has a different threat model, depending on it has been designed and how it's deployed. For example, one codebase might only consider remote HTTP requests tainted to be potentially untrusted, whereas another might also consider local files to be a source of tainted user data. CodeQL can perform security analysis on all such codebases, but it needs to behave slightly differently in each case. If we fail to include types of taint source that are relevant to a codebase, then we may miss important results (false negatives). Conversely, if we include types of taint source that are irrelevant, then we may generate too many results (false positives).

How will it work?

With CodeQL threat model settings, code scanning users will be able to configure which types of tainted data to use in code scanning in the UI. CodeQL CLI users will be able to specify threat model settings on the command line.