Skip to main content

Query Language

Checkmarx IAST Query Language allows you to gather and analyze application run-time events and return a list of results. It also allows you to build custom queries in order to customize existing rules in order to search for new vulnerabilities.

IAST Query Language consists of the following two main segments:


List definition that includes the following types:

  • Source

  • Propagator

  • Sink

  • Single Method


Definition for how to query monitored events in order to find vulnerabilities. This logic is used in predefined lists and includes the following severities:

  • High

  • Medium

  • Low

  • Info

Each result found by IAST Query Language can be a single element executed during run-time (e.g., a method call) which is called ‘Single_Method’ or ‘Flow’ – a path of data monitored in application run-time consisting of an ordered list of method calls manipulating this data.

IAST Query Language starts to monitor flows when a special defined method called ‘Source’ receives data and until a special method called ‘Sink’ is executed on this data.

Between ‘Source’ and ‘Sink’ there may be methods calls ‘Propagators’ manipulating the data. Sanitizers are propagators which can be used to clear a flow from a security standpoint. Data being traced is of the ‘String’ type.


It is impossible to trace a complicated object as a single entity, but all primitive Strings of this object or its sub-objects can be traced. Not only Strings, but all connected types like String Builders, String Buffers, arrays of characters etc. can also be traced.

Each type contains a definition of the APIs needed to be monitored.

For each definition there is a name (e.g., Inputs, Outputs, DBs) and a list of included and excluded APIs. For example, Inputs contain the following:






It is possible to include and exclude other lists.

Even though Checkmarx supported lists are read-only, it is possible to override a Checkmarx lists to include and exclude custom APIs and even to create a new custom list.

Lists are building blocks of queries and queries use these list definitions in order to implement search logics.

The following is an example of a query:

CxList input = All.FindOnTraces(Inputs());

CxList commands = All.FindOnTraces(OsCommands());

CxList sanitizer = All.FindOnTraces(Replace()).FindByParameterValue(0, "&");

result = input.InfluencingOnAndNotSanitized(commands, sanitizer);

This query uses the following lists:

  • Inputs

  • OsCommand

  • Replace

CxList is the base type used by IAST Query Language. It contains a vast assortment of commands for mining run-time events. Because the return value of almost every command is also of type CxList, several commands can be executed consecutively. The return value of all queries is also CxList. It is important to note that most CxList methods return a subset of the original CxList (we can think of the method as a filter). For example, the first line of the query above, ‘CxList inputs = All.FindOnTraces(Inputs());’ takes as its input predefined variable ‘All’ which contains all events (traces) being monitored and returns a sub-list of traces which have calls to APIs defined in Inputs. The method ‘FindOnTraces’ enables us to get a definition of List and returns CxList of traces which have APIs defined in List called on these traces.

The predefined variable ‘result’ is used to return findings from a current query.

It is possible to override a query, when the first line of overridden query contains a call to Checkmarx query like ‘result = super.Sql_Injection();’ and it is possible to add custom logic to the overridden query. It's also possible to create a custom query, which can use both Checkmarx lists and Custom lists.

The following list contains CxList methods almost identical to CxSAST Query Language:

  • FindByParameterValue

  • InfluencingOn

  • InfluencedBy

  • InfluencingOnAndNotSanitized

  • InfluencedByAndNotSanitized

  • Add (+)

  • Remove (-)

  • Intersect (*)

  • IsEmpty

  • Count

It's important to note that IAST Query Language doesn't support operators like + and * on CxList, so ‘Add’ and ‘Intersect’ methods should be used instead. Count is not a field, but a method, so it should be used like: result.Count().

The following list contains CxList methods which don't exist in SAST since these methods are querying run-time data values:

  • FindSinkWithValue – returns a trace ended with a Sink which has a specific value

  • FindSinkWithoutValue – returns a trace ended with a Sink without a specific value

  • FindResponseWithHeader – returns all traces with a specific header in http response

  • FindResponseWithoutHeader – returns all traces without a specific header in http response

  • findOnResponseHeader – returns all traces with a header contains a specific value

  • FindOnTraces – gets a list name and return traces with APIs on these traces

  • ReturnUniqueTraceId – returns traces which are not sub-traces of other traces

  • ReturnCommonTraceId - returns traces which are sub-traces of other traces

  • FilterByTransferProtocol – returns traces from Cxlist which use a specified protocol

When writing a new query, it should be first understood which Sources, Sinks and Sanitizers should be used. Sometimes, it will be already defined, like Inputs, IO, Db, etc. If a query should use something special like a new unknown Sanitizer, a Propagator together with its API should be defined. For example, let's suppose that we need to use a Sanitizer called ‘MyLibrary.mySuperCleaner’ (format is CLASS.METHOD), then we need to define a new list under customer propagators and call it something like ‘SuperCleaners’. We then need to add ‘MyLibrary.mySuperCleaner’ to the Include section and save the changes. Only now we can start to write a new query and use this Sanitizer.

For a full list of vulnerabilities covered in this IAST version, please refer to the IAST Vulnerabilities section.