A software security vulnerability intelligent scanning method based on static analysis

Abstract

This invention discloses an intelligent scanning method for software security vulnerabilities based on static analysis, specifically relating to the field of software security testing technology. The method acquires a snapshot of the baseline version source code and a snapshot of the modified version source code corresponding to the software project under test, establishes alignment relationships between program elements of the previous and current versions, and forms a set of modified elements. Combining the baseline version program graph cache, function summary cache, and historical hazard index, a comprehensive quantity of the impact of changes is formed, and a subgraph of the impact of changes is constructed. Static incremental vulnerability analysis is performed on the subgraph of the impact of changes to identify newly added risk paths and activated historical hazard paths, and a trusted comprehensive quantity of risk activation is formed. Based on the trusted comprehensive quantity of risk activation, confirmation screening and baseline updates are performed, and valid incremental alerts or paths awaiting review are output. This invention can narrow the analysis scope, reduce the resource consumption of full scans, and improve the ability to identify incremental vulnerabilities and the activation of historical hazard paths.

Description

Technical Field

[0001] This invention relates to the field of software security detection technology, and more specifically, to a method for intelligent scanning of software security vulnerabilities based on static analysis. Background Technology

[0002] Software security testing technology is primarily used to analyze and test the source code, configuration files, template files, and program structure relationships within a software system. This enables the identification, early warning, and control of security vulnerabilities before software development, version submission, and delivery. It is widely applied in enterprise application development, internet platform development, industrial software development, and the construction of various information systems. Static analysis-based software vulnerability scanning technology, when applied in the software development process, can improve vulnerability detection efficiency and reduce security risks after software deployment.

[0003] Existing technologies have the following shortcomings: Previous software security vulnerability scanning solutions typically perform a full static scan of the software project under test during code submission, merge requests, or version releases to identify security issues such as SQL injection, command execution, insecure template output, dangerous deserialization, and sensitive file operation defects. Although this can complete the overall detection of the software project, it does not fully consider the correlation and impact between the current code changes and existing historical vulnerabilities during the continuous iteration of the software project. In particular, when new propagation relationships are added, purification processes fail, call targets are replaced, condition constraints change, or configuration effectiveness relationships change, dangerous paths that were not previously established, not connected, or not within the effective execution scope may be reactivated due to the current code changes. Existing technologies lack the ability to accurately identify such incremental risks, which can easily lead to problems such as high resource consumption for full scans, insufficient focus of analysis scope, and inadequate identification of historical dangerous path activation scenarios.

[0004] To address the above problems, this invention proposes a solution. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a software security vulnerability intelligent scanning method based on static analysis to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A software security vulnerability intelligent scanning method based on static analysis includes the following steps: Obtain the baseline version source code snapshot and the modified version source code snapshot corresponding to the software project under test. Read the file difference information, function difference information, configuration difference information and dependency declaration change information corresponding to this submission. Perform syntax parsing and structure normalization processing on the baseline version source code snapshot and the modified version source code snapshot. Establish the alignment relationship of corresponding program elements in the previous and current versions. Identify the syntax nodes, function call edges, control dependency edges, data dependency edges and configuration binding edges that have actually changed, and form a set of changed elements. Based on the set of changed elements, and combined with the baseline version program graph cache, function summary cache and historical danger point index, a comprehensive change impact quantity is formed, and a change impact subgraph corresponding to this commit is constructed in the current version program graph; On the change impact subgraph, combined with the vulnerability rule set, taint analysis specification, baseline version program graph cache, function summary cache and historical alarm index that match the software project under test, static incremental vulnerability analysis is performed to identify new risk paths directly introduced by this code change and historical dangerous paths activated by this code change, and a risk activation credible comprehensive quantity is formed based on the change through impact comprehensive quantity, path reachability confirmation parameters and baseline difference activation parameters; Based on the aforementioned risk activation trusted comprehensive quantity, candidate incremental risk paths are confirmed, screened, and baselines are updated to obtain valid incremental alarms or paths to be reviewed related to this submission, and the baseline version program graph cache, function summary cache, historical danger point index, and historical alarm index are updated.

[0007] In a preferred embodiment, when the software project under test is included in the scan for the first time or when the existing analysis baseline corresponding to the current submission does not exist, the baseline version source code snapshot is used as the initial analysis baseline. The same syntax parsing and structure normalization processing as the changed version source code snapshot is performed on the baseline version source code snapshot to generate an initial baseline version program graph cache, an initial function summary cache and an initial historical danger point index, and the historical alarm index is initialized to empty.

[0008] In a preferred embodiment, the set of changed elements includes at least newly added propagation edges, deleted purification edges, replaced call edges, condition constraint change nodes, and configuration effective relationship change nodes. Simultaneously with forming the set of changed elements, newly added propagation edge parameters, purification weakening parameters, and historical danger adjacency parameters are extracted to form the comprehensive quantity of the change's overall impact. The newly added propagation edge parameters characterize whether the current code change has added a propagation relationship that can drive external input to continue propagating towards historical danger points. The purification weakening parameters characterize whether the current code change has deleted, bypassed, or weakened the original purification and constraint processing. The historical danger adjacency parameters characterize the degree of adjacency between the changed node and the historical danger point.

[0009] In a preferred embodiment, a current version program graph is constructed based on a snapshot of the changed version source code. The current version program graph includes at least abstract syntax tree relationships, control flow relationships, data dependency relationships, function call relationships, and configuration binding relationships. Variable placeholder nodes and output nodes in the template file, as well as SQL fragment nodes, dynamic condition nodes, and parameter reference nodes in the mapping file, are mapped to program elements. For cases where the call target, configuration effective branch, or template variable source cannot be uniquely determined in the static phase, all candidate association edges that satisfy semantic constraints are retained. A comprehensive judgment is made based on the newly added propagation edge parameters, the purification and weakening parameters, and the historical dangerous adjacency parameters to form the comprehensive change impact quantity.

[0010] In a preferred embodiment, the changed nodes and edges in the set of changed elements are used as expansion seeds. An affected scope expansion is performed in the current version of the program graph to construct the change impact subgraph. The affected scope expansion searches outwards along function call relationships, parameter passing relationships, return value passing relationships, object field read / write relationships, data dependency relationships, control dependency relationships, and configuration binding relationships for program nodes associated with the expansion seeds. The expansion depth and direction are controlled by the comprehensive change impact quantity. Historical input entry points, historical danger points, and historical nodes whose semantics have changed due to replacement of call edges, condition constraint change nodes, or configuration effect change nodes that have a propagation relationship with the expansion seeds are included in the change impact subgraph.

[0011] In a preferred embodiment, based on the programming language, framework type, template mechanism, database access method, and configuration file format of the software project under test, a matching vulnerability rule set and taint analysis specification are loaded. The vulnerability rule set is used to identify dangerous function calls, insecure string concatenation, dangerous deserialization entry points, path concatenation defects, missing authentication verification segments, dangerous configuration combinations, and situations where necessary constraints are lacking before sensitive operations. The taint analysis specification includes at least taint source definitions, taint sink definitions, propagation relationship definitions, and cleanup definitions.

[0012] In a preferred embodiment, a structural matching scan is first performed on the change impact subgraph to form a first candidate alarm set. Then, taint propagation analysis is performed using external input entry points included in the change impact subgraph as taint sources and dangerous execution points included in the change impact subgraph as taint sinks. During the propagation process, the purification status of purification processing nodes in the candidate paths is determined, and the impact of nodes with changed condition constraints and nodes with changed configuration effectiveness on the path establishment conditions is recorded to identify the following incremental risks: the incremental risk that the addition of propagation edges in this code change makes historical dangerous points reachable by externally controllable inputs for the first time; the incremental risk that the deletion of purification processing, weakening of condition constraints, or change of calling targets in this code change makes historically restricted dangerous paths re-established; and the incremental risk that the change of configuration effectiveness in this code change makes historically dangerous execution chains that were not in the effective execution range enter the actual execution range of the current version.

[0013] In a preferred embodiment, the path reachability confirmation parameter is used to characterize whether a candidate path meets the conditions for establishment in the modified version; the baseline difference activation parameter is used to characterize the state difference of the same candidate path in the baseline version and the modified version, and is determined according to the following rules: if there is no corresponding propagation path in the baseline version, or although there are local nodes, the whole is not connected, but the path is formed for the first time in the modified version, then the baseline difference activation parameter is set to 1; if there is a corresponding path in the baseline version but it is in a restricted state, but it is transformed into a valid state in the modified version due to the failure of purification processing, the weakening of branch constraints, or the change of configuration effectiveness relationship, then the baseline difference activation parameter is set to 0.5; if the path states in the baseline version and the modified version are basically the same, then the baseline difference activation parameter is set to 0; and the risk activation credible comprehensive quantity is formed based on the comprehensive quantity of the change connectivity impact, the path reachability confirmation parameter, and the baseline difference activation parameter.

[0014] In a preferred embodiment, the candidate incremental risk path set is confirmed and screened one by one, with the risk activation credibility comprehensive quantity as the main judgment basis, and combined with the position of the candidate path in the change impact subgraph, the type of key nodes passed through the path, and the correspondence between the path and the historical alarm index for comprehensive judgment; the screening results are divided into valid incremental alarms, paths to be reviewed, and invalid paths or historical old alarms that are not directly related to this submission; and the confirmed valid incremental alarms are classified into three categories: new danger point alarms, old danger point activation alarms, and old alarm risk escalation alarms.

[0015] In a preferred embodiment, during baseline updates, a corresponding alarm identifier is generated for each valid incremental alarm or path to be reviewed; if a corresponding record does not exist in the historical alarm index, a new record is added; if a corresponding record already exists in the historical alarm index, its impact path summary, handling status, and most recent submission identifier are updated; for newly added hazards and activated old hazards that need to be written back to the new analysis baseline, they are written to the historical hazard index; for functions or methods affected by this submission, their input acceptance characteristics, output propagation characteristics, cleanup characteristics, and hazard call characteristics are updated based on the confirmed path propagation results, and written back to the function summary cache; for historical hazard path records that are no longer valid and have been confirmed to be repaired, they are deleted from the new analysis baseline, or their status is updated to repaired.

[0016] The technical effects and advantages of this invention are as follows: Compared to performing a full static scan of the software project under test, this invention first aligns the baseline version source code snapshot with the modified version source code snapshot to form a set of changed elements. Then, it combines the baseline version program graph cache, function summary cache, and historical hazard index to form a comprehensive change impact metric. Based on this, it constructs a subgraph of the change impact corresponding to the current commit, thereby focusing the analysis on program nodes, propagation relationships, and historical hazard areas that are actually related to the current code change. This approach reduces redundant analysis of irrelevant code areas, lowers resource consumption from full scans, improves vulnerability scanning efficiency, and enhances the accuracy of locating risks related to the current commit. Furthermore, this invention not only identifies new risk paths directly introduced by the current code change but also identifies situations where historical hazard paths are re-established or enter the actual execution scope of the current version due to the addition of propagation edges, deletion of purification edges, replacement of call edges, changes in conditional constraint nodes, or changes in configuration effectiveness nodes. Therefore, it improves the ability to identify historical hazard path activation issues and enhances the detection effect of incremental risks in continuous iteration scenarios.

[0017] Furthermore, this invention performs static incremental vulnerability analysis on the change impact subgraph by combining vulnerability rule sets and taint analysis specifications. It also forms a risk activation confidence comprehensive quantity based on the change impact comprehensive quantity, path reachability confirmation parameters, and baseline difference activation parameters. This provides a clearer basis for confirming and screening candidate incremental risk paths, enabling the differentiation between valid incremental alerts, paths awaiting review, and historical alerts unrelated to the current submission. Valid incremental alerts are further categorized into three types: newly added hazard alerts, old hazard activation alerts, and old alert risk escalation alerts. This benefits, on the one hand, by reducing the interference of false positives and irrelevant old alerts on the current submission judgment, improving the usability of alert output results and the targeting of access control; on the other hand, by writing back and updating the historical hazard index, function digest cache, and historical alert index, a continuous closed loop for subsequent submissions is formed. This allows the updated analysis baseline to be directly reused when the next submission triggers static incremental vulnerability analysis, thus ensuring the continuity and reusability of subsequent scans while improving the long-term identification capability of combined vulnerabilities and continuously evolving risks. Attached Figure Description

[0018] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings; Figure 1 This is a flowchart illustrating an intelligent software security vulnerability scanning method based on static analysis according to the present invention. Figure 2 This is a schematic diagram illustrating the code change extraction and baseline information alignment of the present invention; Figure 3 This is a schematic diagram illustrating the formation of the comprehensive impact of changes on the connection and the construction of the sub-diagram of changes in the present invention; Figure 4 This is a schematic diagram illustrating the static incremental vulnerability analysis and risk activation path identification of this invention; Figure 5 This is a schematic diagram illustrating the incremental alarm confirmation, classification output, and baseline update analysis of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example 1: This invention provides an intelligent software security vulnerability scanning method based on static analysis, such as... Figure 1 As shown, it includes the following steps: Step 1: Obtain the baseline version source code snapshot and the modified version source code snapshot corresponding to the software project under test. Read the file difference information, function difference information, configuration difference information and dependency declaration change information corresponding to this submission. Perform syntax parsing and structure normalization processing on the baseline version source code snapshot and the modified version source code snapshot. Establish the alignment relationship of corresponding program elements in the previous and current versions. Identify the syntax nodes, function call edges, control dependency edges, data dependency edges and configuration binding edges that have actually changed, and form a set of changed elements. Step 2: Based on the set of changed elements, and in combination with the baseline version program graph cache, function summary cache, and historical danger point index, a comprehensive change impact quantity is formed, and a change impact subgraph corresponding to this commit is constructed in the current version program graph; Step 3: On the change impact subgraph, combine the vulnerability rule set, taint analysis specification, baseline version program graph cache, function digest cache and historical alarm index that match the software project under test, and perform static incremental vulnerability analysis to identify new risk paths directly introduced by this code change and historical dangerous paths activated by this code change, and form a risk activation credible comprehensive quantity based on the change through impact comprehensive quantity, path reachability confirmation parameters and baseline difference activation parameters; Step 4: Based on the risk activation trusted comprehensive quantity, confirm and screen the candidate incremental risk paths and update the baseline to obtain the valid incremental alarms or paths to be reviewed related to this submission, and update the baseline version program graph cache, function summary cache, historical danger point index and historical alarm index.

[0021] Specifically: Step 1: As Figure 2 As shown, the process first involves obtaining a baseline version source code snapshot and a modified version source code snapshot for the software project under test. The baseline version source code snapshot is the existing version code set before the current commit, and the modified version source code snapshot is the current version code set containing the content of this commit. Both can be obtained by the code hosting platform based on the commit identifier, branch identifier, or merge request identifier.

[0022] Simultaneously, the file difference information, function difference information, configuration difference information, and dependency declaration change information corresponding to this commit are read to form the original changeset. The file difference information is used to represent the addition, deletion, and modification of files; the function difference information is used to represent the addition, deletion, and replacement of functions, methods, or class members; the configuration difference information is used to represent changes in configuration keys, configuration values, route exposure conditions, environment switches, or profile activation conditions; and the dependency declaration change information is used to represent changes in dependency library versions, dependency coordinates, or plugin configurations.

[0023] After obtaining the above input, syntax parsing and structure normalization are performed on the baseline version source code snapshot and the modified version source code snapshot, respectively. Classes, functions, methods, basic blocks, conditional statements, call statements, assignment statements, return statements, external input entries, database access statements, template output statements, command call statements, file operation statements, and configuration key-value items in source code files, configuration files, template files, and mapping files are uniformly mapped into comparable program elements. Alignment relationships between corresponding program elements in the previous and current versions are established based on file paths, symbol signatures, syntax positions, and semantic types.

[0024] In this embodiment, to ensure that the baseline version program graph cache, function summary cache, historical danger point index, and historical alarm index read in subsequent steps have a clear source, when the software project under test is included in the scan for the first time or when the existing analysis baseline corresponding to the current submission does not exist, the baseline version source code snapshot is used as the initial analysis baseline. The same syntax parsing and structure normalization processing as the changed version source code snapshot is performed on the baseline version source code snapshot to generate the initial baseline version program graph cache, initial function summary cache, and initial historical danger point index, and the historical alarm index is initialized to empty.

[0025] Specifically, each program node in the baseline version program graph cache preferably records at least the node identifier, file path, symbol signature, syntax location, semantic type, and the identifier of the function or method to which it belongs; each associated edge preferably records at least the edge type, starting node identifier, ending node identifier, and edge direction; each summary record in the function summary cache preferably records at least the function or method identifier, input acceptance characteristics, output propagation characteristics, cleanup processing characteristics, dangerous call characteristics, return value propagation characteristics, object field read / write characteristics, and configuration effective conditions; each index record in the historical danger point index preferably records at least the danger point type, danger point location, the identifier of the function or method to which it belongs, the identifier of the nearest upstream external input entry, and adjacent call chain information; each index record in the historical alarm index preferably records at least the alarm identifier, alarm type, affected path summary, changed node location, historical danger point location, handling status, and corresponding submission identifier.

[0026] By using the above methods, the baseline version program graph cache, function summary cache, historical danger point index, and historical alarm index called in subsequent steps all have clear generation methods and clear record content.

[0027] After alignment is completed, the syntax nodes, function call edges, control dependency edges, data dependency edges, and configuration binding edges that have actually changed are identified, and the changes that are directly related to vulnerability propagation and path establishment are further grouped into a set of change elements. The set of change elements includes at least new propagation edges, deleted purification edges, replaced call edges, condition constraint change nodes, and configuration effect relationship change nodes.

[0028] Among them, newly added propagation edges are used to represent data dependency edges, parameter passing edges, return value passing edges, object field writing edges, function call edges, or configuration binding edges added in the changed version that can further propagate data downwards; deleted purification edges are used to represent the disappearance of protection relationships caused by the deletion, bypassing, or invalidation of the original purification, verification, or constraint processing in the changed version; replaced call edges are used to represent the replacement of the original call target with a new call target, which may change the existing function summary and propagation semantics; condition constraint change nodes are used to represent changes in the original condition judgment, authentication judgment, null value judgment, or environment judgment that restricts the path to be valid; configuration effectiveness relationship change nodes are used to represent changes in the original route exposure conditions, environment switches, function switches, or profile effectiveness conditions.

[0029] While forming the set of changed elements, three parameters are simultaneously extracted to form the comprehensive impact of the change: the new propagation edge parameter, the purification and weakening parameter, and the historical danger adjacency parameter. The new propagation edge parameter, denoted as E, characterizes whether this code change has added a propagation relationship that can drive external input to continue propagating towards the historical danger point. The new propagation edge parameter is obtained by comparing the newly added data dependency edges, parameter passing edges, return value passing edges, object field writing edges, function call edges, and configuration binding edges in the baseline version program graph and the changed version program graph, and is valued as follows: when no new propagation edge connecting the external input side node and the downstream processing node is found, E=0; when a new propagation edge exists, and the new propagation edge only advances the external input side node to the intermediate processing node but has not yet entered the historical danger point neighborhood, E=0.5; when at least one new propagation edge forms a connection between the external input entry point and the historical danger point neighborhood for the first time, E=1.

[0030] The purification weakening parameter, denoted as S, is used to characterize whether the current code change has deleted, bypassed, or weakened the original purification and constraint processing. The purification weakening parameter is obtained by comparing the changes in purification function calls, validation statements, branch constraint statements, and their call order on the candidate paths between the previous and current versions, and is assigned values ​​as follows: S=0 when there are no substantial changes in purification function calls, validation statements, and branch constraints between the previous and current versions; S=0.5 when purification functions still exist, but the call conditions are relaxed, the call order is changed, or a bypass branch that can bypass purification appears; and S=1 when purification function calls are deleted, purification functions are replaced with non-purified functions, necessary validation statements are removed, or the original strong constraints are canceled.

[0031] The historical danger adjacency parameter, denoted as A, characterizes the adjacency degree between the changed node and historical danger points. This parameter is obtained by matching the changed node with the shortest hop count between it and cached historical danger SQL execution points, template output points, command execution points, sensitive file operation points, and deserialization usage points in the baseline version. Let the set of changed nodes be... The set of historical danger points is Any changing node To any historical danger point The shortest association hop count is denoted as Take the minimum value among all combinations. When no valid association path exists, let A=0; when a valid association path exists, follow the formula: ; Calculate the historical dangerous adjacency parameters, where, The smaller the value, the closer the changing node is to the historical danger point, and the larger the historical danger adjacency parameter; when the changing node is the direct upstream node of the historical danger point, there is usually... At this point, A=0.5; when the changing node and the historical danger point are at the same node or equivalent direct location, it can be set as follows: At this point, A=1.

[0032] This step outputs a set of changed elements, along with new propagation edge parameters E, purification and weakening parameters S, and historical danger adjacency parameters A. This ensures that before proceeding to the subsequent scope construction, the scan has extracted the structured change objects and their quantified parameters that are directly related to the security propagation relationship from the differences between the previous and current versions.

[0033] Step Two: As Figure 3As shown, the set of changed elements output in step one, the newly added propagation edge parameter E, the purification and weakening parameter S, and the historical danger adjacency parameter A are used as inputs. Combined with the source code snapshot of the changed version, the baseline version program graph cache, the function summary cache, and the historical danger point index, a comprehensive change impact quantity is formed. Based on this, a change impact subgraph corresponding to this submission is constructed.

[0034] First, a program graph for the current version is constructed based on the changed version source code snapshot. The current version program graph includes at least abstract syntax tree relationships, control flow relationships, data dependency relationships, function call relationships, and configuration binding relationships. Variable placeholder nodes and output nodes in the template file, as well as SQL fragment nodes, dynamic condition nodes, and parameter reference nodes in the mapping file, are also uniformly mapped to program elements and then connected to source code nodes through reference relationships.

[0035] When constructing the current version of the program graph, unique node identifiers are generated for each comparable program element obtained after structural normalization, and related edges are established according to program semantics. Specifically, abstract syntax tree relationships are used to connect parent and child syntax nodes; control flow relationships are used to connect sequential execution nodes, branch jump nodes, and loop back edge nodes; data dependency relationships are used to connect variable definition nodes and variable usage nodes, parameter actual parameter nodes and formal parameter nodes, and return value generation nodes and return value receiving nodes; object field read / write relationships are used to connect object field write nodes and object field read nodes; function call relationships are used to connect the calling point and the entry node of the called function or method; and configuration binding relationships are used to connect configuration key-value items, route exposure conditions, environment switches, function switches, or profile activation conditions with the program nodes controlled by them.

[0036] For variable placeholder nodes and output nodes in the template file, the variable placeholder nodes are associated with the upstream program nodes that generate the corresponding variable content, and the output nodes are associated with the actual template output locations. For SQL fragment nodes, dynamic condition nodes, and parameter reference nodes in the mapping file, they are associated with the corresponding database access statements, parameter input nodes, or configuration key-value items. In cases where the call target, configuration effective branch, or template variable source cannot be uniquely determined in the static phase, it is preferable to retain all candidate association edges that satisfy semantic constraints, so that subsequent static incremental vulnerability analysis can continue to be executed in a conservative manner, thereby avoiding the premature deletion of potential risk paths when constructing the change impact subgraph.

[0037] Simultaneously, the baseline version program graph cache, function summary cache, and historical hazard index are read. The baseline version program graph cache represents the existing connections between program nodes in the software project under test before this commit. The function summary cache records the input acceptance characteristics, output propagation characteristics, cleanup characteristics, and dangerous call characteristics of each function or method in the baseline version. The historical hazard index records the location, associated function, and adjacent call chain information of historically identified dangerous SQL execution points, template output points, command execution points, sensitive file operation points, and deserialization usage points in the baseline version.

[0038] After obtaining the current version of the program graph and the aforementioned baseline cache, the newly added propagation edge parameter E, the purification and weakening parameter S, and the historical dangerous adjacency parameter A are comprehensively determined to form the comprehensive impact of the change, denoted as G. To ensure simplicity and reproducibility, this embodiment uses a weighted summation method to calculate G, and the calculation formula is as follows: ; in, , and These are the weight coefficients for the newly added propagation edge parameter E, the purification and weakening parameter S, and the historical dangerous adjacency parameter A, respectively, and they satisfy: Parameter E characterizes the degree to which the newly added propagation edge connects to the existing risk structure; parameter S characterizes the degree to which the original purification and constraint treatments are weakened; and parameter A characterizes the degree to which the changed node is close to the historical danger point. In practical applications, the parameters can be adjusted according to different project types, framework types, or vulnerability types. , and The value of is adjusted. In this embodiment, as an example, is taken as . , , .

[0039] After obtaining the comprehensive impact G of the change and connection, its level is determined using a threshold-based classification method. Let the high threshold be... The middle threshold is ,and .when When the overall impact of the change on the connection is determined to be high; when When, the comprehensive impact of the change on the connection is determined to be medium; when At that time, the overall impact of the change on the connection was determined to be low. In this embodiment, as an example, we take... , .

[0040] After the comprehensive impact of the change is formed, the changed nodes and edges in the set of changed elements are used as expansion seeds. The affected scope is expanded in the current version of the program graph to construct a change impact subgraph. During expansion, program nodes associated with the expansion seeds are searched outwards along function call relationships, parameter passing relationships, return value passing relationships, object field read / write relationships, data dependency relationships, control dependency relationships, and configuration binding relationships, and these program nodes are included in the affected node set.

[0041] The depth and direction of expansion are controlled by the comprehensive impact G of the change. When G is high, expansion proceeds bidirectionally upstream and downstream along the expansion seed, including historical input points and historical risk points that have a propagation relationship with the expansion seed. When G is medium, expansion is prioritized within the same call chain, the same business module, and adjacent call levels. When G is low, only program nodes with a direct call relationship, direct data dependency relationship, or direct control dependency relationship with the expansion seed are retained.

[0042] During the expansion process, historical input points located upstream of the expansion seed and capable of transmitting externally controllable data to the changed nodes should be included in the affected node set. Historical dangerous points located downstream of the expansion seed and identified in the baseline version as historically dangerous SQL execution points, template output points, command execution points, sensitive file operation points, or deserialization usage points should also be included in the affected node set. Historical nodes that, although not directly modified, have semantic changes in their function summary, effective conditions, or call targets due to the replacement of call edges, changes in configuration effective relationships, or changes in condition constraints, should also be included in the affected node set.

[0043] Finally, the affected node set and its internal associated edges are extracted to form a change impact subgraph. This step outputs a comprehensive change impact G and a change impact subgraph. The comprehensive change impact G characterizes the extent to which this code change affects the existing risk structure, while the change impact subgraph serves as the actual analysis scope for subsequent static incremental vulnerability analysis.

[0044] Step 3: As Figure 4 As shown, the change impact subgraph and the change-through impact comprehensive quantity G output in step two are used as basic inputs. Combined with the vulnerability rule set, taint analysis specification, baseline version program graph cache, function summary cache and historical alarm index that match the software project under test, static incremental vulnerability analysis is performed on the change impact subgraph to identify the new risk paths directly introduced by this code change and the historical dangerous paths activated by this code change, and a risk activation trusted comprehensive quantity is formed on this basis.

[0045] First, based on the programming language, framework type, template mechanism, database access method, and configuration file format of the software project under test, a matching vulnerability rule set and taint analysis specification are loaded. The vulnerability rule set is used to identify dangerous function calls, insecure string concatenation, dangerous deserialization entry points, path concatenation defects, missing authentication verification segments, dangerous configuration combinations, and situations where necessary constraints are lacking before sensitive operations. The taint analysis specification includes at least taint source definitions, taint sink definitions, propagation relationship definitions, and cleanup definitions. The taint source includes at least HTTP request parameter binding points, message consumption entry points, file upload entry points, deserialization input entry points, and configuration injection entry points. The taint sink includes at least SQL execution points, template rendering points, command execution points, file sensitive operation points, and deserialization usage points.

[0046] In this embodiment, the vulnerability rule set and taint analysis specification can be stored in a structured rule item format and organized according to programming language, framework type, template mechanism, database access method, and configuration file format. Each vulnerability rule item preferably includes at least a rule identifier, applicable language, applicable framework, dangerous function call pattern, dangerous configuration pattern, necessary constraint pattern, alarm type, and alarm level; each taint analysis specification preferably includes at least a taint source definition, a taint sink definition, allowed propagation associated edge types, cleanup treatment definition, and path fulfillment constraints.

[0047] Taking SQL execution point related rules as an example, when the input source of the database access statement includes an external input entry, and there is no still valid purification processing node on the candidate path, or although there is a purification processing node, the deletion of the purification edge in step one indicates that the purification processing node has been deleted, bypassed, or weakened, the corresponding path will be matched as a candidate risk path; taking template output point related rules as an example, when the upstream data of the template output node comes from an external input entry and does not pass through a purification processing node used to eliminate dangerous outputs, the corresponding path will be matched as a candidate risk path; taking command execution point related rules as an example, when the parameters of the command execution point come from an external input entry, and there is no still valid constraint processing or purification processing on the path, the corresponding path will be matched as a candidate risk path.

[0048] In this way, the vulnerability rule set and taint analysis specification not only have category definitions, but also have a rule item structure and matching criteria that can be directly executed.

[0049] After loading, a structural matching scan is first performed in the change impact subgraph to match dangerous function calls, insecure string concatenation, dangerous deserialization entry points, path concatenation defects, missing authentication verification fragments, and dangerous configuration combinations, forming a first candidate alarm set. Subsequently, using external input entry points included in the change impact subgraph as taint sources and dangerous execution points included in the change impact subgraph as taint sinks, taint propagation analysis is performed along function call relationships, parameter passing relationships, return value passing relationships, object field read / write relationships, data dependency relationships, and configuration binding relationships.

[0050] During the propagation process, the purification status of purification nodes in the candidate paths is determined. If the deletion of purification edges in step one indicates that a purification call on a certain path has been deleted, bypassed, or weakened, then the corresponding path is no longer considered a purified path. For nodes with changed condition constraints and nodes with changed configuration effectiveness, their impact on the path's validity conditions is recorded to determine whether a path has changed from a restricted state to a valid state. Through the above process, three types of incremental risks are identified: the incremental risk that the addition of propagation edges in this code change makes historically dangerous points reachable by externally controlled input for the first time; the incremental risk that the deletion of purification processes, weakening of condition constraints, or change of call targets in this code change makes historically restricted dangerous paths re-established; and the incremental risk that changes in configuration effectiveness relationships in this code change allows historically dangerous execution chains that were not previously within the effective execution scope to enter the actual execution scope of the current version.

[0051] After completing rule matching and taint propagation analysis, three parameters constituting the risk activation credibility comprehensive quantity are extracted. The first parameter is the change-through impact comprehensive quantity G, which characterizes whether the region where the current candidate path is located belongs to the risk structure that has been reopened by this code change. The second parameter is the path reachability confirmation parameter, denoted as C, which characterizes whether the candidate path meets the conditions for success in the changed version. Let the number of nodes that allow the path to continue to succeed be 1 out of the total number of key constraint nodes related to the success of a candidate path. The number of nodes that clearly indicate the path blocking continues is Then, according to the formula: ; The calculation path reachability parameters have been confirmed. Among them, This includes condition judgment nodes where the branch direction and path propagation are consistent, environment switch nodes that are in the open state, configuration activation nodes that allow entry, and authentication judgment nodes that do not block propagation. This includes essential authentication nodes that clearly block path propagation, necessary purification nodes that remain valid, necessary environment switch nodes that are closed in the current version, and key condition judgment nodes that conflict with the path propagation direction; the constant 1 in the denominator is used to avoid division by zero when the number of nodes is extremely small.

[0052] The third parameter is the baseline difference activation parameter, denoted as D, which characterizes the state difference of the same candidate path in the baseline version and the modified version. The baseline difference activation parameter is determined by finding the baseline version path corresponding to the current candidate path using the baseline version program graph cache and function digest cache: if there is no corresponding propagation path in the baseline version, or although there are local nodes, the whole is not connected, but the path is formed for the first time in the modified version, then D=1; if there is a corresponding path in the baseline version but it is in a restricted state, but it is transformed into a valid state in the modified version due to the failure of purification processing, weakening of branch constraints, or changes in configuration effectiveness, then D=0.5; if the path states in the baseline version and the modified version are basically the same, then D=0.

[0053] After extracting the above three parameters, a comprehensive judgment is made to form the risk activation credibility comprehensive quantity, denoted as R. The risk activation credibility comprehensive quantity is calculated according to the following formula: ; in, , and These are the weighting coefficients for the comprehensive impact of the change on connectivity G, the path reachability confirmation parameter C, and the baseline difference activation parameter D, respectively, and they satisfy the following: ; Parameter G reflects the degree to which this code change permeates the existing risk structure; parameter C reflects the static reachability of the candidate path in the current version; and parameter D reflects the activation difference of the candidate path relative to the baseline version. In practical applications, the parameters can be adjusted based on the business type of the software project under test, historical false alarms, or security policies. , and The value of is adjusted. In this embodiment, as an example, is taken as . , , .

[0054] After obtaining the risk activation confidence comprehensive quantity R, its level is determined using a threshold classification method. Let the high threshold be... The middle threshold is ,and .when When the risk activation credible comprehensive quantity is determined to be high; when When, the risk activation credible comprehensive quantity is determined to be medium; when At that time, the risk activation trusted comprehensive quantity is determined to be low. In this embodiment, as an example, we take... , .

[0055] Subsequently, the analysis results were merged and filtered by combining the historical alarm index. Historical old alarms that were irrelevant to this submission and whose status had not changed substantially were removed. New risk paths directly introduced by this submission and historical dangerous paths activated by this submission were retained, thus forming a set of candidate incremental risk paths and the corresponding risk activation confidence comprehensive quantity R.

[0056] Step Four: As Figure 5 As shown, the candidate incremental risk path set, risk activation confidence comprehensive quantity R, change impact subgraph, baseline version program graph cache, function summary cache, historical danger point index, historical alarm index, and preset scanning strategy parameters output in step three are used as inputs to confirm, filter, classify and output, and update the baseline of the candidate risk paths related to this submission.

[0057] First, each candidate incremental risk path in the set is screened and confirmed. During the screening, the risk activation confidence comprehensive quantity R is used as the primary criterion, combined with the candidate path's position in the change impact subgraph, the types of key nodes traversed by the path, and its correspondence with historical alarm indices for a comprehensive judgment. Let the effective incremental alarm confirmation threshold be... The threshold for review is ,and .when When, the corresponding candidate path is determined to be a valid incremental alarm; when Furthermore, if the candidate path still has a clear connection to the current code change in its path structure, the corresponding candidate path is determined as the path to be reviewed; when If there is no substantial change in the path status compared to the baseline version, then the corresponding candidate path is determined to be an invalid path or a historical old alarm that is not directly related to this submission.

[0058] In this embodiment, to ensure consistency with the classification results of the risk activation credible comprehensive quantity, as an example, we can take... , That is, take , In other implementations, it can also be set independently according to the actual access control strategy. and The specific value to be taken.

[0059] After confirmation and screening, the confirmed valid incremental alarms are categorized into three types: newly added hazard alarms, old hazard activation alarms, and old alarm risk escalation alarms. Newly added hazard alarms refer to alarms where a dangerous execution point or a complete dangerous call structure appears for the first time in the changed version, and a corresponding dangerous path does not exist in the baseline version. Old hazard activation alarms refer to alarms where the hazard already existed in the baseline version, but due to changes in propagation relationships, cleanup processes, condition constraints, or configuration effectiveness, it becomes accessible from externally controlled input for the first time in the changed version. Old alarm risk escalation alarms refer to alarms where a local or weakly risky path already existed in the baseline version, but after this submission, the path changes from a local hit to a complete propagation path, from restricted to reachable, or its hazard exposure range significantly expands.

[0060] After classification, alarm output results are generated. These output results include at least the alarm identifier, alarm type, file path, function or method identifier, location of the changed node, summary of the affected path, location of historical danger points, description of key changed objects, and suggested repair locations. Based on this, access control and alarm write-back are performed according to preset scanning strategy parameters.

[0061] To ensure that the updating process of the historical alarm index, function summary cache, and historical danger point index has a repeatable operational approach, when performing alarm write-back, a corresponding alarm identifier is generated for each valid incremental alarm or path to be reviewed, and an index key is formed according to the alarm type, the file path to which it belongs, the identifier of the function or method to which it belongs, the location of the changed node, and the location of the historical danger point. When the same index key does not exist in the historical alarm index, a corresponding record is added; when the same index key already exists in the historical alarm index, its corresponding impact path summary, handling status, and most recent commit identifier are updated.

[0062] For newly added hazards and activated old hazards that need to be written back to the new analysis baseline, their hazard type, hazard location, function or method identifier, and adjacent call chain information are written to the historical hazard index. For functions or methods affected by this commit, their input acceptance characteristics, output propagation characteristics, cleanup characteristics, and hazard call characteristics are updated synchronously based on the confirmed path propagation results, and written back to the function summary cache. For historical hazard path records that are no longer valid and have been confirmed to be repaired, they are deleted from the new analysis baseline or their status is updated to repaired.

[0063] By using the above method, when the next submission triggers static incremental vulnerability analysis, the updated baseline version program graph cache, function digest cache, historical danger point index, and historical alarm index can be directly reused.

[0064] The scanning strategy parameters include at least risk thresholds, blocking conditions, alert conditions, output targets, and write-back methods. When a valid incremental alarm reaches a preset risk threshold or belongs to a preset alarm type that must be blocked, the current submission is marked as failing the security access control, and a summary of the alarm's impact path and a description of key changed objects are output on the corresponding platform page. When a valid incremental alarm does not meet the blocking conditions but still requires an alert, the submission is allowed to continue, but the corresponding alarm is written back to the code hosting platform or defect tracking platform as a warning message. For paths awaiting review, it is preferable not to directly trigger blocking, but to write them back as pending confirmation records.

[0065] After developers complete the repair, rejection, acceptance of risks, or confirmation of false alarms, the baseline version's program graph cache, function summary cache, historical hazard index, and historical alarm index are updated based on the final handling results. For repaired alarms, their corresponding historical hazard path records must be deleted or replaced in the new baseline version, and the propagation summary and cleanup status of the relevant functions must be updated. For confirmed false alarms, their false alarm status must be recorded in the historical alarm index, and their corresponding change node characteristics, path structure characteristics, and rule hit characteristics must be saved so that similar paths will have lower priority when determining the trustworthy comprehensive quantity of risk activation in the future. For accepted risk alarms, their records must be retained in the historical alarm index and marked as known risks so that if the known risks continue to escalate due to new code changes, they can still be recaptured in incremental scans. At the same time, the newly added hazards, activated old hazards, and updated function summaries involved in the valid incremental alarms confirmed this time should be written back to the new analysis baseline so that when the next submission triggers an incremental scan, the program state after the previous processing can be used as the new baseline version.

[0066] Through the above steps, a continuous closed loop is formed, which includes extracting code changes, generating a comprehensive measure of the impact of changes and constructing a subgraph of the impact of changes, generating a trusted comprehensive measure of risk activation and identifying candidate risk paths, confirming the output of incremental alarms and updating the analysis baseline. This reduces the resource consumption of full scans, improves the ability to identify combined vulnerabilities formed by old danger points and new propagation edges, and ensures that subsequent incremental scans are always based on the updated historical analysis baseline.

[0067] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0068] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0069] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0070] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0071] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A static analysis-based intelligent scanning method for software security vulnerabilities, characterized in that, Includes the following steps: Obtain the baseline version source code snapshot and the modified version source code snapshot corresponding to the software project under test. Read the file difference information, function difference information, configuration difference information and dependency declaration change information corresponding to this submission. Perform syntax parsing and structure normalization processing on the baseline version source code snapshot and the modified version source code snapshot. Establish the alignment relationship of corresponding program elements in the previous and current versions. Identify the syntax nodes, function call edges, control dependency edges, data dependency edges and configuration binding edges that have actually changed, and form a set of changed elements. Based on the set of changed elements, and combined with the baseline version program graph cache, function summary cache and historical danger point index, a comprehensive change impact quantity is formed, and a change impact subgraph corresponding to this commit is constructed in the current version program graph; On the change impact subgraph, combined with the vulnerability rule set, taint analysis specification, baseline version program graph cache, function summary cache and historical alarm index that match the software project under test, static incremental vulnerability analysis is performed to identify new risk paths directly introduced by this code change and historical dangerous paths activated by this code change, and a risk activation credible comprehensive quantity is formed based on the change through impact comprehensive quantity, path reachability confirmation parameters and baseline difference activation parameters; Based on the aforementioned risk activation trusted comprehensive quantity, candidate incremental risk paths are confirmed, screened, and baselines are updated to obtain valid incremental alarms or paths to be reviewed related to this submission, and the baseline version program graph cache, function summary cache, historical danger point index, and historical alarm index are updated. 2.The static analysis based intelligent scanning method for software security vulnerabilities according to claim 1, characterized in that: When the software project under test is included in the scan for the first time or when the existing analysis baseline corresponding to the current submission does not exist, the source code snapshot of the baseline version is used as the initial analysis baseline. The same syntax parsing and structure normalization processing as the changed version source code snapshot are performed on the source code snapshot of the baseline version to generate the initial baseline version program graph cache, the initial function summary cache and the initial historical danger point index, and the historical alarm index is initialized to empty. 3.The static analysis based intelligent scanning method of software security vulnerabilities according to claim 1, characterized in that: The set of changed elements includes at least newly added propagation edges, deleted purification edges, replaced call edges, condition constraint change nodes, and configuration effective relationship change nodes. Simultaneously with forming the set of changed elements, newly added propagation edge parameters, purification weakening parameters, and historical danger adjacency parameters are extracted to form the comprehensive quantity of the change's overall impact. The newly added propagation edge parameters characterize whether the current code change has added a propagation relationship that can drive external input to continue propagating towards historical danger points. The purification weakening parameters characterize whether the current code change has deleted, bypassed, or weakened the original purification and constraint processing. The historical danger adjacency parameters characterize the degree of adjacency between the changed node and the historical danger point.

4. The intelligent software security vulnerability scanning method based on static analysis according to claim 3, characterized in that: The current version's program graph is constructed based on the source code snapshot of the changed version. The current version's program graph includes at least abstract syntax tree relationships, control flow relationships, data dependency relationships, function call relationships, and configuration binding relationships. Variable placeholder nodes and output nodes in the template file, as well as SQL fragment nodes, dynamic condition nodes, and parameter reference nodes in the mapping file, are mapped to program elements. For cases where the call target, configuration effective branch, or template variable source cannot be uniquely determined in the static phase, all candidate association edges that satisfy semantic constraints are retained. A comprehensive judgment is made based on the newly added propagation edge parameters, the purification and weakening parameters, and the historical dangerous adjacency parameters to form the comprehensive change-through impact quantity.

5. The intelligent software security vulnerability scanning method based on static analysis according to claim 4, characterized in that: Using the changed nodes and edges in the set of changed elements as expansion seeds, the affected scope expansion is performed in the current version program graph to construct the change impact subgraph. The affected scope expansion searches outward along function call relationships, parameter passing relationships, return value passing relationships, object field read / write relationships, data dependency relationships, control dependency relationships, and configuration binding relationships for program nodes associated with the expansion seeds. The expansion depth and direction are controlled by the comprehensive quantity of the change's pervasive impact, and historical input entry points, historical danger points, and historical nodes whose semantics have changed due to replacement of call edges, condition constraint change nodes, or configuration effect change nodes that have a propagation relationship with the expansion seeds are included in the change impact subgraph.

6. The intelligent software security vulnerability scanning method based on static analysis according to claim 5, characterized in that: Based on the programming language, framework type, template mechanism, database access method, and configuration file format of the software project under test, a matching vulnerability rule set and taint analysis specification are loaded. The vulnerability rule set is used to identify dangerous function calls, insecure string concatenation, dangerous deserialization entry points, path concatenation defects, missing authentication verification segments, dangerous configuration combinations, and situations where necessary constraints are lacking before sensitive operations. The taint analysis specification includes at least taint source definitions, taint sink definitions, propagation relationship definitions, and cleanup definitions.

7. The intelligent software security vulnerability scanning method based on static analysis according to claim 6, characterized in that: First, a structural matching scan is performed on the change impact subgraph to form a first candidate alarm set. Then, using the external input entry points included in the change impact subgraph as taint sources and the dangerous execution points included in the change impact subgraph as taint sinks, taint propagation analysis is performed. During the propagation process, the purification status of the purification processing nodes in the candidate paths is determined, and the impact of the condition constraint change nodes and configuration effective relationship change nodes on the path establishment conditions is recorded to identify the following incremental risks: the incremental risk that the addition of propagation edges in this code change makes historical dangerous points reachable by externally controllable inputs for the first time; the incremental risk that the deletion of purification processing, weakening of condition constraints, or change of calling targets in this code change makes historically restricted dangerous paths re-established; and the incremental risk that the change of configuration effective relationships in this code change makes historically dangerous execution chains that were not in the effective execution scope enter the actual execution scope of the current version.

8. The intelligent software security vulnerability scanning method based on static analysis according to claim 7, characterized in that: The path reachability confirmation parameter is used to characterize whether a candidate path meets the conditions for being valid in the changed version; The baseline difference activation parameter is used to characterize the state difference of the same candidate path in the baseline version and the modified version, and is determined according to the following rules: If there is no corresponding propagation path in the baseline version, or although there are local nodes, the whole path is not connected, but the path is formed for the first time in the modified version, the baseline difference activation parameter is set to 1; if there is a corresponding path in the baseline version but it is in a restricted state, but it is transformed into a valid state in the modified version due to the failure of purification processing, the weakening of branch constraints, or the change of configuration effectiveness relationship, the baseline difference activation parameter is set to 0.5; if the path state in the baseline version and the modified version is basically the same, the baseline difference activation parameter is set to 0; and the risk activation credible comprehensive quantity is formed based on the comprehensive quantity of the change connectivity impact, the path reachability confirmation parameter, and the baseline difference activation parameter.

9. The intelligent software security vulnerability scanning method based on static analysis according to claim 8, characterized in that: Each candidate incremental risk path is screened and confirmed. The risk activation confidence comprehensive quantity is used as the main criterion for judgment. The candidate path is also judged in combination with its position in the change impact subgraph, the type of key nodes it passes through, and its correspondence with the historical alarm index. The screening results are divided into valid incremental alarms, paths to be reviewed, and invalid paths or historical alarms that are not directly related to this submission. The confirmed valid incremental alarms are further classified into three categories: new danger point alarms, old danger point activation alarms, and old alarm risk escalation alarms.

10. The intelligent software security vulnerability scanning method based on static analysis according to claim 9, characterized in that: When performing baseline updates, a corresponding alarm identifier is generated for each valid incremental alarm or path to be reviewed; if the corresponding record does not exist in the historical alarm index, a corresponding record is added; if the corresponding record already exists in the historical alarm index, its impact path summary, handling status, and most recent submission identifier are updated; for newly added danger points and activated old danger points that need to be written back to the new analysis baseline, they are written to the historical danger point index; for functions or methods affected by this submission, their input acceptance characteristics, output propagation characteristics, cleanup characteristics, and danger call characteristics are updated according to the confirmed path propagation results, and written back to the function summary cache; For historical hazardous path records that are no longer valid and have been confirmed to be repaired, they are either removed from the new analysis baseline or their status is updated to repaired.

Images