You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A threat model is a named class of dataflow sources that can be enabled or disabled independently. Threat models allow you to control the set of dataflow sources that you want to consider unsafe. Threat models are defined in a hierarchy. A threat model can have child threat models, so that enabling or disabling the parent threat model does the same for each of its children.
302
+
A threat model is a named class of dataflow sources that can be enabled or disabled independently. Threat models allow you to control the set of dataflow sources that you want to consider unsafe. For example, one codebase may only consider remote HTTP requests to be tainted, whereas another may also consider data from local files to be unsafe. You can use threat models to ensure that the relevant taint sources are used in a CodeQL analysis.
303
303
304
-
The ``default`` threat model is included by default. The ``default`` grouping only contains one child threat model, the ``remote`` threat model, which represents remote HTTP requests.
305
-
306
-
You can extend the CodeQL threat model to specify other sources of untrusted data. For example, if your codebase considers local files to be sources of tainted data, you can specify the ``local`` threat model to be used in CodeQL analysis.
307
-
308
-
The shared ``threat-models`` library pack exposes the following extensible predicates:
309
-
310
-
- ``threatModelConfiguration(string kind, boolean enabled, int priority)``. This is used to configure which threat models are enabled or disabled for the analysis.
311
-
- ``threatModelGrouping(string kind, string group)``. This is used to define the taxonomy of threat models as a parent-child hierarchy.
312
-
313
-
You can specify a threat model to use during analysis by adding a data extension YAML file named ``<test-name>.ext.yml`` in your test directory. In the YAML file, you can extend the ``threatModelConfiguration`` predicate.
314
-
315
-
.. code-block:: yaml
316
-
317
-
extensions:
318
-
- addsTo:
319
-
pack: codeql/threat-models
320
-
extensible: threatModelConfiguration
321
-
data:
322
-
- [local, true, 0]
323
-
- [environment, false, 1]
324
-
325
-
Each data row consists of three columns:
326
-
327
-
- The first value ``local`` is the name of the threat model to enable or disable.
328
-
- The second value ``true`` is a boolean that you can set to ``true`` to enable the named threat model, or ``false`` to disable it.
329
-
- The third value ``0`` is an integer specifying the order in which to process the row. Rows are processed in ascending order of priority.
304
+
The ``kind`` property of the ``sourceModel`` determines which threat model a source is associated with. There are two main categories:
330
305
306
+
- ``remote`` which represents remote HTTP requests.
307
+
- ``local`` which represents data from local files (``file``), command-line arguments (``commandargs``), database reads (``database``), and environment variables(``environement``).
308
+
309
+
When running a CodeQL analysis, the ``remote`` threat model is included by default. You can optionally include other threat models as appropriate when using the CodeQL CLI and in GitHub code scanning. For more information see TODO.
0 commit comments