Patent Description:
In static code analysis, a software application is tested without actually executing the application. The software application is typically tested by processing and analyzing the source code of the application prior to compiling the code. The entire source code of the application, or only portions of the source code, may be analyzed. The source code may be analyzed to identify vulnerabilities in the application, where vulnerabilities may include bugs, security breaches, violations of programming conventions, etc..

It is becoming increasingly common for software developers to generate (and typically release to the public) updates to software applications after the initial release of the application. Although the source code of the initially released application may be tested for vulnerabilities, it is often similarly desirable to test the updated software applications for vulnerabilities. The updated software applications typically have much source code in common with the initial release of the application. Accordingly, when potential vulnerabilities are not addressed in the initial release, they are identified during a test of not only the initial release but also the updated release of the software application. In some situations, such as when a potential vulnerability is not a real vulnerability, the redundant identification of potential vulnerabilities is problematic as it creates additional burdens on the tester reviewing the identified potential vulnerabilities.

Background art is provided in the following documents:
A paper by <NPL>), which discloses a way of automating signature creation for vulnerabilities that can be detected by a runtime monitor.

A paper by <NPL>), which discloses algorithms for generating vulnerability signatures that are based on computing weakest preconditions.

A thesis by <NPL>), which suggests that abstract regular expressions can be used to represent events of known attacks for the identification of security vulnerabilities in future applications.

<CIT>, which discloses a system and process for addressing computer security vulnerabilities. The system and process generally comprise aggregating vulnerability information on a plurality of computer vulnerabilities; constructing a remediation database of said plurality of computer vulnerabilities; constructing a remediation signature to address the computer vulnerabilities; and deploying said remediation signature to a client computer. The remediation signature essentially comprises a sequence of actions to address a corresponding vulnerability. A managed automated approach to the process is contemplated in which the system is capable of selective deployment of remediation signatures; selective resolution of vulnerabilities; scheduled deployment of remediation signatures; and scheduled scanning of client computers for vulnerabilities.

The present invention provides a method, a computer system, a computer program, and a non-transitory computer-readable medium as defined in the appended independent claims. Details of certain embodiments are set out in the dependent claims.

Embodiments of the present invention may address one of more of the above deficiencies. Also disclosed is a method of characterizing vulnerabilities of an application source code. The method includes traversing a representation of the application source code and generating a signature of a potential vulnerability of the application source code. The method also includes determining characteristics of the potential vulnerability based on a correlation between the generated signature of the potential vulnerability and previously stored signatures of potential vulnerabilities.

Generating a signature of a potential vulnerability of the application source code may include identifying a potential vulnerability in the application source, collecting metadata of a node associated with the vulnerability, and generating a signature of the potential vulnerability using the collected metadata. Generating a signature may also include determining whether the potential vulnerability is associated with more than one node, and when it is determined that the potential vulnerability is associated with more than one node, identifying a preferred node of the more than one node.

Collecting contextually significant information may include determining whether the node has a resolved symbol, and when it is determined that the node has a resolved symbol, collecting the corresponding qualified signature. Further, when it is determined that the node does not have a resolved symbol, the name of the node type may be collected if the node influences control flow of the application.

Determining characteristics of the potential vulnerability may include determining whether the generated signature matches any previously stored signatures of potential vulnerabilities. When it is determined that the generated signature matches a previously stored signature, the potential vulnerability may be characterized as having the generated signature as a duplicate. When it is determined that the generated signature does not match a previously stored signature, the potential vulnerability may be characterized as having the generated signature as a new vulnerability.

Also disclosed is a computing system that may comprise a number of elements, such as a storage element operable to store a representation of an application source code, and a processor operable to perform a variety of operations. The operations may include: traversing the representation of the application source code, generating a signature of a potential vulnerability of the application source code, and determining characteristics of the potential vulnerability based on a correlation between the generated signature of the potential vulnerability and previously stored signatures of potential vulnerabilities.

Also disclosed is a tangible non-transitory computer readable storage medium having code stored thereon that, when executed by a computer, causes the computer to perform various operations. The various operations may include: traversing a representation of an application source code, generating a signature of a potential vulnerability of the application source code, and determining characteristics of the potential vulnerability based on a correlation between the generated signature of the potential vulnerability and previously stored signatures of potential vulnerabilities.

Additional embodiments and features are set forth within the description that follows, and in part will become apparent to those skilled in the art upon examination of the specification, or may be learned by the practice of the disclosed embodiments. The features and advantages of the disclosed technology may be realized and attained by means of the instrumentalities, combinations, and methods described in the specification.

Embodiments of the present invention include apparatus, systems and methods for correlating the same vulnerability across an evolving codebase through the use of contextual information in the abstract syntax tree thereby reducing the number of duplicate vulnerabilities produced by a scan.

Some of the techniques described herein provide a static code analysis (SCA) engine that has the ability to correlate the same vulnerability across an evolving codebase, thereby reducing the number of duplicate vulnerabilities produced by a scan. Correlation of the same vulnerability across multiple scans of an evolving codebase may be achieved through the use of contextual analysis of the vulnerability as it exists in an abstract syntax tree (AST).

The SCA engine first models application source code into an AST structure. The AST structure is then analyzed various ways for security vulnerabilities. The vulnerabilities identified in the AST can be associated with one or more AST nodes (henceforth "vulnerability AST node"). For the purpose of performing correlation, the SCA engine selects the AST node that most correctly reflects the vulnerability in the application. For vulnerabilities containing two or more AST nodes, the SCA engine selects the last-most AST node. Given the vulnerability AST node, the SCA engine collects various meta-data about that node. If the AST node has a resolved symbol (e.g., resolved information about a variable declaration, variable usage, method invocation, method declaration, class declaration, etc.), then the SCA engine collects the corresponding qualified signature. If the AST node does not have a resolved symbol but is known to influence the control flow of the application, then the SCA engine simply collects the name of the AST node type. This meta-data collection occurs not only for the given vulnerability AST node, but for all the parents of the vulnerability AST node. When there is no longer any parent to scan (i.e., the SCA engine hits the root of the AST), then the SCA engine generates a hash of all the collected meta-data. This resulting hash of meta-data represents the unique signature of the vulnerability. This unique signature is generated using contextual information that will persist over the lifetime of the application unless the codebase containing the vulnerability dramatically changes. All unique vulnerability signatures produced by a scan are saved and used for comparison when the same application is re-scanned.

When the SCA engine re-scans the application, it will produce vulnerabilities and calculate corresponding unique vulnerability signatures. Signatures produced from the new scan are compared to signatures produced from the previous scan. If a unique signature in the current scan is found in the set of signatures from the previous scan, then the SCA engine considers the corresponding vulnerability a duplicate. If a unique signature in the current scan is not found in the previous scan, then the SCA engine determines that a new vulnerability is present. If a unique signature in the previous scan is not found in the current scan, then the SCA engine determines that the vulnerability is no longer present (i.e., the vulnerability has been fixed or removed).

Turning now to the figures, <FIG> is a block diagram illustrating a computer system <NUM> according to embodiments of the present invention. Computer system <NUM> may be any suitable electronic computing device, such as a desktop computer, a laptop computer, a network server, a note pad, a mobile phone, a personal digital assistant (PDA), a handheld or portable device (iPhone™, Blackberry™, etc.), or other electronic device. Computer system <NUM> may be associated with a user having a desire to perform static code analysis on source code stored at the computer system <NUM> or remote from computer system <NUM>.

Computer system <NUM> may include any suitable components typically found in such a system necessary to perform the operations discussed herein. In one embodiment and as illustrated in <FIG>, computer system <NUM> includes an input device <NUM>, an output device <NUM>, and a case <NUM>, all coupled to one another.

The input device <NUM> may be any device suitable for receiving input from the user. In the embodiment depicted in <FIG>, the input device <NUM> is a keyboard. However, in other embodiments, the input device <NUM> may include a mouse, a pointer, a touch-screen, a microphone, or other device suitable to receive information from a user.

The output device <NUM> may be any device suitable for providing information to the user. In the embodiment depicted in <FIG>, the output device <NUM> is an electronic display (e.g., an liquid crystal display, a light emitting diode display, etc.). However, in other embodiments, the output device <NUM> may include a speaker or other device suitable for providing information to the user. In at least one embodiment, the input device <NUM> and the output device <NUM> may be integrated with one another.

The case <NUM> may be any suitable case for containing one or more additional elements of computer system <NUM>, such as one or more processors <NUM>, one or more storage elements <NUM>, etc. The processor <NUM> may be any suitable computer processor operable to execute instructions stored on a medium (e.g., code representing the SCA engine), and storage element <NUM> may be any suitable tangible non-transitory computer readable storage medium. The storage element <NUM> may be operable to store application source code to be tested, representations of the source code under test, an application representing the SCA engine, etc. The storage element <NUM> may include, for example, one or more of random access memory (RAM), read only memory (ROM), electrically-erasable programmable read only memory (EEPROM), a hard disk, an optical disk, etc. The processor <NUM> may be operable to execute the application representing the SCA engine so as to test the source code under test.

In some embodiments, the application source code may be stored remotely from the computer system <NUM>. In such cases, the application source code, in whole or in part, may be retrieved by the computer system <NUM> and tested by the computer system <NUM>. For example, the computing system <NUM> may also include a communication interface (not shown) to facilitate wired or wireless communication with one or more other electronic devices, and may use the communication interface to acquire the source code and, in some embodiments, communicate test results.

Computer system <NUM> in certain embodiments is a computing environment for performing static code analysis using a number of components as depicted in <FIG>. However, it will be appreciated by those of ordinary skill in the art that static code analysis as described herein could be performed equally well in other computing environments including computer systems having fewer or a greater number of components than are illustrated in <FIG>. Thus, the depiction of computer system <NUM> in <FIG> should be taken as being illustrative in nature, and not limiting to the scope of the disclosure.

<FIG> illustrates various computing engines that may be used to perform static code analysis according to embodiments of the present invention. The various engines may comprise code operable to perform various functions when executed by a processor, or may comprise hardware operable to perform various functions when activated. For example, the various engines may comprise code stored on storage element <NUM> (<FIG>) that is operable to cause computer system <NUM> to perform various operations when executed by processor <NUM>. In some embodiments, the various engines depicted herein may correspond to the previously described SCA engine.

A translation engine <NUM> is coupled to a source code depository <NUM>. The source code depository <NUM> may store source code of an application under test, where the source code may represent all or only a portion of the application under test. For example, the source code depository <NUM> could be located in storage element <NUM> (<FIG>). The translation engine may read the source code from source code depository <NUM> and generate a representation of the source code. For example, the translation engine may generate a representation of the abstract syntactic structure of the source code. In at least one embodiment, the translation engine may generate an abstract syntax tree (AST) of the source code.

An analysis engine <NUM> is coupled to the translation engine <NUM> and is operable to receive the representation of the source code from the translation engine <NUM>. The analysis engine is operable to perform static code analysis on the representation of the source code. The analysis engine <NUM> may include one or more of a variety of components, such as a traverser <NUM>, a vulnerability detector <NUM>, a metadata collector <NUM>, a signature generator <NUM>, and a correlator <NUM> coupled to a current signatures repository <NUM> and a previously stored signatures repository <NUM>.

The traverser <NUM> may be operable to traverse the representation of the source code as described herein. In traversing the representation of the source code, the traverser <NUM> may use one or more rules included in a rule pack (not shown). Further, the traverser <NUM> may use metadata provided from metadata collector <NUM>. The traverser <NUM> may traverse nodes, children of nodes, parents of nodes, grandparents of nodes, etc. While traversing the nodes of the representation of the source code, the analysis engine <NUM> may simultaneously perform other tasks, such as detecting vulnerabilities, generating signatures, etc., as further described herein.

The vulnerability detector <NUM> may be operable to detect or otherwise identify vulnerabilities in the source code. Vulnerabilities may include bugs, security breaches, violations of programming conventions, etc. The vulnerability detector <NUM> may detect vulnerabilities while the traverser <NUM> traverses the representation of the source code as further described herein. Various techniques for detecting vulnerabilities are further described herein.

Metadata collector <NUM> may be operable to collect metadata while the traverser <NUM> traverses the representation of the source code. The metadata collector <NUM> may collect various information about one or more nodes associated with a detected vulnerability. For example, the metadata collector <NUM> may collect contextually significant information about child and/or parent nodes of the node associated with the detected vulnerability, as further described herein.

Signature generator <NUM> may be operable to generate a signature based on metadata collected by metadata collector <NUM>. The signature generator <NUM> may use the collected metadata in one or more of a variety of ways so as to generate a unique signature associated with the vulnerability. For example, the signature generator <NUM> may apply a hash function to the metadata and use the output of the hash function as the signature. Various techniques for generating a signature are further described herein.

Correlator <NUM> may be operable to correlate a generated signature of a detected potential vulnerability with previously stored signatures of previously detected potential vulnerabilities. Correlating the generated signature with previously stored signatures may include comparing the signatures with one another to determine whether they are identical or are substantially similar to one another. For example, correlator <NUM> may store generated signatures of detected potential vulnerabilities in the current signatures repository <NUM>, and may have previously stored signatures in repository <NUM>. Correlator <NUM> may then compare the recently stored signatures with those previously stored to determine whether there are any matches. Various techniques for performing such correlations are further described herein.

The engines depicted in <FIG> are operable to perform static code analysis according to certain embodiments. However, it will be appreciated by those of ordinary skill in the art that static code analysis as described herein could be performed equally well using fewer or a greater number of computing engines than are illustrated in <FIG>. Thus, the depiction of computing engines in <FIG> should be taken as being illustrative in nature, and not limiting to the scope of the disclosure.

<FIG> is a flowchart showing a method <NUM> of performing static code analysis according to embodiments of the present invention. The method <NUM> may be executed by any suitable computing system, such as computing system <NUM> (<FIG>), and/or one or more computational engines including those described with reference to <FIG>.

In operation <NUM>, the source code is obtained. The entire source code or only portions of the source code of an application to be tested may be acquired. For example, computing system <NUM> may receive the source code from another electronic device via wired or wireless communications. For another example, the source code may be generated at computing system <NUM>. The source code may be stored at computing system <NUM>, e.g., by storage element <NUM>, and/or by source code repository <NUM> (<FIG>).

In operation <NUM>, a representation of the structure of the source code is generated. For example, translation engine <NUM> (<FIG>) may generate an AST of the source code, where the AST includes various nodes to be traversed.

In operation <NUM>, a signature of a potential vulnerability of the source code is generated. Signatures of one or more potential vulnerabilities may be generated. For example, signature generator <NUM> (<FIG>) may use data provided by vulnerability detector <NUM> (<FIG>) and metadata collector <NUM> (<FIG>) to generate signatures of potential vulnerabilities. Various techniques for generating signatures of potential vulnerabilities are further described herein, for example with reference to <FIG>.

In operation <NUM>, characteristics of the potential vulnerability are determined. The characteristics are determined based on correlations between the signature(s) generated in operation <NUM> and one or more previously stored signatures of potential vulnerabilities. For example, signatures of potential vulnerabilities may be generated and stored for an initial source code (e.g., stored in the previously stored signatures repository <NUM> of <FIG>). The initial source code may then be updated or otherwise revised to include additional or different code, resulting in a subsequent source code. During or after a scan of the subsequent source code, one or more signatures of potential vulnerabilities of the subsequent source code may be generated (and, in some embodiments, stored in the current signatures repository <NUM> of <FIG>). Characteristics of the potential vulnerabilities of the subsequent source code may be determined based on correlations between the signatures of the potential vulnerabilities of the subsequent source code and the previously stored signatures of the potential vulnerabilities of the initial source code. For example, correlator <NUM> (<FIG>) may determine correlations between the signatures.

Characteristics may include whether the potential vulnerabilities in the subsequent source code are new vulnerabilities or old (i.e., redundant) vulnerabilities. Characteristics may also include whether potential vulnerabilities in the initial source code no longer exist in the subsequent source code, indicating that the potential vulnerabilities have been fixed or removed. Various techniques for determining characteristics of potential vulnerabilities are further described herein.

In operation <NUM>, one or more of the determined characteristics are output. For example, output engine <NUM> (<FIG>) may output information regarding the characteristics determined in operation <NUM>. In some embodiments, this may include identifying and outputting only newly found potential vulnerabilities, identifying and outputting only fixed or removed vulnerabilities, a combination thereof, etc. Various techniques for outputting such characteristics are further described herein.

It should be appreciated that the specific operations illustrated in <FIG> provide a particular method of performing static code analysis according to certain embodiments of the present invention. Other sequences of operations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the operations outlined above in a different order. Moreover, the individual operations illustrated in <FIG> may include multiple sub-operations that may be performed in various sequences as appropriate to the individual operations. Furthermore, additional operations may be added or existing operations removed depending on the particular applications. One of ordinary skill in the art would recognize and appreciate many variations, modifications, and alternatives.

<FIG> is a flowchart showing operations for generating a signature of a potential vulnerability of source code as depicted in operation <NUM> (<FIG>) according to an embodiment of the present invention. The operations may be executed by any suitable computing system, such as computing system <NUM> (<FIG>), and/or one or more computational engines including those described with reference to <FIG>.

In operation <NUM>, traversal of the representation of the source code begins. For example, traverser <NUM> (<FIG>) may begin traversing the representation of source code generated by translation engine <NUM> (<FIG>). In traversing the representation of source code, traverser <NUM> may scan the representation node-by-node, searching for potential vulnerabilities.

In operation <NUM>, it is determined whether a vulnerability is identified. For example, vulnerability detector <NUM> (<FIG>) may search for vulnerabilities in the application source code as the traverser <NUM> traverses the representation of the source code. If no vulnerability is detected, in some embodiments, the traverser may continue to search for vulnerabilities, whereas in other embodiments, the process may end if the traverser has finished traversing the representation of the source code.

In the event that a vulnerability is identified, processing continues to operation <NUM>. In operation <NUM>, it is determined whether the vulnerability is associated with more than one node. For example, vulnerability detector <NUM> may determine whether the identified vulnerability is associated with more than one node in the representation of the source code. If it is determined that the vulnerability is associated with only one node, then processing may continue to operation <NUM>, where metadata about that one node is collected. If it is determined that the vulnerability is associated with more than one node, then processing may continue to operation <NUM>.

In operation <NUM>, a preferred node is identified. The preferred node may be that node that most correctly reflects the vulnerability in the application. This may, for example, be the last-most node, i.e., the node that signifies the final state of execution by the application which triggers the vulnerability. In other words, it represents the last step in a finite state machine at which point the vulnerability is fully realized. Once the preferred node is selected, processing continues to operation <NUM>, where metadata about the preferred node is collected. Further techniques for collecting node metadata are described herein, for example with reference to <FIG>.

Once metadata about a node is collected, processing continues to operation <NUM>. In operation <NUM>, a signature of the potential vulnerability is generated. For example, signature generator <NUM> (<FIG>) may generate a signature of the potential vulnerability using the metadata collected in operation <NUM>. The collected metadata may be used in one or more of a variety of ways to generate a unique signature associated with the vulnerability. For example, the signature generator <NUM> may apply a hash function to the metadata and use the output of the hash function as the signature.

Once a signature of the vulnerability is generated, the signature may be stored in operation <NUM>. For example, the signature may be stored in the current signatures <NUM> repository. In some embodiments, after scanning of a first source code is complete and signatures are generated and stored, those stored signatures may be moved from the current signatures repository <NUM> to the previously stored signatures repository <NUM>. Then, upon subsequently scanning a second source code, any signatures generated for the second source code may be stored in the current signatures <NUM> for comparison to those in the previously stored signatures repository <NUM>.

In operation <NUM>, it is determined whether traversing of the representation of the source code is finished. For example, traverser <NUM> may determine whether it has finished traversing the entire representation of source code. If not, processing may continue with operation <NUM>. If so, processing may continue to operation <NUM> (<FIG>).

It should be appreciated that the specific operations illustrated in <FIG> provide a particular method of generating one or more signatures of one or more potential vulnerabilities of an application source code according to certain embodiments of the present invention. Other sequences of operations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the operations outlined above in a different order. Moreover, the individual operations illustrated in <FIG> may include multiple sub-operations that may be performed in various sequences as appropriate to the individual operations. Furthermore, additional operations may be added or existing operations removed depending on the particular applications. One of ordinary skill in the art would recognize and appreciate many variations, modifications, and alternatives.

<FIG> is a flowchart showing operations for determining characteristics of a potential vulnerability as depicted in operation <NUM> (<FIG>) according to an embodiment of the present invention. The operations may be executed by any suitable computing system, such as computing system <NUM> (<FIG>), and/or one or more computational engines including those described with reference to <FIG>.

In operation <NUM>, a generated signature is compared to previously stored signatures. For example, correlator <NUM> may compare one or more generated signatures (which may be stored in current signatures repository <NUM>) with one or more previously stored signatures (which may be stored in previously stored signatures repository <NUM>). The previously stored signatures may be signatures generated from previous iterations of the source code now under test.

In operation <NUM>, it is determined whether the one or more generated signatures matches the one or more previously stored signatures. For example, each generated signature may be compared to all of the previously stored signatures. If the generated signature is identical to or substantially similar to at least one of the previously stored signatures, then it may be determined that the generated signature matches the previously stored signatures. If there is not a match, then processing continues to operation <NUM>, where it is determined that a new vulnerability is detected. If there is a match, then processing continues to operation <NUM>, where it is determined that the vulnerability is a duplicate.

While the comparison between generated and previously stored signatures is depicted as being performed after traversing of the representation of source is complete and all vulnerabilities have been identified and signatures generated, in some embodiments the comparison may be performed at other suitable times. For example, with reference to <FIG>, the comparison may be performed at any time after generating a signature of the vulnerability (operation <NUM>). In such cases, characteristics of generated signatures may be determined immediately after the vulnerability is detected.

Further, in at least one embodiment, each previously stored signature may be compared to generated signatures to determine whether any previously stored signatures exist for which a new signature has not been generated. If it is determined that previously stored signatures exist but there is no corresponding new signature, then it may be determined that the vulnerability associated with the previously stored generator has been fixed or removed as a result of revisions to the source code used to generate the previously stored signatures.

It should be appreciated that the specific operations illustrated in <FIG> provide a particular method of determining characteristics of potential vulnerabilities according to certain embodiments of the present invention. Other sequences of operations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the operations outlined above in a different order. Moreover, the individual operations illustrated in <FIG> may include multiple sub-operations that may be performed in various sequences as appropriate to the individual operations. Furthermore, additional operations may be added or existing operations removed depending on the particular applications. One of ordinary skill in the art would recognize and appreciate many variations, modifications, and alternatives.

<FIG> is a flowchart showing operations for collecting node metadata as depicted in operation <NUM> (<FIG>) according to an embodiment of the present invention. The operations may be executed by any suitable computing system, such as computing system <NUM> (<FIG>), and/or one or more computational engines including those described with reference to <FIG>.

In operation <NUM>, it is determined whether a node has a parent. For example, metadata collector <NUM> may determine whether a node in the representation of the source code has a parent node. If so, then processing may continue to operation <NUM>.

In operation <NUM>, contextually significant information at the parent node is collected. For example, metadata collector <NUM> may collect a qualified signature of the node, a name of the node type, etc. Further techniques for collecting contextually significant information is described herein, for example with reference to <FIG>.

In operation <NUM>, it is determined whether the parent node has a parent. If so, then processing may return to operation <NUM>, and contextually significant information about the new parent may be collected. Otherwise, processing may continue to operation <NUM>. As a result of operations <NUM>, <NUM>, and <NUM>, contextually significant information about parent nodes, grandparent nodes, great-grandparent nodes, etc., can be collected. This information may subsequently be used (e.g., hashed) to generate a signature.

In operation <NUM>, it is determined whether a node has one or more child nodes. For example, metadata collector <NUM> may determine whether a node in the representation of the source code has one or more child nodes. If so, then processing may continue to operation <NUM> for each child node.

In operation <NUM>, contextually significant information at the child node is collected. For example, metadata collector <NUM> may collect a qualified signature of the node, a name of the node type, etc. Further techniques for collecting contextually significant information is described herein, for example with reference to <FIG>.

In operation <NUM>, it is determined whether the child node has one or more children nodes. If so, then processing may return to operation <NUM> for each child node, and contextually significant information about the new child node(s) may be collected. Otherwise, processing may continue to operation <NUM> (<FIG>). As a result of operations <NUM>, <NUM>, and <NUM>, contextually significant information about children nodes, grandchildren nodes, great-grandchildren nodes, etc., can be collected. This information may subsequently be used (e.g., hashed) to generate a signature.

In some embodiments, a node may only have parent nodes. In such cases, the contextually significant information at the parent nodes may be used to generate a signature. In other embodiments, a node may only have children nodes. In such cases, the contextually significant information at the children nodes may be used to generate a signature. In yet other embodiments, a node may have both parent and children nodes. In such cases, the contextually significant information at both the parent and children nodes may be used to generate a signature.

It should be appreciated that the specific operations illustrated in <FIG> provide a particular method of collecting node metadata according to certain embodiments of the present invention. Other sequences of operations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the operations outlined above in a different order. Moreover, the individual operations illustrated in <FIG> may include multiple sub-operations that may be performed in various sequences as appropriate to the individual operations. Furthermore, additional operations may be added or existing operations removed depending on the particular applications. One of ordinary skill in the art would recognize and appreciate many variations, modifications, and alternatives.

<FIG> is a flowchart showing operations for collecting contextually significant information as depicted in operations <NUM>/<NUM> (<FIG>) according to an embodiment of the present invention. The operations may be executed by any suitable computing system, such as computing system <NUM> (<FIG>), and/or one or more computational engines including those described with reference to <FIG>.

In operation <NUM>, it is determined whether the node (e.g., the node associated with the identified vulnerability, one or more parents of that node, and/or one or more children of that node) has a resolved symbol. For example, the metadata collector <NUM> (<FIG>) may determine whether there is resolved information about a variable declaration, variable usage, method invocation, method declaration, class declaration, etc. If so, then processing may continue to operation <NUM>, where the qualified signature corresponding to the resolved symbol is collected and used as the contextually significant information. If not, then processing may continue to operation <NUM>.

In operation <NUM>, it is determined whether the node influences the control flow of the application. For example, the metadata collector <NUM> may determine whether the node corresponds to an if/then statement, a jump statement, etc. If so, then processing may continue to operation <NUM>, where the name of the node type is collected and used as the contextually significant information. Otherwise, processing may continue to operation <NUM> (<FIG>) or <NUM> (<FIG>).

It should be appreciated that the specific operations illustrated in <FIG> provide a particular method of collecting contextually significant information according to certain embodiments of the present invention. Other sequences of operations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the operations outlined above in a different order. Moreover, the individual operations illustrated in <FIG> may include multiple sub-operations that may be performed in various sequences as appropriate to the individual operations. Furthermore, additional operations may be added or existing operations removed depending on the particular applications. One of ordinary skill in the art would recognize and appreciate many variations, modifications, and alternatives.

The following section provides specific examples illustrating how the SCA engine may calculate the vulnerability hash in source code based on the context of the an AST node.

SQLInjection. java - code vulnerable to SQL injection (<FIG>).

The SQLInjection class contains two distinct SQL injection vulnerabilities, at line <NUM> and <NUM> respectively. We will walk through operations performed by the SCA engine to produce a hash for both of these vulnerabilities starting at line <NUM>. The SCA engine visits the parents and the children of the vulnerability AST node looking for contextually significant AST nodes. Contextually significant AST nodes at a minimum include: method declarations, variable declarations, class declarations, method invocations, and any other AST node that results in code branching (e.g., an "if" statement).

The method invocation at line <NUM>, statement. execute(), is considered our vulnerability and is referred to as our "vulnerability AST node". The first thing the SCA engine does is visit the immediate children of this AST node to determine if they contain any contextually significant information. Given that the method invocation has no arguments, it has no children and thus there is no information of interest. The engine will then start visiting the current vulnerability AST node and all parents collecting information of interest. When traversing to the parent the SCA engine collects the following information many of which are fully qualified symbols of expressions:
statement. execute() - java. execute()
if("view". equals(action)) - class name of code branching statement
public void doGet -
com. SqlHttpServlet. doGet(javax. HttpServletRequest,
javax. HttpServletResponse)
public class SqlHttpServlet - com. SqlHttpServlet.

All of this information is then hashed together and represents the vulnerability signature. If a subsequent scan matches the hash value, then the SCA engine has high confidence that it is dealing with the same vulnerability in the same contextually similar location in code.

The method invocation at line <NUM>, statement. executeUpdate(), is also considered our vulnerability and is in fact referred to as our "vulnerability AST node". The first thing the SCA engine does is visit the immediate children of this AST node to determine if they contain any contextually significant information. Given that the method invocation has no arguments, it has no children and thus there is no information of interest. The engine will then start visiting the current vulnerability AST node and all parents collecting information of interest. When traversing to the parent the SCA engine collects the following information many of which are fully qualified symbols of expressions:
statement. executeUpdate() - java. executeUpdate()
public void doGet -
com. SqlHttpServlet. doGet(javax. HttpServletRequest,
javax. HttpServletResponse)
public class SqlHttpServlet - com. SqlHttpServlet.

Note that the first vulnerability hash incorporated the code branching "if" statement whereas the second did not. While these vulnerabilities are in the same method declaration, they are deemed to be contextually different enough to produce unique vulnerability hashes.

<FIG> is a diagram of a computer apparatus <NUM> according to some embodiments. The various elements in the previously described embodiments (e.g., computer system <NUM>) may use any suitable number of subsystems in the computer apparatus to facilitate the functions described herein. Examples of such subsystems or components are shown in <FIG>. The subsystems shown in <FIG> are interconnected via a system bus <NUM>. Additional subsystems such as a printer <NUM>, keyboard <NUM>, fixed disk <NUM> (or other memory comprising tangible, non-transitory computer-readable media), monitor <NUM>, which is coupled to display adapter <NUM>, and others are shown. Peripherals and input/output (I/O) devices (not shown), which couple to I/O controller <NUM>, can be connected to the computer system by any number of means known in the art, such as serial port <NUM>. For example, serial port <NUM> or external interface <NUM> can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus <NUM> allows the central processor <NUM> to communicate with each subsystem and to control the execution of instructions from system memory <NUM> or the fixed disk <NUM>, as well as the exchange of information between subsystems. The system memory <NUM> and/or the fixed disk <NUM> may embody a tangible, non-transitory computer-readable medium.

The software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.

The use of the terms "a" and "an" and "the" and similar referents in the context of describing embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The term "connected" is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. The use of any and all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate embodiments and does not pose a limitation on the scope unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of at least one embodiment.

Claim 1:
A method of correlating vulnerabilities in source code, the method comprising:
generating (<NUM>) a representation of the source code;
scanning the representation to identify one or more potential vulnerabilities;
generating (<NUM>) a signature for each of the one or more potential vulnerabilities;
storing the signature with a plurality of signatures from previous scans of one or more previous versions of the source code;
comparing (<NUM>) the signature with the plurality of signatures from the previous scans;
determining (<NUM>) whether the signature matches at least one signature from the plurality of signatures from the previous scans; and
in response to determining that the signature does not match the at least one signature from the plurality of signatures from the previous scans, determining (<NUM>) that the signature represents a new vulnerability and storing the signature with the plurality of signatures.