Vulnerability tracking using scopes and offsets

Abstract

The source code is managed through a source code control system, and one or more static application security testing scanners check the source code for vulnerabilities. The scanners generate vulnerability reports that are processed by a vulnerability tracker. The vulnerability tracker calculates the scope of vulnerabilities identified from the source code and generates scope and offset fingerprints (e.g., hashes that uniquely identify vulnerabilities based on the surrounding scope). The fingerprints are used for de-duplication and vulnerability tracking. The vulnerability tracker may generate an improved vulnerability report that includes a set of deduplicated vulnerabilities with corresponding fingerprints. The improved vulnerability report and associated data may be stored in a vulnerability database for use in vulnerability management.

Description

[Technical Field]

[0001]

[0002] The described subject matter relates generally to detecting software vulnerabilities, and more particularly to a vulnerability tracking approach that uses scope and offset fingerprints of detected vulnerabilities to reduce duplicate reporting. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 247,019, filed September 22, 2021, and U.S. Patent Application No. 17 / 941,935, filed September 9, 2022, which are incorporated by reference.

[0003]

[0003] Many entities use source code management (SCM) systems (such as Git) to manage software projects. As code is written and modified, security vulnerabilities inevitably arise. A security vulnerability is a software flaw that allows an attacker to gain control of a system or cause it to behave in an unintended or undesirable way. As a result, entities often apply automated security testing processes that monitor modified code to detect security vulnerabilities as early as possible in the software development process.

[0004]

[0004] One example of an automated security testing process is a static application security testing (SAST) tool that can automatically detect vulnerabilities in a software project's source code. SAST tools are typically language- and problem-specific. For example, some SAST tools can detect secrets (e.g., hard-coded passwords) in source code, while other tools focus on detecting potentially insecure flaws, etc. Thus, an entity may use multiple SAST tools in combination to reduce the overall attack surface of software.

[0005]

[0005] Each SAST tool analyzes source code and reports detected vulnerabilities for further analysis (e.g., by a human security analyst). In many cases, the same vulnerability may be reported multiple times because it appears more than once in the source code, is detected by multiple SAST tools, or both. As a result, security analysts must spend a significant amount of time sifting through potential duplicates to ensure they are the same. Furthermore, as code changes occur, the same vulnerability may be moved to a new location in the source code, or the source code may be reformatted without any substantive changes, making it difficult for security analysts to determine whether a given reported vulnerability is new or a duplicate of one previously discovered. Summary of the Invention

[0006]

[0006] These and other challenges may be addressed by a vulnerability tracking process capable of automatically identifying and tracking duplicate vulnerabilities. In particular, the disclosed process identifies vulnerabilities based on scope and offset fingerprints that contain information about the code surrounding the identified vulnerability. This may reduce instances of duplicate reporting and tracking of identified vulnerabilities that were moved to different locations in the code during the development cycle, thereby reducing the amount of noise considered by security analysts.

[0007] In one embodiment, a method for identifying and deduplicating vulnerabilities in a software project includes receiving source code and generating a parse tree from the source code. Scopes of source code blocks are extracted using the parse tree. The method also includes receiving a vulnerability report associated with the source code from one or more code scanners. The vulnerability report identifies vulnerabilities in the source code. Vulnerabilities identified in the vulnerability report match corresponding scopes, and fingerprints are generated from at least some of the scoped vulnerabilities. The method further includes deduplicating the scoped vulnerabilities using the fingerprints and generating a refined vulnerability report using the deduplicated scoped vulnerabilities. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram of a networked computing environment suitable for managing code for a software project, according to one embodiment. [Figure 2]

[0009] FIG. 2 is a block diagram of the vulnerability tracker shown in FIG. 1, according to one embodiment. [Figure 3]

[0010] FIG. 3 illustrates an exemplary parse tree for a segment of code, according to one embodiment. [Figure 4]

[0011] FIG. 4 is a flowchart of a method for identifying and de-duping vulnerabilities in a software project, according to one embodiment. [Figure 5]

[0012] FIG. 5 is a block diagram illustrating an exemplary computer suitable for use in the networked computing environment of FIG. 1, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009]

[0013] The drawings and the following description describe specific embodiments for purposes of example only. Those skilled in the art will readily recognize from the following description that alternative embodiments of structure and methods may be employed without departing from the principles described. Wherever practicable, similar or like reference numbers are used in the figures to indicate similar or like functionality. When elements share a common number followed by another letter, this indicates that the elements are similar or identical. Unless the context indicates otherwise, reference to a number alone generally refers to any one or any combination of such elements.

[0010] Exemplary System

[0014] 1 illustrates one embodiment of a networked computing environment 100 suitable for managing code for a software project. In the illustrated embodiment, the networked computing environment includes a source code repository 110, one or more client devices 120, one or more code scanners 130, and a vulnerability tracker 140, all connected via a network 170. In other embodiments, the networked computing environment 100 includes different or additional elements. Additionally, functionality may be distributed among the elements in a manner different from that described. For example, while the code scanner 130 and the vulnerability tracker 140 are shown as different entities, in some embodiments, the corresponding functionality is provided by a single computing system (e.g., a server).

[0011]

[0015] Source code repository 110 includes one or more computer-readable storage media that store code for one or more software projects. In one embodiment, source code repository 110 stores code for an SCM system. An SCM system may store multiple versions of a software project's code, allowing updates to be rolled back, developers to see the historical status of the code, and the like.

[0012]

[0016] Client devices 120 are computing devices on which software engineers may edit code and commit updates to code repository 110. For example, client devices 120 may be desktop workstations on which engineers download portions of code from source code repository 110, revise and test them in a development environment, and upload the revised code to source code repository 110. Multiple engineers may each use a corresponding client device 120 to revise code and commit those revisions to source code repository 110 at any given time. Known appropriate techniques may be used to manage conflicts between updates made to code by different engineers at approximately the same time.

[0013]

[0017] The code scanner 130 continuously, periodically (e.g., hourly, daily, etc.), or on-demand scans the code in the source code repository to identify vulnerabilities. In one embodiment, the code scanner 130 includes a set of SAST tools. Each of the SAST tools scans code (or portions of code in a language for which the SAST is intended) to identify vulnerabilities. The SAST tools generate vulnerability reports that include information about the identified vulnerabilities. The SAST tools may generate a report that includes all vulnerabilities identified after scanning the code (or a particular portion of code). Alternatively, the SAST tools may generate individual reports for each identified vulnerability (e.g., immediately after identifying it).

[0014]

[0018] Vulnerability tracker 140 ingests the reports generated by the code scanners and processes them to remove duplicates, where the same vulnerability is identified more than once. In one embodiment, vulnerability tracker 140 identifies duplicates by generating fingerprints from the scope and offset of the vulnerability.

[0015]

[0019] A scope is a source code block (possibly nested) containing statements and expressions, including definitions / declarations of entities such as variables, functions, classes, structures, and types. Scopes limit the visibility of these entities to a portion of a program. In one embodiment, a scope tag uniquely identifies a scope, which is composed of scope elements, which refer to concepts such as packages, modules, namespaces, types, classes, and function definitions associated with a scope. Scope tags are labeled with their corresponding source code tokens.

[0016]

[0020] For example, consider the following code fragment: module widget class CustomWidget def run(user_supplied_arg) exec(“echo #{user_supplied_arg}”) end end end

[0017]

[0021] The code fragment contains four scopes / scope tags: (1) custom_widget.rb, (2) custom_widget.rb>Widget, (3) custom_widget.rb>Widget>CustomWidget, and (4) custom_widget.rb>Widget>CustomWidget>run. Note that this treats files containing source code as separate scopes. The symbol ">" is used herein as a delimiter to separate scope elements. However, any preferred delimiter may be used.

[0018]

[0022] The offset indicates the location of a particular piece of code (e.g., a line identified as a vulnerability) within the scope. In one embodiment, the offset is described as a number indicating the number of lines of code from the start of the scope to the particular piece of code identified.

[0019]

[0023] Various embodiments of a process for identifying duplicate vulnerabilities in code using fingerprints are described in more detail below with reference to FIG.

[0020]

[0024] Network 170 provides a communication channel through which other elements of networked computing environment 100 communicate. Network 170 can include any combination of local-area and wide-area networks using wired or wireless communication systems. In one embodiment, network 170 uses standard communication technologies and / or protocols. For example, network 170 can include communication links using technologies such as Ethernet, 802.11, Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, 5G, Code Division Multiple Access (CDMA), Digital Subscriber Line (DSL), etc. Examples of network protocols used to communicate over network 170 include Multiprotocol Label Switching (MPLS), Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). Data exchanged over network 170 can be represented using any suitable format, such as Hypertext Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, some or all of the communication links of network 170 may be encrypted using any suitable technique.

[0021]

[0025] 2 illustrates one embodiment of vulnerability tracker 140. In the illustrated embodiment, vulnerability tracker 140 includes a parsing module 210, a scope extraction module 220, a scope matching module 230, a fingerprinting module 240, a deduplication module 250, and a vulnerability database 260. In other embodiments, networked computing environment 100 includes different or additional elements. Additionally, functionality may be distributed among elements in a manner different from that described.

[0022]

[0026] The parsing module 210 parses the source code to obtain a parse tree. A parse tree is a structural / hierarchical representation of the source code. For example, a parse tree may show libraries, classes, functions, calls, etc., along with the relationships between them. In one embodiment, the vulnerability tracking methodology is independent of any particular programming language, and therefore, any parsing tool capable of generating a parse tree from source code may be used.

[0023]

[0027] Parsing is the process of deriving a parse tree from source code. The following code snippet shows a sample program, example.rb, which contains three classes with four functions and four calls: class OuterClass class InnerClassA def function_A puts "..." end def function_A puts "..." end class InnerClassB def function_A puts "..." end def function_B puts "..." end end end

[0024]

[0028] Parsing is able to understand the syntactic elements of source code and build a hierarchical representation of the code called a syntax tree or parse tree. Figure 3 shows a simplified diagram of a parse tree that can be generated by parsing. For simplicity, the file name portion of the scope labels is omitted in the following description. The parse tree structure captures scoping through parent-child node relationships. A parent node, if it represents a scope element, provides a scope to its children. Conversely, a child node's scope cannot exist without the scope provided by its parent node. For example, the child scope OuterClass>InnerClassB>function_A cannot exist without the parent scope OuterClass>InnerClassB. Figure 3 also shows the node types of the nodes (enclosed in < > in the diagram) provided by parsing. For example, OuterClass has a type <class>, which is a node that refers to a class declaration that appears in the source code.

[0025]

[0029] 2, the scope extraction module 220 analyzes the parse tree to identify scopes (blocks of source code that cage the visibility of variables and / or functions present in the source file) present in the source code. In one embodiment, each node in the parse tree corresponds to a scope, and the scopes are labeled by traversing the tree backwards to the root node (e.g., the file name containing the code) and adding an identifier for each parsed node to the label.

[0026]

[0030] For example, returning to the example.rb code fragment of FIG. 3 and its corresponding parse tree, scope extraction module 220 identifies seven scopes with the following labels, where A>B indicates that scope element B is nested within scope element A: (a)example.rb>OuterClass[0] (b)example.rb>OuterClass[0]>InnerClassA[0] (c)example.rb>OuterClass[0]>InnerClassA[0]>function_A[0] (d) example.rb>OuterClass[0]>InnerClassA[0]>function_A[1] (duplicate of c) (e)example.rb>OuterClass[0]>InnerClassB[0] (f)example.rb>OuterClass[0]>InnerClassB[0]>function_A[0] (g)example.rb>OuterClass[0]>InnerClassB[0]>function_B[0]

[0027]

[0031] In particular, there are two function_As in InnerClassA[0], the first one in node 3 with index number [0] and the second one in node 5 with index number [1]. The scope of node 3 (corresponding to item (c) above) is the same as the scope of node 5 (corresponding to item (d) above). Therefore, the duplicates may be removed.

[0028]

[0032] Scope computation may be performed by depth-first (DF) pre-order traversal. Pre-order traversal allows for computation of parent scopes before computing child scopes, which is an efficient order due to their interdependencies. For example, the above scope (e) OuterClass[0] > InnerClassB[0] (corresponding to the scope of node 7) is necessary to compute the above scope (f) OuterClass[0] > InnerClassB[0] > function_A[0] (corresponding to the scope of node 8). The numbers associated with each node in FIG. 3 indicate the order in which the scope extraction module 220 may visit each node in the parse tree.

[0029]

[0033] In one embodiment, the scope extraction module 220 relies on a stack of tags (computed based on the identified scope elements) and a set of tags that captures all tags being generated. The traversal algorithm descends the tree regardless of node type. For node types that are relevant in terms of scoping, the scope extraction module 220 creates tags and descends. Each time the scope extractor encounters a node that corresponds to a scope, a new scope tag is generated. Some node types that are not relevant to the scoping may be skipped.

[0030]

[0034] In the Example.rb example, in traversal step 1, the scope extraction module 220 extracts the relevant types in terms of scope to represent class declarations. <class>Therefore, it generates a corresponding scope tag for OuterClass, adds the scope tag to the set of scope tags, and pushes the scope tag onto the tag stack so that it is accessible to the next child node that the scope extraction module 220 will analyze. <funcdef>When a scope extraction module 220 encounters a tag (function definition node), it generates a tag by peeking at the most recently generated tag item from the stack (OuterClass>InnerClassA). This information is used to generate a new tag item (OuterClass>InnerClassA>function_A). Note that when the scope extraction module 220 finishes processing a node, the corresponding tag item is popped from the stack. For example, after completing traversal steps 3 and 4, the scope extraction module 220 pops OuterClass>InnerClassA>function_A from the stack in traversal step 5, so that OuterClass>InnerClassA is the last tag item on the stack.

[0031]

[0035] Some languages ​​allow methods / classes to be defined multiple times. For example, in the code represented by the parse tree of FIG. 3 , function_A is defined twice within InnerClassA, and both are converted to OuterClass > InnerClassA > function_A, so that concatenation of scope elements does not guarantee uniqueness of tags. In one embodiment, the scope extraction module 220 enables the generation of unique tags by applying a numbering scheme to scope elements and maintaining an internal counter that tracks how often a scope element is encountered within a scope. In the case of FIG. 3 , the counter is indicated by a number enclosed in parentheses. Therefore, due to the scope numbering scheme, instead of using the same scope tag for the two occurrences of function_A in InnerClassA, the scope extraction module 220 generates separate scope tags for both occurrences: OuterClass[0] > InnerClassA[0] > function_A[0] and OuterClass[0] > InnerClassA[0] > function_A[1].

[0032]

[0036] The scope tags generated by the scope extraction module 220 may include scope boundaries, i.e., source coordinates that capture the source locations of the start and end of a given scope. For example, the line numbers where the block of code corresponding to the scope begins and ends may be used to define the scope boundaries.

[0033]

[0037] The following example shows an excerpt from the sample program custom_widgets.rb. 1: Module Widget 2: class CustomWidget 3: def foo(arg) / / ... 10: end / / ... 20: def run(user_supplied_arg) / / ... 30: end 31: 32: end 33: end

[0034]

[0038] The scope extraction module 220 generates a scope table that contains scope tags and scope boundaries indicated by the start and end lines of the scopes in the source code. The example scope table below (Table 1) shows the details of the scope tags as well as the start and end lines of the scopes contained in the above code fragment.

[0035] [Table 1]

[0036]

[0039] For example, in Table 1, the scope of the function executed with the scope tag custom_widget.rb[0]>Widget[0]>CustomWidget[0]>run[0] starts from line 20 and ends at line 30.

[0037]

[0040] 2, the scope matching module 230 scopes vulnerabilities contained in vulnerability reports received from one or more SAST scanners. The vulnerability reports may identify the location of the vulnerability by line number. The scope matching module 230 uses the scope boundary along with the vulnerability's line number to identify the containing / enclosing scope.

[0038]

[0041] For example, assuming that scope.start_line and scope.end_line indicate the start and end lines (scope boundaries) of a scope in a source code file, respectively, the scope matching module 230 may identify the narrowest scope that encompasses the reported vulnerability, whose location is identified by that source code line. In one embodiment, the scope matching module identifies the narrowest scope, i.e., the scope for which the following parameter (smatch) is minimized: smatch=((line-scope.start_line)+(scope.end_line-line)) scope.start_line<=line<=scope.end_line

[0039]

[0042] Using the example run custom_widgets.rb, if the SAST tool reports a vulnerability on line 25 of the source code, the scope matching module 230 determines the matching scope based on the scope table generated by the scope extraction module 220. Table 2 below is similar to Table 1, but also includes the smatch value for each scope.

[0040] [Table 2]

[0041]

[0044] Since line 25 is within this scope (lines 20 to 30) and the smatch value of 10 is the lowest smatch value across all scopes, the matching scope is custom_widget.rb[0]>Widget[0]>CustomWidget[0]>run[0]. Note that Custom_widget.rb[0]>Widget[0]>CustomWidget[0]>foo[0] is not considered because it does not satisfy the constraint scope.start_line<=line<=scope.end_line.

[0042]

[0045] The fingerprint module 240 generates a fingerprint for the identified vulnerability using the matching scope. The fingerprint may also be based on the type or category of the corresponding vulnerability. The fingerprint module 240 may generate a fingerprint for the vulnerability using one or more of the name of the scope identified by the scope matching module 230 for the vulnerability, the offset of the vulnerability, or the vulnerability classifier. The vulnerability classifier may be the category or type of vulnerability included in the report received from the SAST. In one embodiment, the fingerprint module 240 generates the fingerprint by calculating a hash value from one or more of the scope, the offset, and the vulnerability classifier. For example, the scope name, the offset value, and the vulnerability classifier may be concatenated into a text string (possibly with delimiters between portions) that is provided as input to the hash function. CWE, CVE, or OWASP categories may be used to make the hashes comparable across different analyzers.

[0043]

[0046] Returning to the Custom_widgets.rb example, if the SAST tool reports a vulnerability of class / type CWE-22 on line 25, fingerprint module 240 may calculate the following hash: custom_widget.rb[0]>widget[0]>CustomWidget[0]>execution[0]>5>CWE-22, where 5 is the relative scope offset calculated by subtracting the line of the vulnerability discovery from the start line of the enclosing scope (line-scope.start_line), and CWE-22 is the vulnerability category.

[0044]

[0047] The deduplication module 250 identifies which vulnerabilities are identical based on the vulnerability fingerprints and removes the duplicates, resulting in a refined set of vulnerabilities. This refined set of vulnerabilities can be stored as an refined report (e.g., in the vulnerability database 260). The refined report occupies less storage due to the deduplication. Also, the time a data analyst spends calculating duplicate vulnerabilities can be significantly reduced, making it more efficient for the data analyst to review the report and address the identified vulnerabilities.

[0045]

[0048] In one embodiment, vulnerability deduplication is performed based on the generated hash. Two vulnerabilities are considered identical if they can be converted to the same fingerprint. Specifically, if the hashes of two vulnerabilities match, they (1) are located in the same scope, (2) have the same vulnerability type or classification, and (3) have the same line offset as the start of their parent scope.

[0046]

[0049] Returning to the Custom_widgets.rb execution example, if the developer shifts the run function by +100 source code lines, the SAST tool will report a CWE-22 vulnerability at line 125, with a difference of +100 lines. Because fingerprint hashes are generated based on scope and offset, rather than absolute location (e.g., line number), the deduplication module 250 is able to dedupe the vulnerabilities from lines 25 and 125. For both vulnerabilities, the fingerprint hashes are identical: custom_widget.rb[0]>Widget[0]>CustomWidget[0]>run[0]>5>CWE-22.

[0047]

[0050] Vulnerability database 260 includes one or more computer-readable media configured to store the refined vulnerability reports generated by de-duplication module 250. Although vulnerability database 260 is shown as a single entity that is part of vulnerability tracker 140, in one embodiment, the vulnerability database is distributed across multiple devices in a distributed database accessed via network 170.

[0048] Exemplary Methods

[0051] 4 illustrates a method 400 for identifying and de-duplicating vulnerabilities in a software project, according to one embodiment. The steps in FIG. 4 are shown from the perspective of vulnerability tracker 140 performing method 400. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform steps in parallel, in a different order, or perform different steps.

[0049]

[0052] In the embodiment shown in FIG. 4 , method 400 begins with vulnerability tracker 140 receiving 410 source code for a software project (e.g., by reading the source code from source code repository 110). Vulnerability tracker 140 generates 420 a parse tree from the source code and uses the parse tree to extract 430 scopes of source code blocks. Vulnerability tracker 140 receives 440 vulnerability reports (e.g., from one or more code scanners 130) and matches 450 identified vulnerabilities to corresponding scopes to obtain a set of scoped vulnerabilities. Vulnerability tracker 140 generates 460 fingerprints for at least some of the scoped vulnerabilities (e.g., by generating a hash from the scope name, offset, and vulnerability classifier) ​​and de-duplicates 470 the identified vulnerabilities using the hash. Vulnerability tracker 140 generates 480 (and stores) an improved vulnerability report from the de-duplicated vulnerability data.

[0050] Computing System Architecture

[0053] 5 is a block diagram of an exemplary computer 500 suitable for use as a client device 120, a code scanner 130, or a vulnerability tracker 140, or for hosting a source code repository 110. The exemplary computer 500 includes at least one processor 502 coupled to a chipset 504. The chipset 504 includes a memory controller hub 520 and an input / output (I / O) controller hub 522. A memory 506 and a graphics adapter 512 are coupled to the memory controller hub 520, and a display 518 is coupled to the graphics adapter 512. A storage device 508, a keyboard 510, a pointing device 514, and a network adapter 516 are coupled to the I / O controller hub 522. Other embodiments of the computer 500 have different architectures.

[0051]

[0054] 4, storage device 508 is a non-transitory computer-readable storage medium such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 506 holds instructions and data used by processor 502. Pointing device 514 is a mouse, trackball, touchscreen, or other type of pointing device and may be used in combination with keyboard 510 (which may be an on-screen keyboard) to input data into computer system 500. Graphics adapter 512 displays images and other information on display device 518. Network adapter 516 couples computer system 500 to one or more computer networks, such as network 170.

[0052]

[0055] 1 and 2 can vary depending on the embodiment and the processing power required for the entities. For example, a system hosting source code repository 110 may include multiple blade servers working together to provide the described functionality, while client device 120 may be a desktop workstation or tablet. Furthermore, computer 500 may lack some of the above components, such as keyboard 510, graphics adapter 512, and display 518.

[0053] Additional Considerations

[0056] Some portions of the foregoing describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. While these operations may be described functionally, computationally, or logically, they should be understood to be implemented by computer programs, including instructions, microcode, etc., executed by a processor or equivalent electrical circuitry. Further, without loss of generality, it has proven convenient at times to refer to such arrangements of functional operations as modules.

[0054]

[0057] As used herein, a reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is done merely for convenience. This description should be understood to mean that there are one or more of the element or component, unless it is clear that something else is meant.

[0055]

[0058] When values ​​are described as "about" or "substantially" (or derivatives thereof), unless otherwise clear from the context, such values ​​should be construed as being accurate to + / - 10%. By way of example, "about 10" should be understood to mean "within the range of 9 to 11."

[0056]

[0059] As used herein, "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, is intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus consisting of a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" means an inclusive "or," not an exclusive "or." For example, condition A or B can be satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0057]

[0060] Upon reading this disclosure, those skilled in the art will recognize yet additional alternative structural and functional designs for systems and processes that track vulnerabilities using scope and offset values ​​to reduce overlapping instances. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise structures and components disclosed. The scope of protection should be limited only by any claims that issue.< / funcdef> < / class> < / class>

Claims

1. 1. A method for analyzing vulnerabilities in a software project, comprising: receiving the source code; generating a parse tree from the source code; extracting the scope of a source code block using the parse tree; receiving a vulnerability report associated with the source code from one or more code scanners, the vulnerability report identifying vulnerabilities within the source code; matching the vulnerabilities identified in the vulnerability report to corresponding scopes to generate a set of scoped vulnerabilities; generating a fingerprint of at least a portion of the scoped vulnerability; de-duplicating the scoped vulnerabilities using the fingerprints; generating an improved vulnerability report using the de-duplicated scoped vulnerabilities; 10. The method of claim 1, wherein the fingerprint for a vulnerability is generated using a scope of the vulnerability and an offset of the vulnerability, the offset being calculated by subtracting a line number of the vulnerability from a starting line of the scope.

2. 1. A method for analyzing vulnerabilities in a software project, comprising: receiving the source code; generating a parse tree from the source code; extracting the scope of a source code block using the parse tree; receiving a vulnerability report associated with the source code from one or more code scanners, the vulnerability report identifying vulnerabilities within the source code; matching the vulnerabilities identified in the vulnerability report to corresponding scopes to generate a set of scoped vulnerabilities; generating a fingerprint of at least a portion of the scoped vulnerability; de-duplicating the scoped vulnerabilities using the fingerprints; generating an improved vulnerability report using the de-duplicated scoped vulnerabilities; 10. A method according to claim 1, wherein the parse tree comprises a plurality of nodes, the plurality of nodes comprising at least one parent node and a child node, the parent node representing a scope that provides a scope to the child node, and the child node cannot exist without the scope provided by the parent node.

3. The method of claim 2 , wherein the parent node represents an outer class and the child node represents an inner class nested within the outer class.

4. The method of claim 2 , wherein the parent node represents a class and the child node represents a function nested within the class.

5. extracting a scope of a source code block using the parse tree, traversing the parse tree from an end child node that has no children to a root parent node that has no parents; labeling the scope of each of the plurality of nodes with an identifier of the corresponding node.

6. Extracting the scope of the source code is 3. The method of claim 2, comprising: performing a depth-first (DF) preorder traversal; and traversing each of the plurality of nodes in the parse tree.

7. The method of claim 1 , wherein generating the fingerprint for the vulnerability comprises calculating a hash using the scope and offset.

8. deduplicating the scoped vulnerabilities using the fingerprints, comparing two hashes for two vulnerabilities to determine whether the two vulnerabilities (1) are located within the same scope, (2) have the same vulnerability type or classification, and (3) have the same offset relative to the line number where their parent scopes start; and in response to determining that the two hashes of the two vulnerabilities match, removing one of the two vulnerabilities from the set of scope vulnerabilities.

9. The method of claim 1 , wherein the fingerprint is further generated using a classifier of the vulnerability.

10. A non-transitory computer-readable storage medium having encoded thereon instructions that, when executed by a processor, cause the processor to: receiving the source code; generating a parse tree from the source code; extracting the scope of a source code block using the parse tree; receiving a vulnerability report associated with the source code from one or more code scanners, the vulnerability report identifying vulnerabilities within the source code; matching the vulnerabilities identified in the vulnerability report to corresponding scopes to generate a set of scoped vulnerabilities; generating a fingerprint of at least a portion of the scoped vulnerability; de-duplicating the scoped vulnerabilities using the fingerprints; generating an improved vulnerability report using the de-duplicated scoped vulnerabilities; 1. A non-transitory computer-readable storage medium, wherein the fingerprint for a vulnerability is generated using a scope of the vulnerability and an offset of the vulnerability, the offset being calculated by subtracting a line number of the vulnerability from a starting line of the scope.

11. A non-transitory computer-readable storage medium having encoded thereon instructions that, when executed by a processor, cause the processor to: receiving the source code; generating a parse tree from the source code; extracting the scope of a source code block using the parse tree; receiving a vulnerability report associated with the source code from one or more code scanners, the vulnerability report identifying vulnerabilities within the source code; matching the vulnerabilities identified in the vulnerability report to corresponding scopes to generate a set of scoped vulnerabilities; generating a fingerprint of at least a portion of the scoped vulnerability; de-duplicating the scoped vulnerabilities using the fingerprints; generating an improved vulnerability report using the de-duplicated scoped vulnerabilities; a non-transitory computer-readable storage medium, the parse tree including a plurality of nodes, the plurality of nodes including at least one parent node and a child node, the parent node representing a scope that provides a scope to the child node, and the child node cannot exist without the scope provided by the parent node.

12. 12. The non-transitory computer-readable storage medium of claim 11, wherein the parent node represents an outer class and the child node represents an inner class nested within the outer class.

13. The non-transitory computer-readable storage medium of claim 11 , wherein the parent node represents a class and the child node represents a function nested within the class.

14. extracting a scope of a source code block using the parse tree, traversing the parse tree from an end child node that has no children to a root parent node that has no parents; and labeling the scope of each of the plurality of nodes with an identifier of the corresponding node.

15. Extracting the scope of the source code is 12. The non-transitory computer-readable storage medium of claim 11, comprising: performing a depth-first (DF) preorder traversal; and traversing each of the plurality of nodes in the parse tree.

16. The non-transitory computer-readable storage medium of claim 10 , wherein generating the fingerprint for the vulnerability includes calculating a hash using the scope and offset.

17. deduplicating the scoped vulnerabilities using the fingerprints, comparing two hashes for two vulnerabilities to determine whether the two vulnerabilities (1) are located within the same scope, (2) have the same vulnerability type or classification, and (3) have the same offset relative to the line number where their parent scopes start; and in response to determining that the two hashes of the two vulnerabilities match, removing one of the two vulnerabilities from the set of scope vulnerabilities.

18. The non-transitory computer-readable storage medium of claim 10 , wherein the fingerprint is further generated using a vulnerability classifier.

Images