An e-commerce API interface security vulnerability detection method based on a knowledge graph

Abstract

The application discloses an e-commerce API interface security vulnerability detection method based on a knowledge graph, which comprises the following steps: collecting API gateway logs and API document data of an e-commerce system, and constructing a business knowledge graph; obtaining an initial vulnerability detection rule library, and forming a rule knowledge graph; constructing a meta-knowledge graph; calling rules in the rule knowledge graph for matching detection; storing conflict events in the meta-knowledge graph; creating an embryo node, splitting a new rule node when the aggregation amount reaches a maturity threshold, and storing the new rule node as a birth event in the meta-knowledge graph; periodically calculating an effectiveness index, and storing the effectiveness index as a death event in the meta-knowledge graph when the effectiveness index is lower than an apoptosis threshold; analyzing the correlation mode between events, detecting API calling requests, and generating a vulnerability detection result. The application constructs business, rule and meta-knowledge graphs to realize API vulnerability detection self-evolution, and has the advantages of wide coverage, high accuracy and continuous optimization.

Description

Technical Field

[0001] This invention relates to the field of security vulnerability detection, and in particular to a method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs. Background Technology

[0002] Existing e-commerce API security detection technologies typically rely on static rule bases or feature-matching-based detection engines. They identify potential risks by analyzing parameter structures, access patterns, and call frequencies in API gateway logs. However, these detection methods generally lack the ability to understand business semantics, cannot extract deep structural information from the relationship between API documentation and real business entities, and struggle to locate potential cross-interface attack paths in complex business chains. Furthermore, static rules cannot adapt to the characteristics of frequent interface changes and rapid evolution of attack strategies in e-commerce business scenarios, easily leading to rule expiration and decreased hit rates.

[0003] Under the existing technical framework, when different rules produce conflicting conclusions for the same API call, there is a lack of a systematic conflict identification and resolution mechanism, leading to logical inconsistencies between rules. Furthermore, new detection rules cannot be automatically generated for newly emerging abnormal traffic that is not covered, creating detection gaps. In addition, the existing technology lacks rule lifecycle management, meaning rules cannot be dynamically updated, optimized, or phased out based on actual performance, making it difficult for the detection system to maintain long-term effectiveness. This invention addresses these technical deficiencies by constructing a business knowledge graph, a rule knowledge graph, and a meta-knowledge graph to achieve rule evolution management, a self-growth mechanism, and adaptive conflict resolution, fundamentally solving these technical shortcomings. Summary of the Invention

[0004] One objective of this invention is to propose a knowledge graph-based method for detecting security vulnerabilities in e-commerce API interfaces. This invention constructs a business, rule, and meta-knowledge graph to achieve self-evolution in API vulnerability detection, possessing the advantages of broad coverage, high accuracy, and continuous optimization.

[0005] A method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to an embodiment of the present invention includes the following steps: Collect API gateway logs and API documentation data from e-commerce systems to build a business knowledge graph; Obtain an initial vulnerability detection rule base, convert each vulnerability detection rule into a rule node, construct edges based on the logical relationships between rules, and form a rule knowledge graph; A meta-knowledge graph is constructed using the rule evolution events that have occurred in the rule knowledge graph as nodes and the temporal relationships between events as edges. Map real-time API call requests to the business knowledge graph, and call the rules in the rule knowledge graph for matching and detection; When multiple rules output conflicting results during matching detection, the conflicting edges are marked and the conflict events are stored in the meta-knowledge graph. When abnormal traffic patterns in the monitoring business knowledge graph are not covered by existing rules, an embryo node is created in the rule knowledge graph to aggregate abnormal traffic patterns with the same structural features. When the aggregation reaches the maturity threshold, a new rule node is generated and stored in the meta-knowledge graph as a birth event. The validity index of each rule in the periodic calculation rule knowledge graph is used. When it falls below the apoptosis threshold, the rule node is removed and stored in the meta-knowledge graph as an extinction event. Based on rule evolution events in the meta-knowledge graph, the association patterns between events are analyzed through graph pattern matching. The analysis results are then updated to maturity thresholds, apoptosis thresholds, or conflict resolution methods. The updated rule knowledge graph is then used to detect API call requests and generate vulnerability detection results.

[0006] Optionally, the construction of the business knowledge graph specifically includes: API log parsing, API document structuring, business entity extraction, interface node generation, entity relationship establishment, log document fusion, graph structure organization, graph node updating, and business knowledge graph formation.

[0007] Optionally, the generation of the rule knowledge graph specifically includes: The initial vulnerability detection rule base is read, and the rule identifier, applicable API scope, triggering conditions, detection constraints and detection conclusions of each vulnerability detection rule are obtained in sequence. All vulnerability detection rules are numbered and organized to form an initial vulnerability detection rule list. Based on the initial list of vulnerability detection rules, a corresponding rule node is created for each vulnerability detection rule. The rule node contains the rule node identifier, rule identifier, rule type information, and scope of application information. All rule nodes are then aggregated to form a rule node set. For any two rule nodes in the rule node set, based on the logical relationship entries set in the vulnerability detection rule base, extract the logical attribute information between the two rule nodes, including mutual exclusion, inclusion, priority and independence relationships, and organize the logical attribute information into a list of logical relationships between rules; Based on the set of rule nodes and the list of logical relationships between rules, a logical relationship edge is established for each pair of rule nodes with logical relationships, including logical relationship type, priority identifier, mutual exclusion identifier and association direction information. The constructed logical relationship edges are then gathered to form a logical relationship edge set. Perform consistency normalization processing on the attribute fields of all rule nodes in the rule node set, including unifying the rule node identifier field, rule type description, rule scope field, and rule status field. Perform unified organization on the attribute fields of all logical relation edges in the logical relation edge set, including unifying the logical relation type field, priority field, and conflict flag field. By combining the standardized set of rule nodes with the set of logical relationship edges, a rule knowledge graph composed of rule nodes and logical relationship edges is formed.

[0008] Optionally, the construction of the meta-knowledge graph specifically includes: Collect a set of rule evolution events that have occurred from the rule knowledge graph. Each rule evolution event contains a unique event identifier, event type, rule node identifier associated with the event, and event timestamp. Event types include conflict events, birth events, and extinction events. Each rule evolution event is transformed into an event node in the meta-knowledge graph. The attributes of the event node include the event type and the event occurrence timestamp. For any two rule evolution events, when the timestamp of the later event is later than the timestamp of the earlier event, a time-series edge is constructed between the corresponding event nodes. The attributes of the time-series edge include the time interval between the two events. For multiple event nodes with the same rule node identifier, time-series edges are constructed sequentially according to the timestamp order to form the lifecycle path of the corresponding rule node; A meta-knowledge graph is constructed based on all event nodes and all temporal edges.

[0009] Optionally, the matching detection specifically includes: Receive real-time API call requests, parse the request method, request path, request parameters, request headers and session identifier of the real-time API call requests, and generate a set of entity information; Match the entity information set with the business entity nodes in the business knowledge graph to generate the business entity node corresponding to each entity; Based on the request path of the real-time API call request, the API interface node is located in the business knowledge graph, and the API interface node is associated with the business entity node to generate the request subgraph of the real-time API call request in the business knowledge graph. Obtain the session identifier of the real-time API call request, read the historical API call sequence of the session within the time window based on the session identifier, process each historical API call request in the historical API call sequence in the same way, and generate a historical request subgraph sequence. By concatenating the request subgraph with the historical request subgraph sequence, a complete business context subgraph of real-time API call requests is generated; All detection rule nodes are obtained from the rule knowledge graph, and each detection rule node is associated with a graph pattern query statement to generate a set of detection rule nodes; The complete business context subgraph is matched with the graph pattern query statement associated with each detection rule node in the detection rule node set. For each detection rule node, the hit determination result of that rule node is generated. Collect the hit determination results of all detection rule nodes and generate a set of matching detection results for real-time API call requests.

[0010] Optionally, the stored meta-knowledge graph specifically includes: Obtain the matching detection result set, extract the identifiers of all hit detection rule nodes from the matching detection result set, and generate the hit rule set for real-time API call requests; Iterate through each pair of detection rule nodes in the hit rule set, read the pre-built logical relationship edges between each pair of detection rule nodes from the rule knowledge graph, and generate the logical relationship edge type for each pair of detection rule nodes; For each pair of detection rule nodes, a conflict determination result is generated based on the logical relationship edge type and the detection conclusions output by the two rules. When the conflict determination result is that a conflict exists, the logical relationship edge between the pair of detection rule nodes is marked as active in the rule knowledge graph, and a conflict event is generated. For each generated conflict event, construct a conflict event information tuple, which includes a unique identifier for the conflict event, the event type, the identifier of the first rule node, the identifier of the second rule node, and the timestamp of the conflict occurrence; The conflict event information tuples are stored as conflict event nodes in the meta-knowledge graph.

[0011] Optionally, storing the birth event in the meta-knowledge graph specifically includes: Real-time monitoring of API call traffic in the business knowledge graph; collection of API call requests that were not detected by any detection rules within the time window; and generation of an abnormal traffic sample set. For each abnormal traffic sample in the abnormal traffic sample set, extract its request subgraph structure features in the business knowledge graph to generate a structure feature vector for each abnormal traffic sample. Cluster analysis is performed on the structural feature vectors of all abnormal traffic samples, and abnormal traffic samples with the same structural feature vectors are aggregated into the same cluster to generate a set of clusters. Traverse each cluster in the cluster set. When the number of samples in the current cluster reaches the embryo creation threshold, create an embryo node in the rule knowledge graph. The attributes of the embryo node include the creation timestamp, the current aggregation amount, and the average structural feature vector of the current cluster. New abnormal traffic samples are received in real time. The structural feature vector of each new abnormal traffic sample is extracted. When the similarity between the structural feature vector of the current new abnormal traffic sample and the average structural feature vector of any embryo node is greater than the aggregation threshold, the current new abnormal traffic sample is aggregated into the corresponding embryo node, and the current aggregation amount and average structural feature vector of the embryo node are updated. Traverse each embryo node in the rule knowledge graph. When the current aggregation amount of the current embryo node reaches the maturity threshold, trigger the split operation and generate a new detection rule node based on the common features of the abnormal traffic samples aggregated by the current embryo node. The newly generated detection rule node is added to the rule knowledge graph, generating a birth event. The birth event includes the event type, the identifier of the new detection rule node, the birth timestamp, and the identifier of the source embryo node. After the embryo node has completed its division, it is removed from the rule knowledge graph, and the birth event is stored in the meta-knowledge graph as a birth event node.

[0012] Optionally, the storage of the extinction event in the meta-knowledge graph specifically includes: Set a lifecycle management cycle. When each management cycle arrives, obtain all currently active detection rule nodes in the rule knowledge graph and generate a set of rule nodes to be evaluated. Iterate through each detection rule node in the set of rule nodes to be evaluated, collect the running data of the current detection rule node in the previous management cycle, and generate the running data set of the current detection rule node. The running data includes the number of hits, the number of false alarms, the number of missed alarms, and the total number of API requests covered. Based on the current set of running data of the current detection rule node, calculate the accuracy and activity metrics of the current detection rule node; Calculate the timeliness index of the current detection rule node based on its creation time and current time; Based on the accuracy, activity, and timeliness metrics of the current detection rule nodes, calculate the effectiveness metrics of the current detection rule nodes. The validity index of the current detection rule node is compared with the apoptosis threshold. When the validity index is lower than the apoptosis threshold, the current detection rule node is marked as apoplexy and added to the set of rule nodes to be removed. Traverse each detection rule node to be removed in the set of rule nodes to be removed, start a confirmation period, and continue to monitor the performance of the current detection rule node to be removed during the confirmation period. If the effectiveness index of the current detection rule node to be removed rises above the apoptosis threshold during the confirmation period, the current detection rule node to be removed is removed from the set of rule nodes to be removed and restored to an active state. If the effectiveness index is still below the apoptosis threshold after the confirmation period ends, the current detection rule node to be removed is officially removed from the rule knowledge graph and a death event is generated. The death event includes the event type, the identifier of the removed detection rule node, and the death timestamp. Each disappearance event is stored as an disappearance event node in the meta-knowledge graph.

[0013] Optionally, the generation of the vulnerability detection results specifically includes: Extract all rule evolution events within the current detection period from the meta-knowledge graph, including conflict events, birth events, and death events. Each event has a unique event identifier, event type, associated detection rule node identifier, and event occurrence timestamp, forming a set of rule evolution events. Based on the rule evolution event set, all events are sorted according to timestamps. The temporal relationship between events is constructed according to the detection rule node identifiers corresponding to the events. When two events satisfy the order of occurrence, the continuous relationship of event types, or the common associated detection rule nodes, an association link between them is established. Pre-defined event association pattern templates, each of which consists of an event type sequence, event occurrence order requirements, and inter-event association links; Based on the temporal correlation and the correlation link between events, structural matching is performed with each event correlation pattern template. The arrangement of event types, the order of the correlation link between events, and the connection relationship between events are compared to obtain the pattern matching result corresponding to each event correlation pattern template. The matched event combinations and the correlation links between events are recorded. Based on the pattern matching results, participation statistics are performed on all detection rule nodes. The number of times each detection rule node appears in different event relationship chains, the types of events involved, and the order of their positions in event combinations are recorded. The pattern participation attribute set of each detection rule node is formed through statistics. The pattern-participating attribute set is classified according to event type. Events belonging to the positive evolution of rules are used to generate maturity threshold adjustment information, and events belonging to the decay trend of rules are used to generate apoptosis threshold adjustment information. By merging the adjustment information, updated maturity thresholds and apoptosis thresholds are formed. For each conflict event in the event set, the detection rule node group associated with the conflict event is extracted. The number of times the conflict occurs, the location of the conflict, and the evolution trajectory after the conflict are analyzed in the event chain of the detection rule node group. The conflict resolution method update content is formed, including the reset of the conflict rule priority, the correction of the conflict triggering conditions, and the update of the conflict association chain attributes. The updated maturity threshold, apoptosis threshold, and conflict resolution method are uniformly written into the rule knowledge graph. In subsequent detection cycles, the complete business context subgraph generated by real-time API call requests is input into the updated rule knowledge graph, and the final vulnerability detection result is output based on the latest attributes and associated links of the rule nodes.

[0014] The beneficial effects of this invention are: This invention introduces a three-layered association structure of business knowledge graph, rule knowledge graph, and meta-knowledge graph into the e-commerce API interface security detection system. This enables semantic modeling and evolvable expression of e-commerce business interface behavior, overcoming the technical bottlenecks of traditional rule matching methods, such as insufficient business understanding, rule rigidity, and limited detection boundaries. By constructing a business knowledge graph, API logs and document information are uniformly extracted, entityized, and linked, enabling real-time API calls to be accurately located within the business context. This achieves deep semantic recognition oriented towards the business chain. By constructing a rule knowledge graph, detection rules are systematically expressed as reasonable, constrained, and updatable rule nodes and logical relationship structures. This ensures that mutual exclusion, inclusion, and priority relationships between rules remain clear and operable within the graph structure, improving the rule system's adaptability to complex scenarios. By constructing a meta-knowledge graph, conflict events, birth events, and death events are uniformly incorporated into a temporal structure, enabling continuous monitoring, evolution recording, and lifecycle management of the rule system.

[0015] This invention introduces an embryonic node mechanism through structured clustering analysis of abnormal traffic samples, enabling the detection system to automatically generate new detection rules from previously uncovered abnormal patterns without relying on manual updates. This significantly improves the system's responsiveness to unknown risks. Furthermore, the dynamic adjustment mechanism for maturity and apoptosis thresholds proposed in this invention makes the rule system's evolution adaptive, allowing for rule strengthening or elimination based on actual operational performance. This ensures long-term rule validity and avoids redundancy or false alarm accumulation caused by rule accumulation. In addition, the conflict resolution mechanism proposed in this invention allows the system to perform structured analysis and proactive correction of rule conflicts, enabling the rule system to self-correct during operation and avoid misjudgments caused by rule contradictions. By matching and analyzing the event structure during operation with the rule evolution pattern, this invention achieves self-evolution, self-optimization, and self-repair of the detection system. This ensures that vulnerability detection results are always based on the latest and most reasonable rule system output, thus providing higher coverage, accuracy, and long-term stability when dealing with constantly evolving e-commerce API security risks. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a knowledge graph-based e-commerce API interface security vulnerability detection method proposed in this invention; Figure 2 This is a schematic diagram illustrating the abnormal traffic sample aggregation and embryo node evolution process of a knowledge graph-based e-commerce API interface security vulnerability detection method proposed in this invention. Figure 3 This is a schematic diagram of the rule validity evaluation and apoptosis event generation process of a knowledge graph-based e-commerce API interface security vulnerability detection method proposed in this invention. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0018] refer to Figures 1-3 A method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs includes the following steps: Collect API gateway logs and API documentation data from e-commerce systems to build a business knowledge graph; Obtain an initial vulnerability detection rule base, convert each vulnerability detection rule into a rule node, construct edges based on the logical relationships between rules, and form a rule knowledge graph; A meta-knowledge graph is constructed using the rule evolution events that have occurred in the rule knowledge graph as nodes and the temporal relationships between events as edges. Map real-time API call requests to the business knowledge graph, and call the rules in the rule knowledge graph for matching and detection; When multiple rules output conflicting results during matching detection, the conflicting edges are marked and the conflict events are stored in the meta-knowledge graph. When abnormal traffic patterns in the monitoring business knowledge graph are not covered by existing rules, an embryo node is created in the rule knowledge graph to aggregate abnormal traffic patterns with the same structural features. When the aggregation reaches the maturity threshold, a new rule node is generated and stored in the meta-knowledge graph as a birth event. The validity index of each rule in the periodic calculation rule knowledge graph is used. When it falls below the apoptosis threshold, the rule node is removed and stored in the meta-knowledge graph as an extinction event. Based on rule evolution events in the meta-knowledge graph, the association patterns between events are analyzed through graph pattern matching. The analysis results are then updated to maturity thresholds, apoptosis thresholds, or conflict resolution methods. The updated rule knowledge graph is then used to detect API call requests and generate vulnerability detection results.

[0019] In this embodiment, the construction of the business knowledge graph specifically includes: API log parsing, API document structuring, business entity extraction, interface node generation, entity relationship establishment, log document fusion, graph structure organization, graph node updating, and business knowledge graph formation.

[0020] In this embodiment, the generation of the rule knowledge graph specifically includes: The initial vulnerability detection rule base is read, and the rule identifier, applicable API scope, triggering conditions, detection constraints and detection conclusions of each vulnerability detection rule are obtained in sequence. All vulnerability detection rules are numbered and organized to form an initial vulnerability detection rule list. Based on the initial list of vulnerability detection rules, a corresponding rule node is created for each vulnerability detection rule. The rule node contains the rule node identifier, rule identifier, rule type information, and scope of application information. All rule nodes are then aggregated to form a rule node set. For any two rule nodes in the rule node set, based on the logical relationship entries set in the vulnerability detection rule base, extract the logical attribute information between the two rule nodes, including mutual exclusion, inclusion, priority and independence relationships, and organize the logical attribute information into a list of logical relationships between rules; Based on the set of rule nodes and the list of logical relationships between rules, a logical relationship edge is established for each pair of rule nodes with logical relationships, including logical relationship type, priority identifier, mutual exclusion identifier and association direction information. The constructed logical relationship edges are then gathered to form a logical relationship edge set. Perform consistency normalization processing on the attribute fields of all rule nodes in the rule node set, including unifying the rule node identifier field, rule type description, rule scope field, and rule status field. Perform unified organization on the attribute fields of all logical relation edges in the logical relation edge set, including unifying the logical relation type field, priority field, and conflict flag field. By combining the standardized set of rule nodes with the set of logical relationship edges, a rule knowledge graph composed of rule nodes and logical relationship edges is formed.

[0021] In this embodiment, constructing the meta-knowledge graph specifically includes: Collect a set of rule evolution events that have occurred from the rule knowledge graph. Each rule evolution event contains a unique event identifier, event type, rule node identifier associated with the event, and event timestamp. Event types include conflict events, birth events, and extinction events. Each rule evolution event is transformed into an event node in the meta-knowledge graph. The attributes of the event node include the event type and the event occurrence timestamp. For any two rule evolution events, when the timestamp of the later event is later than the timestamp of the earlier event, a time-series edge is constructed between the corresponding event nodes. The attributes of the time-series edge include the time interval between the two events. For multiple event nodes with the same rule node identifier, time-series edges are constructed sequentially according to the timestamp order to form the lifecycle path of the corresponding rule node; A meta-knowledge graph is constructed based on all event nodes and all temporal edges.

[0022] In this embodiment, the matching detection specifically includes: Receive real-time API call requests, parse the request method, request path, request parameters, request headers and session identifier of the real-time API call requests, and generate a set of entity information; Match the entity information set with the business entity nodes in the business knowledge graph to generate the business entity node corresponding to each entity; Based on the request path of the real-time API call request, the API interface node is located in the business knowledge graph, and the API interface node is associated with the business entity node to generate the request subgraph of the real-time API call request in the business knowledge graph. Obtain the session identifier of the real-time API call request, read the historical API call sequence of the session within the time window based on the session identifier, process each historical API call request in the historical API call sequence in the same way, and generate a historical request subgraph sequence. By concatenating the request subgraph with the historical request subgraph sequence, a complete business context subgraph of real-time API call requests is generated; All detection rule nodes are obtained from the rule knowledge graph, and each detection rule node is associated with a graph pattern query statement to generate a set of detection rule nodes; The complete business context subgraph is matched with the graph pattern query statement associated with each detection rule node in the detection rule node set. For each detection rule node, the hit determination result of that rule node is generated. Collect the hit determination results of all detection rule nodes and generate a set of matching detection results for real-time API call requests.

[0023] In this embodiment, storing the meta-knowledge graph specifically includes: Obtain the matching detection result set, extract the identifiers of all hit detection rule nodes from the matching detection result set, and generate the hit rule set for real-time API call requests; Iterate through each pair of detection rule nodes in the hit rule set, read the pre-built logical relationship edges between each pair of detection rule nodes from the rule knowledge graph, and generate the logical relationship edge type for each pair of detection rule nodes; For each pair of detection rule nodes, a conflict determination result is generated based on the logical relationship edge type and the detection conclusions output by the two rules. When the conflict determination result is that a conflict exists, the logical relationship edge between the pair of detection rule nodes is marked as active in the rule knowledge graph, and a conflict event is generated. For each generated conflict event, construct a conflict event information tuple, which includes a unique identifier for the conflict event, the event type, the identifier of the first rule node, the identifier of the second rule node, and the timestamp of the conflict occurrence; The conflict event information tuples are stored as conflict event nodes in the meta-knowledge graph.

[0024] In this embodiment, storing the birth event in the meta-knowledge graph specifically includes: Real-time monitoring of API call traffic in the business knowledge graph; collection of API call requests that were not detected by any detection rules within the time window; and generation of an abnormal traffic sample set. For each abnormal traffic sample in the abnormal traffic sample set, extract its request subgraph structure features in the business knowledge graph to generate a structure feature vector for each abnormal traffic sample. Cluster analysis is performed on the structural feature vectors of all abnormal traffic samples, and abnormal traffic samples with the same structural feature vectors are aggregated into the same cluster to generate a set of clusters. Traverse each cluster in the cluster set. When the number of samples in the current cluster reaches the embryo creation threshold, create an embryo node in the rule knowledge graph. The attributes of the embryo node include the creation timestamp, the current aggregation amount, and the average structural feature vector of the current cluster. Creating an embryo node specifically includes: The process involves: acquiring clusters that have reached the embryo creation threshold; reading the number of samples in each cluster, the corresponding structural feature vectors of the samples, and the cluster generation time; recording the creation timestamp of the embryo node based on the cluster generation time and writing this timestamp into the embryo node's creation attribute; generating the current aggregation quantity of the embryo node based on the number of samples in the cluster and writing this current aggregation quantity into the embryo node's aggregation attribute; calculating the mean of all structural feature vectors in the cluster to obtain the average structural feature vector of the cluster and writing this average structural feature vector into the feature attribute field of the embryo node; generating the embryo node entity in the rule knowledge graph and writing the creation timestamp, current aggregation quantity, and average structural feature vector into all attribute fields of the embryo node to complete the embryo node creation. New abnormal traffic samples are received in real time. The structural feature vector of each new abnormal traffic sample is extracted. When the similarity between the structural feature vector of the current new abnormal traffic sample and the average structural feature vector of any embryo node is greater than the aggregation threshold, the current new abnormal traffic sample is aggregated into the corresponding embryo node, and the current aggregation amount and average structural feature vector of the embryo node are updated. The specific nodes of the aggregated embryo node include: For newly received abnormal traffic samples, structural feature vectors are extracted. The extracted structural feature vectors are then compared with the average structural feature vectors of existing embryonic nodes. When the similarity exceeds the aggregation threshold, the new abnormal traffic sample is assigned to the corresponding embryonic node. The current aggregation value of the assigned embryonic node is updated and written into the aggregation attribute field of the embryonic node. Based on all assigned abnormal traffic samples, the average structural feature vector of the embryonic node is recalculated and written into the feature attribute field of the embryonic node. Traverse each embryo node in the rule knowledge graph. When the current aggregation amount of the current embryo node reaches the maturity threshold, trigger the split operation and generate a new detection rule node based on the common features of the abnormal traffic samples aggregated by the current embryo node. The splitting operation specifically includes: Embryo nodes that have reached the maturity threshold are acquired, and the set of anomalous traffic samples aggregated for that embryo node is read. The structural feature vectors of the anomalous traffic sample set are used for feature induction to extract common features that represent the aggregated sample set. Based on these common features, the rule attribute information required for the detection rules is constructed, including rule identifier, rule type, and rule scope. New detection rule nodes are generated in the rule knowledge graph, and the rule attributes formed by the common features are written into the attribute fields of these detection rule nodes. The newly generated detection rule nodes are added to the rule knowledge graph, completing the splitting process from embryo node to detection rule node. The newly generated detection rule node is added to the rule knowledge graph, generating a birth event. The birth event includes the event type, the identifier of the new detection rule node, the birth timestamp, and the identifier of the source embryo node. After the embryo node has completed its division, it is removed from the rule knowledge graph, and the birth event is stored in the meta-knowledge graph as a birth event node.

[0025] In this embodiment, storing the extinction event in the meta-knowledge graph specifically includes: Set a lifecycle management cycle. When each management cycle arrives, obtain all currently active detection rule nodes in the rule knowledge graph and generate a set of rule nodes to be evaluated. Iterate through each detection rule node in the set of rule nodes to be evaluated, collect the running data of the current detection rule node in the previous management cycle, and generate the running data set of the current detection rule node. The running data includes the number of hits, the number of false alarms, the number of missed alarms, and the total number of API requests covered. Based on the current set of running data of the current detection rule node, calculate the accuracy and activity metrics of the current detection rule node; Calculate the timeliness index of the current detection rule node based on its creation time and current time; The generation of timeliness indicators specifically includes: Obtain the birth time of the current detection rule node and record it as the start time of the rule node; read the current time of the current detection rule node and use it as the evaluation time of the rule node; generate the timeliness value of the rule node based on the time interval between the start time and the evaluation time, and write the duration represented by the time interval into the timeliness attribute field of the detection rule node. Based on the accuracy, activity, and timeliness metrics of the current detection rule nodes, calculate the effectiveness metrics of the current detection rule nodes. The generation of effectiveness indicators specifically includes: Obtain the accuracy, activity, and timeliness metrics of the current detection rule node, and use these three metrics as input parameters for calculating the validity metric; normalize the three metrics to generate a standardized parameter set for validity judgment; comprehensively quantify the performance of the current detection rule node based on the standardized parameter set to generate the validity value of the detection rule node; and write the validity value into the validity attribute field of the detection rule node. The validity index of the current detection rule node is compared with the apoptosis threshold. When the validity index is lower than the apoptosis threshold, the current detection rule node is marked as apoplexy and added to the set of rule nodes to be removed. Traverse each detection rule node to be removed in the set of rule nodes to be removed, start a confirmation period, and continue to monitor the performance of the current detection rule node to be removed during the confirmation period. If the effectiveness index of the current detection rule node to be removed rises above the apoptosis threshold during the confirmation period, the current detection rule node to be removed is removed from the set of rule nodes to be removed and restored to an active state. If the effectiveness index is still below the apoptosis threshold after the confirmation period ends, the current detection rule node to be removed is officially removed from the rule knowledge graph and a death event is generated. The death event includes the event type, the identifier of the removed detection rule node, and the death timestamp. The generation of extinction events specifically includes: For detection rule nodes that are still below the apoptosis threshold after the confirmation period ends, the identifier of the detection rule node is used as the identification information of the rule node to be removed; the time information of the detection rule node at the end of the confirmation period is recorded, and the recorded time is used as the extinction timestamp; the event attributes of the extinction event are generated based on the identification information of the rule node to be removed and the extinction timestamp. The event attributes include the event type, the identifier of the removed detection rule node, and the extinction timestamp. Each disappearance event is stored as an disappearance event node in the meta-knowledge graph.

[0026] In this embodiment, the generation of vulnerability detection results specifically includes: Extract all rule evolution events within the current detection period from the meta-knowledge graph, including conflict events, birth events, and death events. Each event has a unique event identifier, event type, associated detection rule node identifier, and event occurrence timestamp, forming a set of rule evolution events. Based on the rule evolution event set, all events are sorted according to timestamps. The temporal relationship between events is constructed according to the detection rule node identifiers corresponding to the events. When two events satisfy the order of occurrence, the continuous relationship of event types, or the common associated detection rule nodes, an association link between them is established. Pre-defined event association pattern templates, each of which consists of an event type sequence, event occurrence order requirements, and inter-event association links; Based on the temporal correlation and the correlation link between events, structural matching is performed with each event correlation pattern template. The arrangement of event types, the order of the correlation link between events, and the connection relationship between events are compared to obtain the pattern matching result corresponding to each event correlation pattern template. The matched event combinations and the correlation links between events are recorded. The generation of pattern matching results specifically includes: Based on the temporal correlation between events, the time sequence information of events is obtained, and the correlation links between events are read to determine the connection order between events. The event type sequence, event arrangement order, and correlation links between events are compared one by one with the preset event association pattern template. The consistency of event types, the continuity of event order, and the matching of correlation links are checked accordingly. During the check, event combinations that meet the requirements of event type sequence, event order, and correlation links are selected, and the selected event combinations are used as the event set corresponding to pattern matching. For each successfully matched event combination, a record of the correlation links between events is established, and the event combinations and their correlation links are combined to form the pattern matching result. Based on the pattern matching results, participation statistics are performed on all detection rule nodes. The number of times each detection rule node appears in different event relationship chains, the types of events involved, and the order of their positions in event combinations are recorded. The pattern participation attribute set of each detection rule node is formed through statistics. The pattern-participating attribute set is classified according to event type. Events belonging to the positive evolution of rules are used to generate maturity threshold adjustment information, and events belonging to the decay trend of rules are used to generate apoptosis threshold adjustment information. By merging the adjustment information, updated maturity thresholds and apoptosis thresholds are formed. The generation of the updated maturity threshold and apoptosis threshold specifically includes: The event combinations in the pattern participation attribute set are classified according to event type. For event combinations marked as having a positive rule evolution, their occurrence frequency and positional order attributes are read one by one. The occurrence frequency and positional order attributes are statistically accumulated to form a statistic used for adjusting the maturity threshold. For event combinations marked as having a rule decay trend, their occurrence frequency and positional order attributes are read one by one. The occurrence frequency and positional order attributes are statistically accumulated to form a statistic used for adjusting the apoptosis threshold. An update value for the maturity threshold is generated based on the maturity threshold statistics and written into the maturity threshold. Similarly, an update value for the apoptosis threshold is generated based on the apoptosis threshold statistics and written into the apoptosis threshold. This yields the updated maturity threshold and apoptosis threshold. For each conflict event in the event set, the detection rule node group associated with the conflict event is extracted. The number of times the conflict occurs, the location of the conflict, and the evolution trajectory after the conflict are analyzed in the event chain of the detection rule node group. The conflict resolution method update content is formed, including the reset of the conflict rule priority, the correction of the conflict triggering conditions, and the update of the conflict association chain attributes. The generation of conflict resolution method update content specifically includes: Based on the conflict event, the corresponding detection rule node group is extracted. The conflict occurrence frequency attribute, conflict location attribute, and post-conflict evolution trajectory attribute of the detection rule node group in the event chain are read. The conflict occurrence frequency attribute is statistically processed to generate frequency data for determining the priority adjustment of the conflict rule. The conflict location attribute is organized to generate location information data for correcting the conflict triggering conditions. The post-conflict evolution trajectory attribute is obtained to generate trajectory data for updating the conflict-related link attributes. The frequency data is written to the conflict rule priority adjustment field, the location information data is written to the conflict triggering condition update field, and the trajectory data is written to the conflict-related link attribute update field. This constitutes the conflict resolution method update content of the conflict rule and is associated with the corresponding conflict event record. The updated maturity threshold, apoptosis threshold, and conflict resolution method are uniformly written into the rule knowledge graph. In subsequent detection cycles, the complete business context subgraph generated by real-time API call requests is input into the updated rule knowledge graph, and the final vulnerability detection result is output based on the latest attributes and associated links of the rule nodes.

[0027] Example 1: To verify the feasibility of this invention in practice, it was applied to the API call security detection scenario of an e-commerce platform. The actual operating environment before and after a large-scale promotion was selected as the verification environment. In this e-commerce platform, there are many API interfaces, complex call chains, and significant fluctuations in business traffic. During the promotion, there are a large number of users accessing the platform concurrently, interface parameters change frequently, and call chains span multiple business entities. This makes it difficult for existing static rule-based detection methods to accurately identify security risks. Especially with the continuous adjustment of interface logic, frequent changes in permission policies, and the continuous integration of third-party applications, traditional methods often suffer from problems such as rule lag, inability to handle rule conflicts in a timely manner, and the neglect of new suspicious requests that are not covered. Therefore, this invention selects the above-mentioned environment as the implementation scenario. Through the multi-knowledge graph fusion mechanism, rule self-evolution mechanism, and event-driven dynamic threshold adjustment mechanism proposed in this invention, the API access behavior of the e-commerce platform at different stages before and after the promotion is continuously monitored to verify the adaptability and detection effectiveness of this invention in complex scenarios.

[0028] During implementation, entity information suitable for building a business knowledge graph was continuously extracted from access records and interface maintenance documents generated by the e-commerce platform's API gateway. This included user information, permissions, interface paths, parameter structures, and request context relationships. Through entity extraction, relationship recognition, and structural fusion, a stable business knowledge graph representing business logic, call flow, and interface semantics was formed. This enabled API call behavior to generate corresponding request subgraphs within the knowledge graph, which were then contextually concatenated with historical call sequences. Next, the platform's original rule-based detection method was restructured. Based on a pre-defined security detection rule library, each rule was constructed as a rule node, and logical edges were established for inclusion, triggering, and mutual exclusion relationships between rules, thus forming a rule knowledge graph. During this process, all rule attributes were written into the graph nodes in a structured manner, allowing each rule to be invoked and reasoned about in a clearly defined relational form within the graph structure.

[0029] As promotional traffic increases, in scenarios with rapid business changes, some API calls may trigger different conclusions from multiple rules. For example, the same request may be judged as abnormal by one rule and normal by another. In traditional methods, such conflicts are often difficult to identify and handle effectively. However, in the implementation of this invention, such phenomena are automatically recorded as "conflict events" in the meta-knowledge graph. The meta-knowledge graph organizes all conflict events, birth events, and death events into an evolutionary chain in chronological order to form an event structure that can be used for subsequent pattern analysis. During promotions, due to the addition of fields to some interfaces and changes in the order of calls, a large number of API requests that were not hit by the original rules appeared. These requests are identified by the abnormal traffic monitoring method of this invention and aggregated into an abnormal traffic sample set. For abnormal traffic that has been aggregated to a certain extent, this invention will automatically create embryonic nodes and continuously absorb subsequent abnormal requests with similar structures. Finally, when the aggregation reaches the maturity threshold, the embryonic nodes automatically split into new detection rule nodes, so that the previously unrecognizable abnormal behavior is successfully defined as a new detection rule.

[0030] Throughout the promotional period, the rule knowledge graph continuously accumulates new rule nodes. Simultaneously, some rules gradually become invalid due to business changes. This invention, through a lifecycle management mechanism, performs validity analysis on all active rules at the end of each detection cycle, including hit performance, false positives, and timeliness. When the validity of a rule consistently falls below a set threshold, this invention marks it as a target for removal and initiates a confirmation cycle. If the rule fails to regain validity within the confirmation cycle, it is removed from the rule knowledge graph, and its corresponding "extinction event" is stored in the meta-knowledge graph to form a complete rule lifecycle record. In this process, this invention not only automatically identifies rule decay but also ensures that valid rules are not mistakenly deleted due to short-term business fluctuations, making rule evolution more robust.

[0031] As a large number of events accumulate in the meta-knowledge graph, this invention further utilizes pattern matching technology to identify structural patterns of rule evolution in event chains. This automatically generates adjustments to maturity thresholds, apoptosis thresholds, and conflict resolution methods. For example, during multiple promotional activities, if a certain type of rule continuously exhibits chain-like combinations of birth events, this invention automatically increases the maturity threshold of that type of rule, enabling future similar abnormal behaviors to be identified and categorized more quickly. If a certain type of rule continuously exhibits event combinations with decreasing effectiveness across multiple cycles, this invention automatically lowers its apoptosis threshold, making that type of rule easier to eliminate. If conflict events repeatedly appear in certain rule chains, this invention automatically updates the priority and conflict triggering conditions of these rules based on the number and location of conflicts, effectively suppressing the generation of conflict edges.

[0032] In this embodiment, by continuously running the method in three stages—before the promotion begins, during the promotion peak, and after the promotion ends—the e-commerce platform's API interface can maintain stable security detection performance even in the face of surging traffic, frequent changes in interface structure, and increased attempts at black market attacks. Because this invention has the ability to automatically generate new rules, automatically adjust thresholds, and automatically resolve conflicts, the detection mechanism can remain synchronized with business changes without manual updates. During continuous monitoring, the performance of existing rules in the system is automatically corrected, multiple invalid rules are identified and removed, multiple new rules are automatically generated from abnormal patterns, the number of conflicts between rules is significantly reduced, and the detection path becomes clearer and more reliable. All of these changes actually occur in the business environment during the promotion period. Overall, this demonstrates that this invention can maintain the continuous effectiveness of detection capabilities through a knowledge graph-driven evolution mechanism, enabling security detection to remain efficient and stable even in rapidly changing e-commerce scenarios.

[0033] Table 1. Performance comparison between the method of this invention and traditional rule detection methods

[0034] As shown in Table 1, the present invention demonstrates a stable improvement in overall performance compared to traditional methods, particularly in anomaly detection accuracy and recall. The present invention leverages a business semantic context constructed from a business knowledge graph, freeing detection from limitations on parameter features and static rules. This enables more accurate identification of potential risks in complex calls. Traditional methods, which have weak semantic characterization capabilities in complex links, achieve only 79.6% accuracy and 72.8% recall. The present invention, through entity association and call relationship modeling in the graph, improves these metrics to 87.4% and 82.1%, respectively, exhibiting a significant and stable advantage. Furthermore, the present invention utilizes anomaly traffic clustering and embryo node generation mechanisms, nearly doubling the detection rate of novel anomalies compared to traditional methods, while maintaining the difference within a credible range. This indicates that the present invention enhances the ability to capture unknown risks without exaggeration.

[0035] From the perspectives of rule conflict control and rule evolution efficiency, the improvements of this invention are also significant. Traditional methods, lacking logical structure between rules, result in an average of 18 rule conflicts per week. This invention reduces this to 9 times per week through logical relationship edges and conflict event recording, effectively alleviating the rule conflict problem. The false positive and false negative rates also decrease significantly. This is closely related to the improved rule adaptability brought about by graph-based business modeling, refined expression of rule nodes, and evolution mechanism. This invention also has outstanding advantages in rule update response speed: traditional methods rely on manual analysis and manual rule expansion, which takes nearly 30 hours on average to update; this invention, relying on embryo nodes and maturity threshold mechanisms, can generate new rule nodes in less than six hours, significantly improving the response efficiency of rule updates. At the same time, this invention can generate more new rules and clean up a certain number of redundant rules every week, keeping the rule system highly active and concise, and reducing the risk of misjudgment caused by rule aging.

[0036] The fundamental reason for the performance improvement of this invention lies in mapping the e-commerce API call process to a three-layer structure of business knowledge graph, rule knowledge graph, and meta-knowledge graph. Through an event-driven mechanism, the rules achieve self-evolution, self-repair, and self-update. The graph structure enhances the detection's understanding of business semantics, the anomaly clustering and splitting mechanism enhances the ability to identify new attack types, the threshold dynamic adjustment mechanism strengthens the rule's adaptability, and the conflict resolution mechanism reduces inconsistencies within the rule system. Under the combined effect of these mechanisms, this invention achieves continuous improvement in detection effect, detection stability, and rule lifecycle health while maintaining a reasonable performance gap.

[0037] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs, characterized in that, Includes the following steps: Collect API gateway logs and API documentation data from e-commerce systems to build a business knowledge graph; Obtain the initial vulnerability detection rule base, convert each vulnerability detection rule into a rule node, construct edges based on the logical relationships between rules, and form a rule knowledge graph; A meta-knowledge graph is constructed using the rule evolution events that have occurred in the rule knowledge graph as nodes and the temporal relationships between events as edges. Map real-time API call requests to the business knowledge graph, and call the rules in the rule knowledge graph for matching and detection; When multiple rules output conflicting results during matching detection, the conflicting edges are marked and the conflict events are stored in the meta-knowledge graph. When abnormal traffic patterns in the monitoring business knowledge graph are not covered by existing rules, an embryo node is created in the rule knowledge graph to aggregate abnormal traffic patterns with the same structural features. When the aggregation reaches the maturity threshold, a new rule node is generated and stored in the meta-knowledge graph as a birth event. The validity index of each rule in the periodic calculation rule knowledge graph is used. When it falls below the apoptosis threshold, the rule node is removed and stored in the meta-knowledge graph as an extinction event. Based on rule evolution events in the meta-knowledge graph, the association patterns between events are analyzed through graph pattern matching. The analysis results are then updated to maturity thresholds, apoptosis thresholds, or conflict resolution methods. The updated rule knowledge graph is then used to detect API call requests and generate vulnerability detection results.

2. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The construction of the business knowledge graph specifically includes: API log parsing, API document structuring, business entity extraction, interface node generation, entity relationship establishment, log document fusion, graph structure organization, graph node updating, and business knowledge graph formation.

3. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The generation of the rule-based knowledge graph specifically includes: The initial vulnerability detection rule base is read, and the rule identifier, applicable API scope, triggering conditions, detection constraints and detection conclusions of each vulnerability detection rule are obtained in sequence. All vulnerability detection rules are numbered and organized to form an initial vulnerability detection rule list. Based on the initial list of vulnerability detection rules, a corresponding rule node is created for each vulnerability detection rule. The rule node contains the rule node identifier, rule identifier, rule type information, and scope of application information. All rule nodes are then aggregated to form a rule node set. For any two rule nodes in the rule node set, based on the logical relationship entries set in the vulnerability detection rule base, extract the logical attribute information between the two rule nodes, including mutual exclusion, inclusion, priority and independence relationships, and organize the logical attribute information into a list of logical relationships between rules; Based on the set of rule nodes and the list of logical relationships between rules, a logical relationship edge is established for each pair of rule nodes with logical relationships, including logical relationship type, priority identifier, mutual exclusion identifier and association direction information. The constructed logical relationship edges are then gathered to form a logical relationship edge set. Perform consistency normalization processing on the attribute fields of all rule nodes in the rule node set, including unifying the rule node identifier field, rule type description, rule scope field, and rule status field. Perform unified organization on the attribute fields of all logical relation edges in the logical relation edge set, including unifying the logical relation type field, priority field, and conflict flag field. By combining the standardized set of rule nodes with the set of logical relationship edges, a rule knowledge graph composed of rule nodes and logical relationship edges is formed.

4. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The construction of the meta-knowledge graph specifically includes: Collect a set of rule evolution events that have occurred from the rule knowledge graph. Each rule evolution event contains a unique event identifier, event type, rule node identifier associated with the event, and event timestamp. Event types include conflict events, birth events, and extinction events. Each rule evolution event is transformed into an event node in the meta-knowledge graph. The attributes of the event node include the event type and the event occurrence timestamp. For any two rule evolution events, when the timestamp of the later event is later than the timestamp of the earlier event, a time-series edge is constructed between the corresponding event nodes. The attributes of the time-series edge include the time interval between the two events. For multiple event nodes with the same rule node identifier, time-series edges are constructed sequentially according to the timestamp order to form the lifecycle path of the corresponding rule node; A meta-knowledge graph is constructed based on all event nodes and all temporal edges.

5. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The matching detection specifically includes: Receive real-time API call requests, parse the request method, request path, request parameters, request headers and session identifier of the real-time API call requests, and generate a set of entity information; Match the entity information set with the business entity nodes in the business knowledge graph to generate the business entity node corresponding to each entity; Based on the request path of the real-time API call request, the API interface node is located in the business knowledge graph, and the API interface node is associated with the business entity node to generate the request subgraph of the real-time API call request in the business knowledge graph. Obtain the session identifier of the real-time API call request, read the historical API call sequence of the session within the time window based on the session identifier, process each historical API call request in the historical API call sequence in the same way, and generate a historical request subgraph sequence. By concatenating the request subgraph with the historical request subgraph sequence, a complete business context subgraph of real-time API call requests is generated; All detection rule nodes are obtained from the rule knowledge graph, and each detection rule node is associated with a graph pattern query statement to generate a set of detection rule nodes; The complete business context subgraph is matched with the graph pattern query statement associated with each detection rule node in the detection rule node set. For each detection rule node, the hit determination result of that rule node is generated. Collect the hit determination results of all detection rule nodes and generate a set of matching detection results for real-time API call requests.

6. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The stored meta-knowledge graph specifically includes: Obtain the matching detection result set, extract the identifiers of all hit detection rule nodes from the matching detection result set, and generate the hit rule set for real-time API call requests; Iterate through each pair of detection rule nodes in the hit rule set, read the pre-built logical relationship edges between each pair of detection rule nodes from the rule knowledge graph, and generate the logical relationship edge type for each pair of detection rule nodes; For each pair of detection rule nodes, a conflict determination result is generated based on the logical relationship edge type and the detection conclusions output by the two rules. When the conflict determination result is that a conflict exists, the logical relationship edge between the pair of detection rule nodes is marked as active in the rule knowledge graph, and a conflict event is generated. For each generated conflict event, construct a conflict event information tuple, which includes a unique identifier for the conflict event, the event type, the identifier of the first rule node, the identifier of the second rule node, and the timestamp of the conflict occurrence; The conflict event information tuples are stored as conflict event nodes in the meta-knowledge graph.

7. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The specific items included in storing the birth event in the meta-knowledge graph are: Real-time monitoring of API call traffic in the business knowledge graph; collection of API call requests that were not detected by any detection rules within the time window; and generation of an abnormal traffic sample set. For each abnormal traffic sample in the abnormal traffic sample set, extract its request subgraph structure features in the business knowledge graph to generate a structure feature vector for each abnormal traffic sample. Cluster analysis is performed on the structural feature vectors of all abnormal traffic samples, and abnormal traffic samples with the same structural feature vectors are aggregated into the same cluster to generate a set of clusters. Traverse each cluster in the cluster set. When the number of samples in the current cluster reaches the embryo creation threshold, create an embryo node in the rule knowledge graph. The attributes of the embryo node include the creation timestamp, the current aggregation amount, and the average structural feature vector of the current cluster. New abnormal traffic samples are received in real time. The structural feature vector of each new abnormal traffic sample is extracted. When the similarity between the structural feature vector of the current new abnormal traffic sample and the average structural feature vector of any embryo node is greater than the aggregation threshold, the current new abnormal traffic sample is aggregated into the corresponding embryo node, and the current aggregation amount and average structural feature vector of the embryo node are updated. Traverse each embryo node in the rule knowledge graph. When the current aggregation amount of the current embryo node reaches the maturity threshold, trigger the split operation and generate a new detection rule node based on the common features of the abnormal traffic samples aggregated by the current embryo node. The newly generated detection rule node is added to the rule knowledge graph, generating a birth event. The birth event includes the event type, the identifier of the new detection rule node, the birth timestamp, and the identifier of the source embryo node. After the embryo node has completed its division, it is removed from the rule knowledge graph, and the birth event is stored in the meta-knowledge graph as a birth event node.

8. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The specific items included in the storage of the extinction events in the meta-knowledge graph are: Set a lifecycle management cycle. When each management cycle arrives, obtain all currently active detection rule nodes in the rule knowledge graph and generate a set of rule nodes to be evaluated. Iterate through each detection rule node in the set of rule nodes to be evaluated, collect the running data of the current detection rule node in the previous management cycle, and generate the running data set of the current detection rule node. The running data includes the number of hits, the number of false alarms, the number of missed alarms, and the total number of API requests covered. Based on the current set of running data of the current detection rule node, calculate the accuracy and activity metrics of the current detection rule node; Calculate the timeliness index of the current detection rule node based on its creation time and current time; Based on the accuracy, activity, and timeliness metrics of the current detection rule nodes, calculate the effectiveness metrics of the current detection rule nodes. The validity index of the current detection rule node is compared with the apoptosis threshold. When the validity index is lower than the apoptosis threshold, the current detection rule node is marked as apoplexy and added to the set of rule nodes to be removed. Traverse each detection rule node to be removed in the set of rule nodes to be removed, start a confirmation period, and continue to monitor the performance of the current detection rule node to be removed during the confirmation period. If the effectiveness index of the current detection rule node to be removed rises above the apoptosis threshold during the confirmation period, the current detection rule node to be removed is removed from the set of rule nodes to be removed and restored to an active state. If the effectiveness index is still below the apoptosis threshold after the confirmation period ends, the current detection rule node to be removed is officially removed from the rule knowledge graph and a death event is generated. The death event includes the event type, the identifier of the removed detection rule node, and the death timestamp. Each disappearance event is stored as an disappearance event node in the meta-knowledge graph.

9. The method for detecting security vulnerabilities in e-commerce API interfaces based on knowledge graphs according to claim 1, characterized in that, The generation of the vulnerability detection results specifically includes: Extract all rule evolution events within the current detection period from the meta-knowledge graph, including conflict events, birth events, and death events. Each event has a unique event identifier, event type, associated detection rule node identifier, and event occurrence timestamp, forming a set of rule evolution events. Based on the rule evolution event set, all events are sorted according to timestamps. The temporal relationship between events is constructed according to the detection rule node identifiers corresponding to the events. When two events satisfy the order of occurrence, the continuous relationship of event types, or the common associated detection rule nodes, an association link between them is established. Pre-defined event association pattern templates, each of which consists of an event type sequence, event occurrence order requirements, and inter-event association links; Based on the temporal correlation and the correlation link between events, structural matching is performed with each event correlation pattern template. The arrangement of event types, the order of the correlation link between events, and the connection relationship between events are compared to obtain the pattern matching result corresponding to each event correlation pattern template. The matched event combinations and the correlation links between events are recorded. Based on the pattern matching results, participation statistics are performed on all detection rule nodes. The number of times each detection rule node appears in different event relationship chains, the types of events involved, and the order of their positions in event combinations are recorded. The pattern participation attribute set of each detection rule node is formed through statistics. The pattern-participating attribute set is classified according to event type. Events belonging to the positive evolution of rules are used to generate maturity threshold adjustment information, and events belonging to the decay trend of rules are used to generate apoptosis threshold adjustment information. By merging the adjustment information, updated maturity thresholds and apoptosis thresholds are formed. For each conflict event in the event set, the detection rule node group associated with the conflict event is extracted. The number of times the conflict occurs, the location of the conflict, and the evolution trajectory after the conflict are analyzed in the event chain of the detection rule node group. The conflict resolution method update content is formed, including the reset of the conflict rule priority, the correction of the conflict triggering conditions, and the update of the conflict association chain attributes. The updated maturity threshold, apoptosis threshold, and conflict resolution method are uniformly written into the rule knowledge graph. In subsequent detection cycles, the complete business context subgraph generated by real-time API call requests is input into the updated rule knowledge graph, and the final vulnerability detection result is output based on the latest attributes and associated links of the rule nodes.

Images