Skip to main content

XML Document Structure

The structure of an XML document that contains a pattern must include the following elements:

  • Rules root element contains several Rule elements.
  • Rule element specifies a set of methods to search vulnerabilities of a certain type. Each Rule element contains RuleId and Patterns elements.
  • RuleId element contains a unique identifier reflecting the logic of a rule, for example, CRYPTO_KEY_SIZE (encryption key is too short).
  • Patterns element contains one or more Pattern elements.
  • Pattern element describes a vulnerability search method for a specific subset of cases. As a result, if several cryptographic libraries are used to implement encryption methods, each pattern included in the CRYPTO_KEY_SIZE rule specifies a method to search this particular vulnerability for one library or several similar libraries. To facilitate the debugging process, each Pattern element has a patternId attribute, which is a unique six-character alphanumerical [0-9, a-f] identifier of this pattern.

A Pattern element contains sub-elements from one of the following two sets:

  • Categories, Severity, Definitions, Condition, ChangeFlags

  • ReportValues, Categories, Severity, XPath

  • Categories element contains one or more Category elements.

  • Category element defines an app class to which this certain pattern belongs and may have one of the following values: JavaWeb (Java, Scala or Kotlin web apps), Android (mobile apps), PASCAL, PHP, CS, JS, LotusScript, TS, VBS, HTML5, Python, Perl, CCPP, ObjectiveC, Swift, PLSQL, TSQL, ABAP, 1C, APEX, GO, RUBY, RUST, Groovy, Dart, DELPHI, VBA, VB6, Solidity, Vyper, or COBOL. Patterns relating to only one app class are not used to analyze another class app, thus reducing the duration of analysis.

  • Severity element shows vulnerability severity on a scale from 1 (low) to 3 (high). One rule may include patterns with different severity levels.

  • Definitions element identifies entities that are involved in defining the pattern. Such entities may be: class (Class element), method (Method element), and method call with specific argument values and flags (Instruction element). You can specify class and method names (either explicitly or by regular expression). Moreover, you can also specify a signature (number and types of parameters, as well as in a fuzzy way by using WildCard elements) for a method, and actual argument and flag values for an instruction.

  • Condition element defines the insecure language construct, which is usually specified in terms of entities defined in Definitions. A Condition element contains one or more elements from the following: ClassCondition, MethodCondition, InstructionCondition, CatchBlockCondition, VariableCondition, ConstantCondition. A typical Condition element for a sink pattern contains only one condition: instruction call (InstructionCondition) with a reference (Ref) to an insecure call, which is defined in Definitions.

  • ChangeFlags element (only for source and passthrough patterns) shows how flags must be changed if a code fragment meets conditions described in the Condition.

  • ReportValues element specifies what entity information should be pushed to the user interface. This element contains one or more ReportValue elements. Each ReportValue contains a key attribute (ID string for a receiving module) and Ref element with id, attribute defining the entity, with any information on this having to be transmitted (id must be defined in Definitions). In most cases, information about called insecure instruction is transmitted, although information about class, method, field, etc. can also be transmitted.

  • XPath element is used to write down patterns based on an intermediate AST representation and is a query to XML representation of the intermediate representation of a program code.