WO2026018186A1 - Suivi des vulnérabilités à l'aide d'une portée et d'un décalage normalisé - Google Patents

Suivi des vulnérabilités à l'aide d'une portée et d'un décalage normalisé

Info

Publication number
WO2026018186A1
WO2026018186A1 PCT/IB2025/057221 IB2025057221W WO2026018186A1 WO 2026018186 A1 WO2026018186 A1 WO 2026018186A1 IB 2025057221 W IB2025057221 W IB 2025057221W WO 2026018186 A1 WO2026018186 A1 WO 2026018186A1
Authority
WO
WIPO (PCT)
Prior art keywords
scope
vulnerabilities
code
vulnerability
source code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2025/057221
Other languages
English (en)
Inventor
Julian THOME
Lucas CHARLES
Craig Mark SMITH
Jason LEASURE
Hua Yan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gitlab Inc
Original Assignee
Gitlab Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gitlab Inc filed Critical Gitlab Inc
Publication of WO2026018186A1 publication Critical patent/WO2026018186A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the subject matter described relates generally to detecting software vulnerabilities and, in particular, to an approach to tracking vulnerabilities that reduces double reporting using scope and offset fingerprints of detected vulnerabilities.
  • SCM Source Code Management
  • SAST static application security testing
  • SAST tools are typically language and problem specific. For example, some SAST tools can detect secrets (e.g., hardcoded passwords) in the source code, while other tools are focused on detecting potentially insecure flows, etc.
  • secrets e.g., hardcoded passwords
  • entities may employ multiple SAST tools in combination to reduce the overall attack surface of the software.
  • Each SAST tool analyzes the source code and reports detected vulnerabilities for further analysis (e.g., by a human security analyst).
  • the same vulnerability may be reported multiple times because it appears more than once in the source code, is detected by more than one of the SAST tools, or both. Consequently, the security analyst must spend a significant amount of time sifting through potential duplicates to verify they are the same.
  • the same vulnerability may be moved to a new location in the source code or the source code may be reformatted without substantive changes, making it difficult for the security analyst to determine whether any given reported vulnerability is new or a duplicate of one seen previously.
  • the disclosed process identifies vulnerabilities based on a scope and offset fingerprint that includes information about the code surrounding an identified vulnerability. This may reduce the amount of noise considered by a security analyst by reducing instances of double reporting and tracking identified vulnerabilities that are moved to different positions in the code during the development cycle.
  • the offset is a normalized offset that excludes non-functional lines of code from the computation of the offset, which can further reduce duplication in detected vulnerabilities.
  • a method for identifying and deduplicating vulnerabilities in a software project includes receiving source code and generating a parse tree from the source code. The scopes of source code blocks are extracted using the parse tree. The method also includes receiving vulnerability reports relating to the source code from one or more code scanners. The vulnerability reports identify vulnerabilities in the source code. The vulnerabilities identified in the vulnerability reports are matched to 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 vulnerabilities report using the deduplicated scoped vulnerabilities.
  • FIG. 1 is a block diagram of a networked computing environment suitable for managing the code of a software project, according to one embodiment.
  • FIG. 2 is a block diagram of the vulnerability tracker shown in FIG. 1, according to one embodiment.
  • FIG. 3 illustrates an example parse tree for a segment of code, according to one embodiment.
  • FIG. 4 is a flowchart of a method for identifying and deduplicating vulnerabilities in a software project, according to one embodiment.
  • FIG. 5A illustrates an example parse tree for a code block with non-functional lines of code, according to one embodiment.
  • FIG. 5B illustrates another example parse tree for a code block with non-functional lines of code, according to one embodiment.
  • FIG. 6 is a block diagram illustrating an example computer suitable for use in the networked computing environment of FIG. 1, according to one embodiment.
  • FIG. 1 illustrates one embodiment of a networked computing environment 100 suitable for managing the code of a software project.
  • 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.
  • the networked computing environment 100 includes different or additional elements.
  • the functions may be distributed among the elements in a different manner than described.
  • the code scanners 130 and vulnerability tracker 140 are shown as distinct entities, in some embodiments the corresponding functionality is provided by a single computing system (e.g., a server).
  • the source code repository 110 includes one or more computer-readable storage media that store the code for one or more software projects.
  • the source code repository 110 stores the code for a SCM system.
  • the SCM system may store multiple versions of the code for the software project to enable updates to be rolled back and developers to review the historical status of the code, etc.
  • the client devices 120 are computing devices with which software engineers may edit code and commit updates to the code repository 110.
  • a client device 120 may be a desktop workstation with which an engineer downloads a portion of code from the source code repository 110, makes and tests revisions in a development environment, and uploads the revised code to the source code repository 110.
  • Multiple engineers may each use a corresponding client device 120 to revise code and commit those revisions to the source code repository 110 at any given time.
  • Known suitable techniques may be used to manage conflicts between updates made to the code by different engineers at approximately the same time.
  • the code scanners 130 continuously, periodically (e.g., hourly, daily, etc.), or on demand scan the code in the source code repository to identify vulnerabilities.
  • the code scanners 130 include a set of SAST tools.
  • Each SAST tool scans the code (or portions of the code in a language the SAST is intended to be used with) in to identify vulnerabilities.
  • the SAST tools generate vulnerability reports with information regarding identified vulnerabilities.
  • a SAST tool may generate a report including all of the vulnerabilities identified after scanning the code (or a specified portion of the code). Alternatively, the SAST tool may generate an individual report about each identified vulnerability (e.g., immediately after identifying it).
  • the vulnerability tracker 140 ingests the reports generated by the code scanners and processes them to remove duplicates where the same vulnerability was identified more than once.
  • the vulnerability tracker 140 identifies duplicates by generating fingerprints from the scope and offset of vulnerabilities.
  • the offset may be a normalized offset that excludes non-functional lines of source code when determining the offset.
  • a scope is a (possibly nested) source code block that may contain statements and expressions including definitions/declarations of entities such as variables, functions, classes, structs, types, etc. Scopes limit the visibility of these entities to a part of the program.
  • a scope tag uniquely identifies a scope which is composed of scope elements where a scope element refers to a concept, such as a package, module, namespace, type, class, function definition, etc., which are relevant with respect to scoping.
  • the scope tag is labeled with its corresponding source-code token.
  • the code snippet includes 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 this treats the file containing the source code as a separate scope.
  • the ‘>’ symbol is used herein as a delimiter that separates scope elements. However, any preferred delimiter may be used.
  • An offset indicates the position of a specific piece of code (e.g., a line identified as a vulnerability) within a scope.
  • the offset may be stated as a number that indicates the number of lines of code from the start of a scope to the specific piece of code being identified.
  • the offset is a normalized offset that only counts functional lines of source code in determining the number of lines of code from the start of the scope to the specific piece of code beig idnetified.
  • the normalized offset is a number of functional lines of code from the start of the scope to the specific piece of code being identified.
  • the network 170 provides the communication channels via which the other elements of the networked computing environment 100 communicate.
  • the network 170 can include any combination of local area and wide area networks, using wired or wireless communication systems.
  • the network 170 uses standard communications technologies and protocols.
  • the 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.
  • networking protocols used for communicating via the network 170 include multiprotocol label switching (MPLS), transmission control protocol/fritemet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP).
  • MPLS multiprotocol label switching
  • TCP/IP transmission control protocol/fritemet protocol
  • HTTP hypertext transport protocol
  • SMTP simple mail transfer protocol
  • FTP file transfer protocol
  • FIG. 2 illustrates one embodiment of the vulnerability tracker 140.
  • the 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.
  • the networked computing environment 100 includes different or additional elements.
  • the functions may be distributed among the elements in a different manner than described.
  • the parsing module 210 parses the source code to obtain a parse tree.
  • the parse tree is a structural/hierarchical representation of the source code.
  • the parse tree can indicate libraries, classes, functions, calls, etc. along with the relationships between them.
  • the vulnerability tracking methodology is independent from any specific programming language so any parser that can produce a parse tree from source code may be used.
  • Parsing is the process of deriving a parse tree from source code.
  • the following code snippet shows an example program example.rb including 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 end end
  • the parser is able to understand the syntactic elements of the source code and constructs a hierarchical representation of the code which is called syntax tree or parse tree.
  • FIG. 3 illustrates a simplistic view of a parse tree that may be produced by the parser. For simplicity, the file name parts of the scope labels are omitted in the following description.
  • the parse-tree structure captures the scoping through parent-child node relationships: a parent node, if it represents a scope element, provides a scope to its children. Conversely, the scope of a child node 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.
  • the OuterClass is a node of type ⁇ class>, a node that refers to a class declaration as it appears in the source code.
  • the scope extraction module 220 analyzes the parse tree to identify the scopes present in the source code (source code blocks that cage the visibility of variables and/or functions that are present in the source file).
  • each node in the parse tree corresponds to a scope, and a scope is labeled by traversing the tree back to the root node (e.g., the name of the file containing the code) and adding an identifier of each node parsed through to the label.
  • scope extraction module 220 identifies seven scopes with the following labels, where A > B denotes that scope element B is nested in scope element A:
  • InnerClassA [0] there are two function As, the first one is node 3 with an index number [0], and the second one is node 5 with an index number [1].
  • the scope of node 3 (corresponding to the above item (c)) is same as the scope of node 5 (corresponding to the above item (d)). Thus, a duplicate one may be removed.
  • the scope computation may be done in a depth-first (DF) pre-order traversal.
  • Pre-order traversal enables computation of the parent scope before computing the child scopes, which is an efficient order due to their interdependence.
  • DF depth-first
  • Pre-order traversal enables computation of the parent scope before computing the child scopes, which is an efficient order due to their interdependence.
  • the above scope e
  • OuterClass [0] > InnerClassB [0] (which corresponds to the scope of node 7) is needed to compute the above scope
  • OuterClass [0] > InnerClassB [0] > function_A [0] which corresponds to the scope of node 8).
  • the numerals 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.
  • the scope extraction module 220 relies on a stack of tags (that are computed based on the identified scope elements), as well as a set of tags that captures all the tags that have been generated.
  • the traversal algorithm walks down (descends) the tree irrespective of the node type.
  • the scope extraction module 220 creates a tag 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 irrelevant for scoping may be skipped.
  • the scope extraction module 220 encounters a node of type ⁇ class> which is relevant with regards to scoping as it represents a class declaration. Hence, 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 for the child nodes that the scope extraction module 220 is going to analyze next.
  • the scope extractor encounters a ⁇ funcdef> (a function definition node). The scope extraction module 220 generates a tag by peeking the tag item that was generated last from the stack (OuterClass > InnerClassA).
  • This information is used to generate a new tag item (OuterClass > InnerClassA > function_A). Note that once the scope extraction module 220 is done processing a node, the corresponding tag item is popped from the stack. For example, once the scope extraction module 220 is done with traversal steps 3 and 4, it pops OuterClass > InnerClassA > function_A from the stack so that, at traversal step 5, OuterClass> InnerClassA is the last tag item on the stack.
  • the scope extraction module 220 applies a numbering scheme to the scope elements to enable the generation of unique tags by maintaining an internal counter that tracks how often a scope element has been encountered within a scope. In the case of FIG. 3, the counters are indicated by the numbers enclosed in brackets.
  • the scope extraction module 220 instead of using the same scope tag for function_A that appears twice in InnerClassA, the scope extraction module 220 generates dedicated scope tags for both occurrences with OuterClassfO] > InnerClassA[0] > function_A[0] and OuterClassfO] > InnerClassAfO] > function_A[l].
  • the scope tags produced by the scope extraction module 220 may include source coordinates that capture the scope boundaries, i.e., the start and end source positions of a given scope. For example, the line numbers at which the block of code corresponding to the scope begins and ends may be used to define the scope boundaries.
  • the scope extraction module 220 generates a scope table that includes the scope tag as well as the scope boundary denoted by start and end lines of the scope in the source code.
  • the example scope table below (Table 1) details the scope tags as well as the start and end-lines for the scopes that are contained in the code snippet above.
  • the scope matching module 230 scopes the vulnerabilities that are included in vulnerability reports received from one or more SAST scanners.
  • a vulnerability report may identify the location of a vulnerability by a line number.
  • the scope matching module 230 uses the scope boundaries in conjunction with the line number of the vulnerability to identify the scope that includes/wraps it.
  • scope matching module 230 may identify the narrowest scope that encompasses the reported vulnerability whose position is identified by its source code line (line).
  • 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 values for each scope.
  • Table 2 smatch values for a vulnerability finding on line 25.
  • the matching scope is custom_widget.rb[0] > Widget[0] > Custom Widget[0] > run[0], because line 25 is within the range of this scope (lines 20 to 30) and an smatch value of 10 is the lowest smatch value across all scopes.
  • the fingerprinting module 240 generates fingerprints for identified vulnerabilities using the matching scopes.
  • a fingerprint may also be based on a type or category of the corresponding vulnerability.
  • the fingerprinting module 240 may generate the fingerprint for a vulnerability using one or more of the names of the scope identified by the scope matching module 230 for the vulnerability, the offset for the vulnerability, or a vulnerability classifier.
  • the vulnerability classifier may be a category or type of the vulnerability included in the report received from the SAST.
  • the fingerprinting module 240 generates the fingerprint by calculating a hash value from one or more of the scope, offset, and vulnerability classifier.
  • scope name, offset value, and vulnerability classifier may be concatenated into a text string (possibly with delimiters between parts) that is provided as input to a hash function.
  • a hash function To make hashes comparable across different analyzers, CWEs, CVEs, or OWASP categories may be used.
  • the deduplication module 250 identifies which vulnerabilities are identical based on their fingerprints and removes duplicates to yield a set of refined vulnerabilities.
  • This set of refined vulnerabilities can be stored (e.g., in the vulnerability database 260) as a refined report.
  • the refined report takes up less storage due to the deduplication. It is also more efficient for a data analyst to review the report and address the identified vulnerabilities as they can spend significantly less time accounting for duplicate vulnerabilities.
  • the deduplication of vulnerabilities is performed based on the generated hashes. If two vulnerabilities can be translated to the same fingerprints, they are considered identical. Specifically, if the hashes for two vulnerabilities match, this indicates that they: (1) are located in the same scope; (2) have the same vulnerability type or classification; and (3) have the same offset to the line number where their parent scope begins.
  • the deduplication module 250 may support a feedback mechanism by logging the associated deduplication in the vulnerability databased 260 to enable override or perform further review of the data analyst.
  • custom_widgets.rb if a developer shifts the run function by +100 source code lines, the SAST tool would report the CWE 22 vulnerability with a +100 line difference on line 125. Because the fingerprint hash is generated based on scope and offset, not absolute position (e.g., line number), the deduplication module 250 can deduplicate the vulnerabilities from lines 25 and 125. For both vulnerabilities, the fingerprint hash is identical: custom_widget.rb[0] > Widget[0] > CustomWidget[0] > run[0] > 5 > CWE-22.
  • the offset used is a normalized offset that does not consider nonfunctional lines of code within the scope, such as blank lines or comment lines.
  • Using an offset value that considers all source code lines (non-functional and functional) between the beginning of the scope and the line of the vulnerability makes the scope component sensitive to source code changes that do not affect the program’s functionality, leading to vulnerability duplication where only non-functional differences exist between two instances of essentially the same vulnerability.
  • normalized offsets that exclude non-functional source-code lines to generate the fingerprints can be further reduced.
  • the following example illustrates how duplication of vulnerabilities that are not functionally different can be reduced.
  • the example code that follows includes a path traversal vulnerability on line 6 where it directly passes user input to the Dir .
  • mkdir method 1 module Widget
  • Example 2 example . rb
  • a normalized offset value enables a refined notion of vulnerability equivalence which allows duplicate vulenabilities to be identified.
  • two vulnerabilities are considered equivalent if they: (1) are located in the same scope; (2) have the same vulnerability type; and (3) have the same normalized offset (line number distance) to the line number where their parent scope begins excluding non-functional code lines.
  • start_line not differentiating between non-functional and functional code lines.
  • LOC line of code
  • s(n) and e(n) to express the start and end lines for LOCs that correspond to the syntax tree node n, respectively. Note that there is a one to many (1 :n) mapping between a LOC and syntax tree nodes.
  • a scope can be linked to a node in the syntax tree.
  • countNonFunctionalLines takes two parameters: node (a node in the syntax tree produced by the parsing module 210) and line (the line in the source code where the vulnerability finding is located).
  • node a node in the syntax tree produced by the parsing module 210
  • line the line in the source code where the vulnerability finding is located.
  • the code below uses a counter variable nfloccount for the purpose of counting non functional lines of code. Afterwards the fingerprinting module 240 collects the child nodes for node that are stored in C that provides indexed access to its elements and loop over each child node Ci 6 C.
  • fingerprinting module 240 visits the nodes in the order in which they appear in the source code so that it can be assumed that siblings that are located on the same syntax tree level are ordered with regards to their start and end line numbers. However, it is possible that consecutive nodes share the same source code line number as the mapping from source code to syntax tree nodes is a one to many (1 :n) mapping. Hence, the fingerprinting module 240 only has to process nodes unless and until it checks a node for which s(c t ) > line which implies that it crossed the position of the vulnerability location being evaluated. Every source code line that comes after line is not relevant for the computation of of fse t ormalized •
  • the function countNonFunctionalLinesSpan represents a function that identifies nonfunctional nodes in the syntax tree that correspond to source code location and returns the number of source code lines occupied by non-functional code. It also returns a boolean value represented by the skip variable which defines whether the fingerprinting module 240 can directly proceed with the next child node or should continue the computation with the current child. This is useful for situations where non-functional nodes can be directly mapped to distinct code locations such as newlines where there can be a 1:1 relationship between nodes and source code locations.
  • nfloccount is used to count the source code lines that are occupied by nonfunctional code. This variable is increased by the number of lines returned by countNonFunctionalLinesSpan.
  • the fingerprinting module 240 may recurse into relevant child nodes that represent sub-scopes as they may include additional nonfunctional source code lines. Relevant child nodes may be selected by means of shouldDescend that filters only those nodes that have child nodes and that span more than a single LOC.
  • the fingerprinting module 240 updates nfloccount with the non-functional source code lines that may be included in these sub-scope blocks.
  • the approch assumes that every node in the syntax tree as it is provided parsing module 210 can be mapped to a source code line number by means of s(n) and e(n) that represent start and end source code line for the syntax tree node n with s(n) ⁇ e(n). Since the syntax tree is a hierarchical representation where every parent node subsumes its children, for every child node c x G C of a parent node n, we know that s(c x ) > s(n) and e(c % ) ⁇ e(n).
  • non-functional source code segments are implicit because they are not represented by a syntax tree node and only inferable by looking at the indices. This is usually the case for lines of source code that include newlines.
  • explicit non-functional source code segments are those who can be mapped to concrete syntax tree nodes.
  • the algorithm below accounts for both the implicit and explicit cases. The explicit cases are covered by countNonFunctionalLinesSpan whereas the implicit cases are covered at the bottom of the pseudo code below by computing the gaps between parent and child or sibling child nodes. function countNonFunctionalLines(node, line') ⁇ nfloccount «- 0
  • the i > 0 case covers cases where there can be gaps between siblings which is covered by s(Cj) — (efci-i) + 1).
  • the two expressions t ⁇ and t 2 are siblings as they are on the same level in the syntax tree as they are both children of f.
  • the s(lastChild) ⁇ line covers the third possible implicit case, i.e., a possible gap between the last child node and its scoping node which is covered by e(node) — (e (lastChild) + 1).
  • A is a helper function that computes the overlap between nodes.
  • the mapping between the nodes of syntax tree to source code locations is a many to one n:l mapping.
  • the function A helps to detect these cases by computing the overlap in terms of LOC for two consecutive syntax tree nodes first, second. function A (first, second) ⁇ if e (fir st) ⁇ s (second) ⁇ return 0
  • FIG. 5A illustrates an example parse tree for a code block including non-fiinctional lines of code, according to one embodiment.
  • the parse tree corresponds to Example 1 and illustrates the countNonFunctionalLines algorithm based on the code block for example.rb shown above.
  • the parse tree shows the node types as well as the line ranges that link the node n to the range of LOC in the form [s(n), e(n)] (e.g., module [1, 10]). Every node is assigned a sequence number which we use as a suffix x with n x to refer to a node explicitly.
  • the scoping function node n 3 510 and the vulnerable call, HH 520 are used to demonstrate the operation of countNonFunctionalLines.
  • the scoping function node n 3 510 represents the start of the function that defines the scope of the vulnerable call «n 520, and line 6 corresponds to the location of the vulnerability. Thus, countNonFunctionalLines would be called with countNonFunctionalLines (n 3 , 6).
  • the table below illustrates how the evaluation of countNonFunctionalLines would unfold.
  • the left column sketches the sequence of recursive calls on the various nodes visited as the fingerprinting module 240 traverses the syntax tree.
  • the right column indicates the change of the nfloccount.
  • the value of nfloccount in the last row of the table corresponds to the number of nonfunctional lines of codes that were counted between the beginning of the scope and the line of the vulnerability finding.
  • FIG. 6 is a block diagram of an example computer 600 suitable for use as a client device 120, code scanner 130, or vulnerability tracker 140, or for hosting the source code repository 110.
  • the example computer 600 includes at least one processor 602 coupled to a chipset 604.
  • the chipset 604 includes a memory controller hub 620 and an input/output (I/O) controller hub 622.
  • a memory 606 and a graphics adapter 612 are coupled to the memory controller hub 620, and a display 618 is coupled to the graphics adapter 612.
  • a storage device 608, keyboard 610, pointing device 614, and network adapter 616 are coupled to the VO controller hub 522.
  • Other embodiments of the computer 600 have different architectures.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

Un code source est géré par l'intermédiaire d'un système de gestion de code source et un ou plusieurs outils de balayage de test de sécurité d'application statique vérifient si le code source présente des vulnérabilités. Les outils de balayage génèrent des rapports de vulnérabilités qui sont traités par un outil de suivi des vulnérabilités. L'outil de suivi des vulnérabilités calcule les portées des vulnérabilités identifiés à partir du code source et génère des empreintes digitales de portée et de décalage normalisé (par exemple, des hachages qui identifient de manière unique des vulnérabilités en fonction de leur portée environnante). Les empreintes digitales peuvent être utilisées pour le suivi de déduplication et de vulnérabilité. L'outil de suivi des vulnérabilités peut générer un rapport de vulnérabilités affiné qui contient un ensemble de vulnérabilités dédupliquées avec les empreintes digitales correspondantes. Le rapport de vulnérabilités affiné et les données associées peuvent être stockés dans une base de données de vulnérabilités afin d'être utilisés dans la gestion des vulnérabilités.
PCT/IB2025/057221 2024-07-16 2025-07-16 Suivi des vulnérabilités à l'aide d'une portée et d'un décalage normalisé Pending WO2026018186A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463672125P 2024-07-16 2024-07-16
US63/672,125 2024-07-16

Publications (1)

Publication Number Publication Date
WO2026018186A1 true WO2026018186A1 (fr) 2026-01-22

Family

ID=98436933

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2025/057221 Pending WO2026018186A1 (fr) 2024-07-16 2025-07-16 Suivi des vulnérabilités à l'aide d'une portée et d'un décalage normalisé

Country Status (1)

Country Link
WO (1) WO2026018186A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070245304A1 (en) * 2006-04-13 2007-10-18 Sap Ag Systems and methods for processing non-functional commentary of computer source code
US20100325614A1 (en) * 2003-11-25 2010-12-23 Robert Marc Zeidman Detecting plagiarism in computer source code
KR101780233B1 (ko) * 2016-04-26 2017-09-21 고려대학교 산학협력단 소프트웨어의 코드 클론 탐지 장치 및 방법
US20180034846A1 (en) * 2016-07-29 2018-02-01 Praetorian Group, Inc. Method and system for validating a vulnerability submitted by a tester in a crowdsourcing environment
US20230104814A1 (en) * 2021-09-22 2023-04-06 Gitlab Inc. Vulnerability Tracing Using Scope and Offset

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100325614A1 (en) * 2003-11-25 2010-12-23 Robert Marc Zeidman Detecting plagiarism in computer source code
US20070245304A1 (en) * 2006-04-13 2007-10-18 Sap Ag Systems and methods for processing non-functional commentary of computer source code
KR101780233B1 (ko) * 2016-04-26 2017-09-21 고려대학교 산학협력단 소프트웨어의 코드 클론 탐지 장치 및 방법
US20180034846A1 (en) * 2016-07-29 2018-02-01 Praetorian Group, Inc. Method and system for validating a vulnerability submitted by a tester in a crowdsourcing environment
US20230104814A1 (en) * 2021-09-22 2023-04-06 Gitlab Inc. Vulnerability Tracing Using Scope and Offset

Similar Documents

Publication Publication Date Title
Andow et al. {PolicyLint}: investigating internal privacy policy contradictions on google play
US8307351B2 (en) System and method for performing code provenance review in a software due diligence system
US12086271B2 (en) Vulnerability tracking using smatch values of scopes
US20100241469A1 (en) System and method for performing software due diligence using a binary scan engine and parallel pattern matching
US8984485B2 (en) Analysis of source code changes
US20100185686A1 (en) System and method for providing a license description syntax in a software due diligence system
US7421680B2 (en) Persisted specifications of method pre-and post-conditions for static checking
US20190340229A1 (en) Validating an xml document
van Doorn et al. Maintaining a library of formal mathematics
Göde et al. Studying clone evolution using incremental clone detection
US8606806B2 (en) Static typing of xquery expressions in lax validation content
EP2107457B1 (fr) Système de configuration de logiciel automatique
US20050262482A1 (en) System and method for efficiently analyzing and building interdependent resources in a software project
EP1526448B1 (fr) Procédé et système d'ordinateur pour la création de documents
CN114765559A (zh) 使用cve条目来验证网络设备的漏洞的方法
German et al. cregit: Token-level blame information in git version control repositories
Mitrevski et al. WikiHist. html: English Wikipedia's full revision history in HTML format
US20150278386A1 (en) Universal xml validator (uxv) tool
US20030051216A1 (en) Automatic validation method for multimedia product manuals
CN121008828A (zh) 权限配置方法和装置
WO2026018186A1 (fr) Suivi des vulnérabilités à l'aide d'une portée et d'un décalage normalisé
Kats et al. Providing rapid feedback in generated modular language environments: adding error recovery to scannerless generalized-LR parsing
Cavalieri EX up: an engine for the evolution of XML schemas and associated documents
Le Zou et al. On synchronizing with web service evolution
CN116775116A (zh) 一种非侵入式接口文档自动生成方法、装置、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25840796

Country of ref document: EP

Kind code of ref document: A1