Method and device for detecting vulnerabilities, electronic equipment and program product

Abstract

The embodiment of the invention relates to a method and device for detecting vulnerabilities, electronic equipment and a computer program product. The method comprises the steps of firstly determining that an interface corresponding to traffic data has a vulnerability risk based on the traffic data, wherein the interface is used for realizing an asset management function; then, in response to determining that the interface has the vulnerability risk, determining a first function corresponding to the interface; further, a second function that calls the first function is determined from code of an interface for implementing the asset management service. And finally, determining vulnerabilities in the code for realizing the second function.

Description

Technical Field

[0001] The embodiments in this specification generally relate to the field of computer technology, and more specifically to a method, apparatus, electronic device, and computer program product for detecting vulnerabilities. Background Technology

[0002] As cybersecurity threats continue to evolve, vulnerability detection technology has become a core means of ensuring information system security. Vulnerability detection technology is evolving from single-rule matching to intelligent, multi-dimensional collaborative detection to address increasingly complex attack scenarios.

[0003] The rapid development of asset management systems has further increased the difficulty of vulnerability detection. In the field of asset management, asset transfer involves multiple stages and complex transfer logic. Asset security vulnerabilities in asset management systems are highly time-sensitive and destructive; the time lag between vulnerability discovery and remediation can lead to the loss of significant amounts of assets. Therefore, detecting asset security vulnerabilities is extremely challenging. Summary of the Invention

[0004] The embodiments of this specification provide a method, apparatus, electronic device, and computer program product for detecting vulnerabilities.

[0005] In a first aspect of this specification, a method for detecting vulnerabilities is provided. The method includes determining, based on traffic data, that an interface corresponding to the traffic data is at risk of vulnerability, the interface being used to implement asset management functionality. The method further includes, in response to determining that the interface is at risk of vulnerability, determining a first function corresponding to the interface. Further, the method includes determining, from the code of the interface used to implement the asset management functionality, a second function that calls the first function. Additionally, the method includes determining vulnerabilities in the code implementing the second function.

[0006] In a second aspect of this specification, an apparatus for detecting vulnerabilities is provided. The apparatus includes a vulnerability risk determination module configured to determine, based on traffic data, that an interface corresponding to the traffic data has a vulnerability risk, the interface being used to implement asset management functions. The apparatus also includes a first function determination module configured to determine a first function corresponding to the interface in response to determining that the interface has a vulnerability risk. Further, the apparatus includes a second function determination module configured to determine, from the code of the interface used to implement the asset management functions, a second function that calls the first function. Additionally, the apparatus includes a vulnerability determination module configured to determine vulnerabilities in the code implementing the second function.

[0007] In a third aspect of this specification, an electronic device is provided. The electronic device includes at least one processor. The electronic device also includes a memory coupled to the at least one processor and having instructions stored thereon, which, when executed by the at least one processor, cause the device to perform the method according to the first aspect of this specification.

[0008] In a fourth aspect of this specification, a computer program product is provided. This computer program product includes machine-executable instructions that, when executed, cause the method according to a first aspect of this specification to be implemented.

[0009] In a fifth aspect of this specification, a computer storage medium is provided. This computer-readable storage medium stores computer-executable instructions, which are executed by a processor to implement the method provided according to a first aspect of this specification. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this specification will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 Schematic diagrams are shown of example environments in which some embodiments of this specification may be implemented;

[0012] Figure 2 Flowcharts of methods for detecting vulnerabilities according to some embodiments of this specification are shown;

[0013] Figure 3 A schematic diagram illustrating function call relationships in some embodiments of this specification is shown;

[0014] Figure 4 A flowchart illustrating the vulnerability detection workflow of some embodiments of this specification is shown;

[0015] Figure 5 This specification shows a schematic block diagram illustrating the layered architecture of vulnerability detection technologies according to some embodiments; and

[0016] Figure 6 A schematic block diagram of a computing device according to some embodiments of this specification is shown.

[0017] In all the accompanying figures, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0018] Embodiments of this specification will now be described in more detail with reference to the accompanying drawings. While some embodiments of this specification are shown in the drawings, it should be understood that this specification can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this specification. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of this specification.

[0019] It is understood that before using the technical solutions disclosed in the various embodiments of this specification, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this specification in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0020] In the description of embodiments in this specification, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0021] In the field of asset security, vulnerabilities can lead to substantial economic losses, trigger serious security incidents, and impact the property safety of businesses and users. Currently, related technologies still rely on static analysis tools and human experience to comprehensively analyze large-scale codebases and complex logical functions, making it difficult to accurately identify potential problems.

[0022] Therefore, the embodiments of this specification provide a method for detecting vulnerabilities. First, based on traffic data, it is determined whether the interface implementing the asset management function corresponding to the traffic data has a vulnerability risk. Then, if the interface implementing the asset management function corresponding to the traffic data has a vulnerability risk, a first function corresponding to the interface is identified. Further, a second function that calls the first function is identified from the code of the interface used to implement the asset management function. Finally, vulnerabilities in the code implementing the second function are identified.

[0023] This approach utilizes traffic analysis for asset security vulnerability detection, locating the root cause of vulnerabilities based on interfaces with potential risks, thus overcoming the limitations of traditional static analysis. By monitoring traffic, potentially suspicious interfaces are identified, and vulnerable functions corresponding to these interfaces are filtered out. Related functions are then located through these vulnerable functions. Only the functions related to the vulnerable functions need to be identified to determine the vulnerability, without requiring the identification of all code. Therefore, the embodiments in this specification can leverage traffic analysis combined with abstract syntax trees to locate vulnerable functions and related functions, improving vulnerability detection efficiency.

[0024] Figure 1 A schematic diagram of an example environment 100 in which some embodiments of this specification may be implemented is shown. Reference Figure 1 The example environment 100 includes a computing device 102, which includes, but is not limited to, communication devices, computing chips, computing systems, single servers, distributed servers, or cloud-based servers. The example environment 100 also includes an asset management system 104, and the computing device 102 is equipped with a traffic receiving platform 106, a language model 108, and a vulnerability analysis platform 110.

[0025] Understandably, the asset management system 102 provides operations such as adding, deleting, modifying, and querying data. The asset management system provides interfaces as the sole entry point for external interaction. Each interface maps to internal system functions that implement the functional logic, allowing other systems or users to interact with it. For example, a user deletes an asset by calling the ` / asset / delete` interface, while the functions behind the interface are responsible for the specific implementation, such as permission verification and database operations.

[0026] Understandably, each interface call of the asset management system 104 generates traffic data, which is a record of interface interactions, including request and response messages. This data traffic can be captured by the traffic receiving platform 106. The traffic receiving platform 106 collects interface interaction data seamlessly through remote procedure call protocols or network monitoring, providing monitoring of the operational status of the asset management system 104 without affecting the normal execution of the asset management system 104's functional logic.

[0027] In some embodiments, computing device 102 acquires traffic data through traffic receiving platform 106. When a user invokes an interface, the underlying function is executed, processing the request and generating a response. The request parameters and response results in the traffic data reflect the interface's input and output, while the logic within the function may contain vulnerabilities, such as injection attacks caused by unvalidated input. Traffic receiving platform 106 then passes this data to vulnerability analysis platform 110 and language model 108 for further processing, such as detecting abnormal traffic and locating vulnerabilities. By analyzing the traffic data, computing device 102 can discover abnormal behavior of the interface. In some embodiments, vulnerabilities may include unauthorized access, parameter tampering, and sensitive data leakage.

[0028] In some embodiments, the computing device 102 may identify vulnerable functions or functions with a high probability of vulnerability as target functions (first functions). Due to the complex call relationships between functions, vulnerabilities in the target functions can propagate along the function call chain. Functions that directly or indirectly call the target function may also be contaminated by the target function and thus have defects. The computing device 102 identifies these functions as candidate functions (second functions). It is understood that the target function is the core function implementing the interface functionality, or a function with a high probability of vulnerability and serious consequences. Candidate functions are functions highly related to the target function and easily affected by it. Candidate functions are the focus of analysis and detection throughout the vulnerability detection process.

[0029] In some embodiments, the language model 108 is a core component with the ability to understand code semantics and perform functional logic reasoning. The language model 108 has unique advantages in code analysis, such as semantic understanding, logical reasoning, and pattern recognition capabilities. The computing device 102 uses deep learning technology to analyze the logical intent of the code, for example, identifying Asset as an asset entity class field and amount as a quantity field, and combining this with traffic data, such as abnormal requests with delta = -9999, to locate the root cause of vulnerabilities. The computing device 102 can analyze function call chains through the language model 108 to discover defects such as unverified permissions in upstream functions and parameter pollution during transmission. It can also, based on knowledge from the asset management domain, such as the requirement that asset quantities cannot be negative, determine that abnormal requests with delta = -9999 will affect asset security, thereby achieving a precise mapping from traffic anomalies to code defects.

[0030] In some embodiments, computing device 102 analyzes vulnerabilities identified by language model 108 through vulnerability analysis platform 110. Vulnerability analysis platform 110 performs further evaluation based on the vulnerabilities identified by language model 108. Vulnerability analysis platform 110 can analyze the causes, scope of impact, and severity of vulnerabilities. It is understood that vulnerability analysis platform 110 can also provide remediation suggestions or be integrated into the development team's project management tools to provide comprehensive support to the development team and better address security vulnerabilities in the system.

[0031] This approach utilizes traffic analysis for asset security vulnerability detection, locating the root cause of vulnerabilities based on interfaces with potential risks, thus overcoming the limitations of traditional static analysis. By monitoring traffic, potentially suspicious interfaces are identified, and vulnerable functions corresponding to these interfaces are filtered out. Related functions are then located through these vulnerable functions. Only the functions related to the vulnerable functions need to be identified to determine the vulnerability, without requiring the identification of all code. Therefore, the embodiments in this specification can leverage traffic analysis combined with abstract syntax trees to locate vulnerable functions and related functions, improving vulnerability detection efficiency.

[0032] It should be understood that the architecture and functionality in example environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this specification. Embodiments of this specification can also be applied to other environments with different structures and / or functionalities.

[0033] Figure 2 A flowchart of a method 200 for detecting vulnerabilities according to an embodiment of this specification is shown. In some embodiments, in Figure 1 In the example environment 100 shown, method 200 can be executed by computing device 102. It should be understood that although the following description uses computing device 102 as the execution subject, method 200 can also be executed by other devices. Method 200 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of this specification is not limited in this respect.

[0034] In step 202, based on the traffic data, it is determined that the interface corresponding to the traffic data has a vulnerability risk. The interface is used to implement asset management functions. In some embodiments, the computing device 102 can determine that the interface has a vulnerability risk based on abnormal traffic data. Abnormal traffic data may include abnormal request frequency, abnormal request parameters, abnormal request source, abnormal response time, abnormal response content, etc.

[0035] In step 204, in response to determining that an interface has a vulnerability risk, a first function corresponding to the interface is determined. In some embodiments, each interface corresponds to one or more functions, and the first function may be a core function that implements the functionality of the interface or a function that plays a critical role in the security of asset management. It is understood that the first function may also be a function that requires special attention in the asset management system, or a function with a high probability of vulnerability based on historical experience.

[0036] At step 206, the second function that calls the first function is determined from the code of the interface used to implement the asset management function. In some embodiments, there are complex call relationships between multiple functions implementing the interface function; the first function may be called by other functions, or may call other functions. The computing device 102 determines these functions that have call relationships with the first function as the second function. It is understood that the second function is closely related to the first function, usually a function closely related to core functions or functions that play a key role in the security of asset management, and requires special attention and investigation. It is understood that the second function can be in any interface. In some embodiments, functions in other interfaces called by the first function can also be the second function.

[0037] At step 208, vulnerabilities in the code implementing the second function are identified. In some embodiments, the language model 108 can predefine various rules and learn relevant knowledge reserves, enabling the computing device 102 to perform deep analysis of the code implementing the second function through the language model 108. Through the language model 108, the computing device 102 considers the functionality and security characteristics of the first function, as well as the data transfer and interaction methods between the first and second functions, thereby identifying vulnerabilities in the second function.

[0038] In the embodiments of this specification, traffic analysis is used to detect asset security vulnerabilities. By locating the root cause of vulnerabilities based on interfaces with potential vulnerabilities, it overcomes the limitations of traditional static analysis. Potentially suspicious interfaces are identified through traffic monitoring. In this way, traffic analysis is used to detect asset security vulnerabilities, locating the root cause of vulnerabilities based on interfaces with potential vulnerabilities, thus overcoming the limitations of traditional static analysis. Potentially suspicious interfaces are identified through traffic monitoring, and vulnerable functions corresponding to these suspicious interfaces are filtered out. Related functions are then found through these vulnerable functions. Only the related functions of the vulnerable functions need to be identified to determine the vulnerability, without needing to identify all the code. Therefore, the embodiments of this specification can utilize traffic analysis combined with abstract syntax trees to locate vulnerable functions and related functions, improving the efficiency of vulnerability detection.

[0039] In some embodiments, network traffic is generated each time a user calls the asset management system's interface. The traffic receiving platform 106 captures this network traffic through Remote Procedure Call (RPC) protocol, network listening, or mirrored ports. Network traffic refers to the real-time capture of the complete data flow of the user's interaction with the asset interface, encompassing various information carried when the request is initiated, such as the service interface accessed, detailed input data (e.g., asset ID, operation instructions, transaction amount, and other key parameters), and output data returned by the server (e.g., operation result feedback, asset details, error messages, etc.). This traffic not only includes the specific content of the user's interaction with the system but also control information during the request and response process, such as the request method (HTTP GET method, HTTP POST method, HTTP PUT method), authentication information and data type declarations in the request header, and response status codes (e.g., 200 for success, 404 for resource not found, 500 for internal server error, etc.).

[0040] In some embodiments, network traffic includes not only explicit request content actively sent by the user, but also implicit control information encapsulated by each layer of the protocol stack. For example, the application layer carries the request body that carries specific functional logic, the transport layer encapsulates the port number and checksum through the Transmission Control Protocol or User Datagram Protocol, the network layer contains source and destination IP addresses (Internet Protocol Address) and routing information, the data link layer contains physical network identifiers such as MAC address (Media Access Control Address) and VLAN (Virtual Local Area Network) label, and the time dimension of request initiation timestamp and response time accurate to the millisecond level.

[0041] In some embodiments, by analyzing the payload data in the traffic, the computing device 102 can discover that in a delta=1000000 request submitted by a user through the / asset / modify interface, the user_role field has been tampered with and changed to admin. Combined with an abnormal surge in the number of retransmissions at the transport layer, this pinpoints an asset value tampering caused by an SQL (Structured Query Language) injection vulnerability. This comprehensive capture of traffic can accurately identify vulnerability scenarios such as high-frequency asset queries through network layer traffic surges, and the plaintext transmission of sensitive fields through application layer payload risks.

[0042] In some embodiments, the language model filters traffic data according to rules related to asset security to determine traffic data that conforms to the rules. Asset security rules may be related to access control, data integrity, and sensitive information protection. In some embodiments, the rules may include rules such as non-administrators cannot delete assets, asset quantities cannot be negative, and responses cannot contain un-anonymized information. The language model needs to understand these rules and identify whether they are conformed to in the traffic data.

[0043] In some embodiments, the computing device 102 needs to incorporate natural language processing technology to transform rules into executable logic, such as detecting anomalies through pattern matching or deep learning models. In some embodiments, when the computing device 102 detects that the user_id in a request is not an administrator but an attempt is being made to delete an asset, a warning is triggered. Then, the filtering process requires real-time analysis of traffic data to identify portions that conform to the rules. This can be understood as the computing device 102 parsing request and response messages, extracting key parameters such as user_id, asset_id, and delta (transaction amount) values, and then applying rules for judgment. Through rule-based filtering, traffic data irrelevant to asset security or that does not conform to predetermined rules is excluded, reducing the amount of data that needs to be processed in subsequent analysis.

[0044] In some embodiments, after the computing device 102 filters out traffic data that meets the risk characteristics according to asset security rules, it first parses the interface path information in the traffic data. This path is the unique identifier of the interface. In some embodiments, after the language model 108 filters out traffic data that meets the risk characteristics according to the asset security rules "non-administrators are prohibited from calling sensitive interfaces" and "asset quantity change parameters must be positive", such as the request message of user=guest (guest user) calling the / asset / delete interface and the asset update request of delta=-100 (asset decrease by 100 units), it first parses the interface path information in the traffic data, such as the URL (Uniform Resource Locator) path in the request message, / asset / delete or / asset / update.

[0045] Next, based on the abnormal service characteristics in the traffic, a preset risk association model is used to determine whether the interface has a vulnerability risk. In some embodiments, when the computing device 102 repeatedly captures traffic where the user_role=employee successfully calls the / asset / export_all ( / asset / export all) interface and obtains all asset data, the system will identify that the / asset / export_all ( / asset / export all) interface has a risk of missing permission verification, because according to asset security rules, this interface is only allowed to be accessed by the admin (administrator) role. This judgment not only relies on the anomaly of a single traffic flow, but also confirms the authenticity of the risk by statistically analyzing the frequency of similar anomalies in the traffic and the scope of impact (such as the type of assets involved and the data sensitivity level).

[0046] In some embodiments, static code analysis techniques can be used to precisely map interface paths to specific implementation code. For example, the code query engine first performs a comprehensive scan of the asset management system's codebase. During the scan, it establishes a mapping relationship between interface paths and code locations by parsing framework-specific routing definitions or configuration files. The acquired code includes not only the interface's entry function (i.e., the routing function that directly handles requests) but also all dependent code called by the entry function. In this way, a complete context code from the interface to the functional logic is formed. This code acquisition mechanism ensures the accuracy and comprehensiveness of vulnerability analysis, enabling the computing device 102 to locate logical defects at the line-level from interface-level risks, providing a precise basis for subsequent function vulnerability analysis and remediation.

[0047] In some embodiments, after the computing device 102 obtains the code block corresponding to the interface through the code query engine, the language model 108 identifies the function that directly carries the core logic of asset operation as the target function (first function) based on the call relationship and functional logic between functions in the code block. In some embodiments, the language model 108 takes the entry function of the code block interface as the starting point, and through parsing the function call chain, traces the downstream functions directly or indirectly called by the entry function, and filters out functions that contain key logic such as asset data addition, deletion, modification and query, permission verification, and parameter compliance checks.

[0048] In some embodiments, the entry function of the interface / asset / delete may only be responsible for parameter parsing, while the delete_asset_core function it calls, which includes permission verification and database deletion operations, will be identified as the target function (the first function). This process requires the language model 108 to combine the code's functional context to determine whether the function operates on the Asset entity class, whether it contains role permission judgment or delta value verification and other asset security-related logic, and to verify whether the function handles operations that actually trigger risks through parameters in the traffic data, such as user_id and asset_id.

[0049] In some embodiments, the computing device 102 parses the code that implements the asset management function through a code parser. The code parser scans the code that implements the asset management service and uses Abstract Syntax Tree (AST) parsing technology to convert the source code into a structured syntax tree. Each node in the tree precisely corresponds to the class, function, parameter and return value in the code, forming a visual structure mapping of the code logic.

[0050] Understandably, Language Model 108 takes the code implementing asset creation, deletion, modification, and query functions as input. Through its language processing capabilities of lexical analysis, syntactic analysis, and semantic analysis, it decomposes the source code into a hierarchical tree structure. The root node of the tree represents the entire asset management module, the branch nodes can be classes and functions, and the leaf nodes can be parameters and return values. Each node can contain syntactic information such as function name and parameter type, and can also include functional semantic labels. For example, class nodes are labeled "core asset entity," function nodes are labeled with operations such as "asset deletion" and "permission verification," parameter nodes are labeled with functional meanings such as "asset primary key" and "quantity change value," and return value nodes record the operation result of "operation success / failure."

[0051] Understandably, each function node in the syntax tree can serve as a logical hub, with other function expressions within the function forming call edges pointing to other functions. In some embodiments, when a syntax tree node of function A contains a direct reference to function B (such as the B() statement), a direct call relationship is formed, indicating that the execution of A will inevitably trigger the execution of B. If function B further calls function C through an intermediate function D, a function call chain A→D→B→C can be formed in the syntax tree.

[0052] In some embodiments, the computing device 102 traverses the hierarchical structure of the syntax tree using a code parser to identify the call relationships of all functions. This analysis does not require running the code; instead, the language model 108 constructs function call relationships and execution logic by identifying the parent-child relationships of nodes in the syntax tree and the semantic associations of call expressions. In some embodiments, if the computing device 102 finds that the deleteAsset node in the syntax tree of the asset deletion operation lacks a call edge pointing to checkPermission, it considers that the code implementing this function has a vulnerability path with missing permission verification. This process transforms the code block into a code block logic map, marking all function interaction paths on the map. In some embodiments, the failure to call permission functions, the skipping of risk parameters from the verification function, resulting in a broken call chain or parameter passing pollution in the graph can be clearly displayed in the graph.

[0053] In some embodiments, the computing device 102 abstracts the function call relationships parsed from the syntax tree into a directed graph structure. Each node in the graph represents a function, and the edges represent the call direction. The weight of the edges can indicate the call frequency or service criticality (e.g., edges of asset operation functions are displayed in bold). When generating the graph, the computing device 102 automatically filters auxiliary functions such as log tools, focusing on functions related to Asset entities, and using core functions related to entities as the core nodes of the graph, forming a call graph centered on the core functions of asset management.

[0054] Figure 3 A schematic diagram of function call relationships 300 according to some embodiments of this specification is shown. For example... Figure 3 As shown, node 302 represents function A, node 304 represents function B, node 306 represents function C, edge 308 indicates that function A calls function B, and edge 310 indicates that function B calls function C. It can be understood that function B is directly called by function A, and function C is indirectly called by function A. Function A is an upstream function of function B, and function C is a downstream function of function B.

[0055] In some embodiments, the computing device 102 identifies a node in the call graph representing the target function (first function), such as the core function for asset deletion. The computing device 102 uses this node as the hub of the functional logic, and the connecting edges around this node represent execution dependencies between functions. The computing device 102 captures all nodes that have a call relationship with the target function by traversing the directed edges of the call graph. This includes both downstream functions actively called by the target function and upstream functions that call the target function. The functions corresponding to these nodes can be identified as candidate functions (second functions) to jointly implement the asset operation logic.

[0056] refer to Figure 3 If function B is the target function, then function A is an upstream function of function B, and function C is a downstream function of function B. Function C, called by function B, and function A, which calls function B, are both candidate functions. It can be understood that the scope of candidate functions can be traced upwards and downwards along functions A and B. This graph-based correlation localization enables computing device 102 to quickly identify the dependent functions of the target function or the source of corrupted calls, providing a full-link analysis from point to surface for vulnerability cause analysis, ensuring that every related function in the asset management logic is identified and addressed.

[0057] In some embodiments, the computing device 102 uses the target function node as the starting point for traversal, initiates a graph search algorithm to identify candidate functions, and traces downstream functions triggered by the target function along the forward direction of the edges (target function → called function), and traces upstream call sources along the reverse direction of the edges (function calling the target function → target function), collecting all nodes reachable from the target function. These nodes include verification functions and data operation functions directly called by the target function, as well as interface entry points and parameter parsing functions indirectly triggered by the target function. The traversal process follows the reachability principle of the graph: as long as there is a path (regardless of length) composed of edges connecting the starting node and other nodes, it is determined that there is a function call relationship between them.

[0058] In some embodiments, computing device 102 initiates a graph breadth-first search algorithm to determine candidate functions. Computing device 102 uses the target function node as the root node and employs a queue-driven hierarchical traversal approach to perform the search. Computing device 102 initializes a double-ended queue and pushes the target function node into the queue, while maintaining a boolean array of access markers to mark the root node as visited. Then, iterates in a loop: each time a node v is popped from the head of the queue, the following processing is performed on node v: traverse all outgoing edges of node v, where each outgoing edge corresponds to a downstream function directly called by v. For each downstream node u that has not been marked as visited, mark it as visited and push it to the tail of the queue. Traverse all incoming edges of node v, where each incoming edge corresponds to an upstream function directly calling v. For each upstream node w that has not been marked as visited, similarly mark it as visited and push it into the queue.

[0059] By using this bidirectional edge traversal method, the elements in the queue sequentially include the root node (i.e., the objective function) of level 0, the direct upstream and downstream nodes of level 1, the indirect upstream and downstream nodes of level 2, and so on, until the queue is empty. When the queue is empty, the functions corresponding to all reachable nodes within all levels constitute a set of candidate functions.

[0060] In some embodiments, the computing device 102 initiates a graph depth-first search algorithm to determine candidate functions. Starting with the target function node, the computing device 102 searches all potential call paths using a stack-driven recursive traversal. The computing device 102 initializes a stack and pushes the target function node onto the stack, marking it as visited. Then, it iterates, removing the top node from the stack each time and processing it according to the following steps: First, perform a depth-first search along the node's outgoing edges, which correspond to downstream functions called by that node. For unvisited downstream nodes, mark them as visited and push them onto the stack, continuing this operation until no new nodes are available for expansion. When no new downstream nodes are available, backtracking is performed to process unvisited nodes corresponding to the node's incoming edges, which correspond to upstream functions that called that node. This process is repeated until the stack is empty.

[0061] Because of the Last-In-First-Out (LIFO) property of the stack, the traversal path extends in a tree-like pattern. Meanwhile, a visit marker array is used to avoid redundant analysis of nodes. When the top node of the stack has no unvisited nodes on either its outgoing or incoming edges, the node is popped from the stack until the stack is empty. At this point, all reachable nodes on the depth path constitute a set of candidate functions.

[0062] It is understood that the embodiments in this specification, during the traffic data preprocessing stage, use language models to filter traffic data according to rules, which can reduce the scope of code that needs to be focused on during static analysis. By using precise call graphs and function reachability analysis, the search space for static analysis is narrowed, reducing the possibility of analyzing irrelevant code and improving the efficiency of vulnerability detection.

[0063] In some embodiments, the language model determines vulnerabilities in the code of candidate functions based on predefined vulnerability types, vulnerability scenarios, and vulnerability attributes. Understandably, the language model first loads a predefined vulnerability knowledge graph, where each vulnerability type corresponds to a set of structured rules. In some embodiments, vulnerability types can be ineffective access controls, including horizontal and vertical privilege escalation; they can also be missing syntax tree nodes, etc. In some embodiments, vulnerability scenarios can describe situations that might lead to vulnerabilities in a function within a specific context. For example, unfiltered asset queries or unverified asset transfers could lead to asset theft. In some embodiments, vulnerability attributes can be attributes describing the vulnerability characteristics of a function, such as insecure input parameters or a lack of validation mechanisms.

[0064] In some embodiments, the language model 108 can perform detailed analysis of candidate functions through syntax tree feature extraction, rule pattern matching, and service semantic enhancement, and compare them with predefined vulnerability types, scenarios, and attributes to identify potential vulnerabilities. Once a potential vulnerability is identified, the language model 108 will further analyze the cause of the vulnerability and its potential impact. Understandably, the language model 108 can send the identified vulnerabilities to the vulnerability analysis platform 110 for further evaluation of the vulnerability's impact scope and severity based on the matched scenario.

[0065] In some embodiments, language model 108 performs deep semantic analysis on identified potential vulnerabilities, associating code defects with system logic risks. Based on matched vulnerability scenarios (such as "asset deletion without authentication" or "parameters not validated"), language model 108 traces the root cause of vulnerabilities from the code's syntax tree, call graph, and data flow. In some embodiments, computing device 102 discovers that a function lacks an authorization validation node or that parameters are not filtered due to user input being directly concatenated into SQL statements. Subsequently, language model 108 combines predefined service rules (such as "non-administrators cannot delete core assets" or "inventory quantity cannot be negative") and asset attributes to infer the potential scope of the vulnerability. If the vulnerable function is located in the core path of asset deletion, its impact may cover all asset operation interfaces.

[0066] It is understood that the embodiments in this specification combine traffic analysis with language modeling capabilities for the detection of asset security vulnerabilities, introducing semantic understanding of large models and overcoming the limitations of traditional vulnerability detection relying on static analysis and human experience. This improves the efficiency and accuracy of vulnerability detection and enhances the intelligence and automation level of vulnerability detection.

[0067] During the severity assessment, computing device 102 can consider the existence of direct call paths and the exploitability of code-level vulnerabilities. By combining asset importance and operational frequency, computing device 102 can generate analysis results at the functional implementation level, including technical causes, impact scope, and risk levels. Computing device 102 transforms code-level structural defects into concrete risks in the asset security domain, enabling vulnerability analysis to go beyond technical diagnosis and form a systematic security assessment of asset management functions. In the vulnerability analysis phase of the model, computing device 102 can compare various scenarios and attributes, and through step-by-step reasoning, analyze the vulnerability causes and impact scope of each suspicious function. This approach makes vulnerability analysis more comprehensive and accurate.

[0068] Understandably, this solution leverages behavioral analysis for dynamic detection. By monitoring the behavior of the asset management system application during actual operation, particularly during sensitive operations such as asset transfers and withdrawals, it identifies potential logical vulnerabilities. Real-time traffic monitoring, network traffic capture, and system call monitoring are used to acquire asset-related operational data. By capturing function calls and memory changes during program runtime, a call graph is dynamically generated. Combined with historical behavioral data, this graph is compared with known vulnerability scenarios to identify operations deviating from normal behavior patterns and predict potential vulnerabilities. By capturing code execution behavior in the actual operating environment, dynamic analysis helps confirm whether suspicious vulnerabilities identified in static analysis actually exist.

[0069] Understandably, this solution can also be based on a hybrid static and dynamic analysis approach. The computing device 102 can combine static and dynamic analysis for comprehensive vulnerability detection. The computing device uses traditional static analysis tools to scan code, executes relevant code in a sandbox environment, and captures abnormal runtime behavior. By combining the results of static analysis and dynamic verification, vulnerabilities are confirmed and remediation suggestions are proposed. Static analysis can discover potential problems in the code, while dynamic analysis can verify whether vulnerabilities discovered through static analysis will be triggered during actual execution. Combining static analysis with dynamic verification can improve the accuracy and reliability of vulnerability detection.

[0070] Figure 4The flowchart illustrates the vulnerability detection workflow 400 of some embodiments of this solution. Traffic data containing request and response messages is obtained from the traffic platform via an RPC interface. This data is then filtered using a language model based on asset security rules to identify asset security-related traffic. Suspicious interfaces are identified based on the filtering results, and a code query engine is used to obtain the corresponding implementation class methods and related call functions. The source code is parsed using a code parser to generate an abstract syntax tree, from which method call information is extracted to construct a call graph. A graph traversal algorithm is then used to analyze reachability to identify reachable methods related to the target function. Candidate functions are determined from the call graph, and the language model performs semantic analysis and matching on these candidate functions based on predefined vulnerability types, scenarios, and attributes. Once a potential vulnerability is identified, the language model further analyzes the causes, assesses the scope and severity of the impact, and finally generates a vulnerability report.

[0071] Figure 5 This diagram illustrates a layered vulnerability detection architecture 500 of some embodiments of this solution. The data layer encompasses the traffic platform and its traffic database storing traffic data, and the code repository storing source code. The processing layer includes a language model filtering module for semantic filtering of traffic data, a code parsing engine for parsing source code to generate an abstract syntax tree, a call graph generator for constructing a call graph, and a scenario matcher for performing vulnerability scenario and attribute matching. The analysis layer consists of an reachability analyzer for performing reachability analysis, a vulnerability analysis module for conducting deep vulnerability analysis, and a language model analysis engine for implementing semantic understanding. The output layer is responsible for outputting the final vulnerability detection results. These layers collaborate through data flow and processing logic, forming a complete vulnerability detection process from data input to vulnerability detection result output, ensuring accurate and comprehensive discovery and analysis of potential vulnerabilities.

[0072] In some embodiments, the scenarios matched by the scenario matcher can be abstract descriptions of the conditions under which a specific type of problem or vulnerability occurs. These typically include two parts: a functional scenario and a behavioral scenario. In some embodiments, a functional scenario can describe the key operations or functions involved. For example, an operation involving authorization verification, resource transfer, or data update can indicate the basic behavioral environment in which the problem occurs. In some embodiments, a behavioral scenario describes the specific behaviors or code characteristics that lead to the problem, such as a lack of security checks, improper operation sequence, permission leakage, or incorrect state reset. These scenarios can be manually defined in advance by technical personnel according to different problem types and expressed in natural language. They are equivalent to describing the "triggering conditions" or "running environment" of the problem in a specific context. Through this definition, the system can determine whether the actual code content matches these scenarios, thereby effectively identifying potential risks or vulnerabilities.

[0073] Figure 6 A block diagram schematically illustrates a computing device 600 suitable for implementing embodiments of the present invention. The computing device 600 may be used to implement the computing device 102. The computing device 600 may be used to implement execution... Figure 2 The device shown in method 200. (As...) Figure 6 As shown, the computing device 600 includes a processing unit (CPU) 601, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 602 or loaded from storage unit 608 into random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the computing device 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0074] Multiple components in computing device 600 are connected to I / O interface 605, including: input unit 606, output unit 607, and storage unit 608. Processing unit 601 executes the various methods and processes described above, such as executing method 200. For example, in some embodiments, the various processes or operations described above may be implemented as computer software programs stored in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on computing device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by CPU 601, the various methods and processes described above may be executed, such as executing one or more operations of method 200. Alternatively, in other embodiments, CPU 601 may be configured by any other suitable means (e.g., by means of firmware) to execute the various methods and processes described above, such as executing one or more actions of method 200.

[0075] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0076] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0077] These computer-readable program instructions can be provided to a processor, general-purpose computer, special-purpose computer, or other programmable data processing unit in a voice interaction device to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing device, these instructions create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, causing a computer, programmable data processing device, and / or other device to operate in a particular manner.

[0078] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0079] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0080] The above are merely optional embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for detecting vulnerabilities, comprising: Based on traffic data, it was determined that the interface corresponding to the traffic data has a vulnerability risk. The interface is used to implement asset management functions. In response to determining that the interface has a vulnerability risk, a first function corresponding to the interface is determined; From the code of the interface used to implement the asset management function, determine the second function that calls the first function; as well as Identify the vulnerability in the code that implements the second function.

2. The method according to claim 1, further comprising: The code of the interface used to implement the asset management function is parsed by a code parser to generate a syntax tree, wherein the nodes of the syntax tree indicate at least one of class, function, parameter, and return value; Based on the syntax tree, the function call relationships in the code of the interface used to implement the asset management function are determined, and the function call relationships indicate the direct or indirect call relationships between functions; as well as Based on the function call relationships, a call graph is generated, and the nodes of the call graph indicate the corresponding functions.

3. The method of claim 2, wherein determining the second function comprises: In the call graph, the node for the first function is determined; In the call graph, nodes that have a function call relationship with the node of the first function are identified; as well as The function corresponding to the node with a function call relationship is identified as the second function.

4. The method according to claim 3, wherein determining the nodes where function call relationships exist includes: In the call graph, the node of the first function is determined as the starting node of the call graph; In the call graph, one or more paths are determined based on the starting node; as well as Nodes in one or more paths are identified as nodes with function call relationships.

5. The method according to claim 1, further comprising: Acquire traffic data related to user access requests to the interface, the traffic data including request messages and response messages; as well as The traffic data is filtered by a language model based on rules related to asset security to determine the traffic data that meets the rules.

6. The method of claim 6, wherein determining the first function comprises: Based on the traffic data that conforms to the rules, the interfaces with potential vulnerability risks are identified. The code corresponding to the interface is obtained through a code query engine; as well as The first function is determined from the code corresponding to the interface.

7. The method of claim 1, wherein identifying vulnerabilities in the code implementing the second function includes: The language model determines the vulnerabilities in the code implementing the second function according to at least one of the predefined vulnerability types, vulnerability scenarios, and vulnerability attributes. The method also includes: The language model is used to determine the cause and / or impact of vulnerabilities in the code implementing the second function; as well as Based on the causes and / or effects, generate a vulnerability analysis report for the code implementing the asset management function.

8. An apparatus for detecting vulnerabilities, comprising: The vulnerability risk determination module is configured to determine the vulnerability risk of the interface corresponding to the traffic data based on traffic data. The interface is used to implement asset management functions. The first function determination module is configured to determine the first function corresponding to the interface in response to determining that the interface has a vulnerability risk. The second function determination module determines the second function that calls the first function from the code of the interface used to implement the asset management function; as well as The vulnerability identification module is configured to identify vulnerabilities in the code that implements the second function.

9. A computing device, comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the computing device to perform the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program that is executed by a processor to implement the method according to any one of claims 1 to 7.

Images