diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 2eb9446459f4..f8f576b16b16 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -223,7 +223,7 @@ The first five values identify the function to be modeled as a summary. - The first value ``slices`` is the package name. - The second value ``""`` is left blank, since the function is not a method of a type. - The third value ``False`` is a flag that indicates whether or not the model also applies to subtypes. This has no effect for non-method functions. -- The fourth value ``Max`` is the function name. +- The fourth value ``Concat`` is the function name. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 203213b94255..608235636f16 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -63,8 +63,8 @@ The CodeQL library for Java and Kotlin analysis exposes the following extensible - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data maybe used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. -- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. -- ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingValue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. +- ``barrierModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(package, type, subtypes, name, signature, ext, input, acceptingValue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) override generated summary models (those with a provenance such as ``df-generated``) so that the summary will be ignored. Other than that, neutral models have a slight impact on the dataflow dispatch logic, which is out of scope for this documentation. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst index a0702289cefb..77ea678f5468 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst @@ -381,7 +381,7 @@ We need to add a tuple to the ``sourceModel(type, path, kind)`` extensible predi - The first column, ``"@example/middleware"``, begins the search at imports of the hypothetical NPM package ``@example/middleware``. - ``Member[injectData]`` selects accesses to the ``injectData`` member. - ``ReturnValue`` selects the return value of the call to ``injectData``. -- ``GuardedRouteHandler`` interprets the current value as a middleware function and selects all route handlers guarded by that middleware. Since the current value is passd to ``app.use()``, the callback subsequently passed to ``app.get()`` is seen as a guarded route handler. +- ``GuardedRouteHandler`` interprets the current value as a middleware function and selects all route handlers guarded by that middleware. Since the current value is passed to ``app.use()``, the callback subsequently passed to ``app.get()`` is seen as a guarded route handler. - ``Parameter[0]`` selects the first parameter of the callback (the parameter named ``req``). - ``Member[data]`` selects accesses to the ``data`` property of the ``req`` object. - Finally, the kind ``remote`` indicates that this is considered a source of remote flow. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index db041a521514..beccf82327f2 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -56,7 +56,7 @@ We need to add a tuple to the ``sinkModel(type, path, kind)`` extensible predica - The first column, ``"TTY::Command"``, identifies a set of values from which to begin the search for the sink. - The string ``"TTY::Command""`` means we start at the places where the codebase constructs instances of the class ``TTY::Command``. + The string ``"TTY::Command"`` means we start at the places where the codebase constructs instances of the class ``TTY::Command``. - The second column is an access path that is evaluated from left to right, starting at the values that were identified by the first column. - ``Method[run]`` selects calls to the ``run`` method of the ``TTY::Command`` class.