Software supply chain security detection method and device, storage medium and electronic equipment

Abstract

The invention discloses a security detection method and device for a software supply chain, a storage medium and electronic equipment, and the method comprises the steps: operating target test software on the software supply chain, collecting the operation behavior data of the target test software, determining a target behavior baseline rule for the target test software, and determining the target behavior baseline rule according to the target behavior baseline rule; and performing operation behavior detection processing on the operation behavior data by adopting a target behavior baseline rule to obtain a behavior detection result, and if the behavior detection result is an abnormal behavior type, performing security risk response processing on the target test software.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a software supply chain security detection method, device, storage medium and electronic device. Background Art

[0002] In today's digital age, as software becomes the core of organizational operations, the security of the software supply chain has become a critical issue. The software supply chain, which involves the entire process from code development to final software delivery, has become a new target for attackers. Security vulnerabilities, malicious code injection, third-party dependency risks, and internal threats not only threaten the data security of software, but are also likely to cause serious economic losses and reputation damage. There are multiple potential risk points throughout the software development, distribution, and maintenance process, which provide attackers with multiple ways to invade. Summary of the invention

[0003] This specification provides a software supply chain security detection method, device, storage medium and electronic device. The technical solution is as follows:

[0004] In a first aspect, this specification provides a software supply chain security detection method, the method comprising:

[0005] Running the target test software on the software supply chain and collecting the running behavior data of the target test software;

[0006] A target behavior baseline rule for the target test software is determined, and the target behavior baseline rule is used to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result.

[0007] If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software.

[0008] In a second aspect, this specification provides a software supply chain security detection device, the device comprising:

[0009] A data collection module is used to run the target test software on the software supply chain and collect the operation behavior data of the target test software;

[0010] The behavior detection module is used to determine the target behavior baseline rule for the target test software, and use the target behavior baseline rule to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result.

[0011] The risk response module is used to perform security risk response processing on the target test software if the behavior detection result is an abnormal behavior type.

[0012] In a third aspect, the present specification provides a computer storage medium, wherein the computer storage medium stores at least one instruction, wherein the instruction is suitable for being loaded by a processor and executing the method steps of one or more embodiments of the present specification.

[0013] In a fourth aspect, the present specification provides a computer program product, wherein the computer program product stores at least one instruction, wherein the instruction is suitable for being loaded by a processor and executing the method steps of one or more embodiments of the present specification.

[0014] In a fifth aspect, the present specification provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the method steps of one or more embodiments of the present specification.

[0015] The beneficial effects brought by the technical solutions provided by some embodiments of this specification include at least:

[0016] In one or more embodiments of the present specification, an electronic device runs target test software on a software supply chain, collects running behavior data of the target test software, and uses the determined target behavior baseline rules to perform running behavior detection processing on the running behavior data to obtain a behavior detection result. If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software. The entire security detection process can be monitored and responded to in real time, and complex and hidden abnormal behavior threats can be effectively identified and responded to, thereby enhancing visibility of potential security threats and improving the accuracy of detecting malicious activities in real environments, making timely security risk response possible, thereby greatly improving the security and reliability of the entire software supply chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in this specification or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 This is a scenario diagram of a software supply chain security detection system provided in this specification;

[0019] Figure 2 It is a flowchart of a software supply chain security detection method provided in this specification;

[0020] Figure 3 It is a flowchart of another software supply chain security detection method provided in this specification;

[0021] Figure 4 It is a flowchart of a rule selection provided in this manual;

[0022] Figure 5 It is a flowchart of a report generation process provided in this manual;

[0023] Figure 6 This is a flowchart of a baseline rule configuration provided in this manual;

[0024] Figure 7 It is a structural diagram of a software supply chain security detection device provided in this specification;

[0025] Figure 8 It is a structural schematic diagram of an electronic device provided in this manual. DETAILED DESCRIPTION

[0026] The following will be combined with the drawings in this specification to clearly and completely describe the technical solutions in this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0027] In the description of this specification, it should be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise clearly specified and limited, "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. For those of ordinary skill in the art, the specific meanings of the above terms in this specification can be understood in specific circumstances. In addition, in the description of this specification, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are an "or" relationship.

[0028] In related technologies, security detection of software supply chains relies on dynamic security scanning capabilities or static security scanning capabilities, specifically:

[0029] Static Application Security Testing (SAST) tools: used to analyze source code, byte code, or application binary files without running the program to discover security vulnerabilities; Dynamic Application Security Testing (DAST) tools: detect security vulnerabilities while the application is running, simulating the behavior of external attackers.

[0030] However, static application security testing (SAST) tools have the following problems:

[0031] Unable to detect runtime vulnerabilities: SAST only analyzes static code and cannot detect security vulnerabilities that only appear when the program is running.

[0032] High false positive rate: SAST may produce a high false positive rate, requiring manual review, which increases the workload of the security team.

[0033] Limited language and framework support: Some SAST tools may not support certain programming languages ​​or frameworks.

[0034] Not suitable for complex environments: For complex software environments and interactive applications, SAST may not be able to fully reveal potential security issues.

[0035] However, dynamic application security testing (DAST) tools have the following problems:

[0036] Failure to cover the entire code base: DAST focuses primarily on the external behavior of a running application and may miss some code paths that are not executed at runtime.

[0037] Inability to detect non-runtime issues: DAST cannot identify non-runtime configuration errors and hidden vulnerabilities.

[0038] Dependence on the runtime environment: DAST requires a complete runtime environment, which may be difficult to implement for some complex applications.

[0039] Limited detection coverage: DAST may not detect certain security vulnerabilities in backend code, especially those that do not directly affect the performance of the application.

[0040] In summary, existing static and dynamic application security testing tools cannot effectively identify complex and hidden abnormal behaviors, and the security detection effect is poor.

[0041] The present specification is described in detail below with reference to specific embodiments.

[0042] See also Figure 1 , is a scenario diagram of a software supply chain security detection system provided in this specification. Figure 1 As shown, the security detection system may include at least a client cluster and a service platform 100 .

[0043] The client cluster may include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0044] Each client in the client cluster may be an electronic device with communication function, including but not limited to: wearable device, handheld device, personal computer, tablet computer, vehicle-mounted device, smart phone, computing device or other processing device connected to a wireless modem, etc. Electronic devices may be called different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), electronic device in 5G network or future evolution network, etc.

[0045] The service platform 100 can be a separate server device, such as a rack-mounted, blade, tower, or cabinet-mounted server device, or a workstation, mainframe computer, or other hardware device with strong computing power; it can also be a server cluster composed of multiple servers, and the servers in the service cluster can be composed in a symmetrical manner, wherein each server has equivalent functions and status in the transaction link, and each server can provide services to the outside independently, and the independent service can be understood as not requiring the assistance of other servers.

[0046] In one or more embodiments of the present specification, the service platform 100 may establish a communication connection with at least one client in the client cluster, and complete data interaction in the software supply chain process based on the communication connection, such as the interaction of running behavior data of the target test software. For example, the service platform 100 may implement security testing of the target test software published by the client on the software supply chain based on the software supply chain security testing method of the present specification.

[0047] It should be noted that the service platform 100 and at least one client in the client cluster establish a communication connection through a network for interactive communication, wherein the network can be a wireless network or a wired network, the wireless network includes but is not limited to a cellular network, a wireless local area network, an infrared network or a Bluetooth network, and the wired network includes but is not limited to Ethernet, a universal serial bus (USB) or a controller local area network. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Mark-up Language (HTML), Extensible Markup Language (XML), etc. are used to represent data (such as a target compressed package) exchanged through a network. In addition, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec), etc. can also be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can also be used to replace or supplement the above data communication technologies.

[0048] The software supply chain system embodiments provided in this specification and the software supply chain security detection method in one or more embodiments belong to the same concept. The execution subject corresponding to the software supply chain security detection method in one or more embodiments of the specification can be an electronic device, and the electronic device can be the above-mentioned service platform 100; the execution subject electronic device corresponding to the software supply chain security detection method in one or more embodiments of the specification can also be a client, which is determined based on the actual application environment. The implementation process of the software supply chain system embodiment can be detailed in the following method embodiment, which will not be repeated here.

[0049] based on Figure 1 The scenario diagram is shown, and the software supply chain security detection method provided by one or more embodiments of this specification is introduced in detail below.

[0050] See also Figure 2 , a flowchart of a software supply chain security detection method for one or more embodiments of this specification is provided, which can be implemented by a computer program and can be run on a software supply chain security detection device based on the von Neumann system. The computer program can be integrated into an application or run as an independent tool application. The software supply chain security detection device can be an electronic device.

[0051] Specifically, the security detection methods of the software supply chain include:

[0052] S102: running the target test software in the software supply chain, and collecting the running behavior data of the target test software;

[0053] The software supply chain refers to the entire process and each link involved in software development, distribution and maintenance, including from the initial demand analysis, design, coding, to software construction, testing, deployment, and final update and maintenance. In this software supply chain, each step may involve different suppliers, developers, tools and technologies, so security testing is very important for testing software in the software supply chain;

[0054] Specifically, the environment can be set up for the current target test software in the software supply chain, and then the target test software in the software supply chain can be run to collect the running behavior data of the target test software.

[0055] Schematically, the test environment and monitoring tools are configured during the environment setup process. Test environment: Configure a secure test environment to ensure that it is as similar as possible to the actual software deployment environment. For example, you can configure an isolated sandbox environment to prevent potential malicious behaviors from affecting the actual system. Monitoring tool configuration: Deploy various monitoring tools and agents to capture the runtime behavior data of the target test software. Monitoring tools include but are not limited to network monitoring tools, system call tracers, file access monitoring, etc.

[0056] Schematically, data collection mainly involves collecting operational behavior data such as network activities, system calls, file operations, and behavior logs;

[0057] Network activity: Monitor all network requests and responses of the target test software, record the source and destination of the data packet, protocol type, port usage, etc. Tools for collecting network activities include Wireshark or tcpdump. System calls: Record all system call data of the target test software, including file operations, registry access, process start / termination, etc. File operations: Monitor access to the file system, record all read and write operations, file creation and deletion activities. This can help identify possible modifications or data theft behaviors that malware may perform. Behavior logs: Collect system and application logs related to the target test software. These behavior logs may contain error reports, warnings, and other system messages, which are helpful for subsequent analysis of software behavior.

[0058] S104: Determine a target behavior baseline rule for the target test software, and use the target behavior baseline rule to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result.

[0059] Specifically, multiple behavior baseline rules are formulated in advance, and all behavior baseline rules can form a general baseline rule set. The behavior baseline rules can be normal behavior baseline rules formulated for normal behavior types and abnormal behavior baseline rules formulated for abnormal behavior types;

[0060] Anomaly detection: Based on the collected operation behavior data and the target behavior baseline rules, operation behavior detection is performed to identify any abnormal or suspicious behavior. For example, it involves matching with known malicious behavior indicators in the target behavior baseline rules (such as a list of known malicious domain names, abnormal system call sequences).

[0061] Behavior detection results include positive behavior types and abnormal behavior types;

[0062] In a feasible implementation, all preset baseline rules may be obtained from the general baseline rule set, and all preset baseline rules may be determined as target behavior baseline rules for the target test software;

[0063] In other embodiments of the present specification, target behavior baseline rules can be dynamically selected from a general baseline rule set, key operating characteristics of the target software under test can be extracted based on the operating behavior data, software context information of the target software can be obtained, and target behavior baseline rules can be selected from a general baseline rule set based on the key operating characteristics of the target software and the software context information.

[0064] Furthermore, since the target behavior baseline rule can be a normal behavior baseline (rule) or an anomaly detection rule;

[0065] Optionally, a normal behavior baseline is determined based on a target behavior baseline rule, and the running behavior data is matched with the normal behavior baseline to obtain a first behavior detection result;

[0066] Optionally, an anomaly detection rule is determined based on the target behavior baseline rule, and the operation behavior data is matched with the anomaly detection rule for abnormal behavior to obtain a second behavior detection result;

[0067] Further, based on the first behavior detection result and / or the second behavior detection result, a behavior detection result is generated.

[0068] For example, the electronic device will compare the behavior data collected in real time with the baseline rules. If it is found whether the behavior pattern corresponding to the running behavior data matches the target behavior baseline rule, if the target behavior baseline rule is a normal behavior baseline and the result matches, the behavior detection result is determined to be normal in combination with the baseline rule type. On the contrary, if the target behavior baseline rule is a normal behavior baseline and the result does not match, the behavior detection result is determined to be abnormal in combination with the baseline rule type. If the target behavior baseline rule is an abnormal behavior baseline and the result matches, the behavior detection result is determined to be abnormal in combination with the baseline rule type. On the contrary, if the target behavior baseline rule is an abnormal behavior baseline and the result does not match, the behavior detection result is determined to be normal in combination with the baseline rule type. When the abnormal behavior type is determined, the abnormal behavior type corresponding to the baseline rule that detects the abnormality is determined, such as malicious code injection, abnormal network activity, illegal file operation, etc. At the same time, the baseline matching process data can be exported to generate behavior detection result data, including the detected abnormal behavior type, the time of occurrence, related behavior data, impact assessment and other information.

[0069] S106: If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software.

[0070] Exemplarily, if the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software, which may be to trigger an alarm mechanism (when abnormal behavior is detected, an alarm is automatically generated and the security team is notified); it may be to trigger the generation of a detailed report (such as providing a detailed abnormal behavior report, including the time of occurrence, the system components involved, possible impacts, etc.); it may be to initiate response measures.

[0071] Optionally, the response measures can be isolation and repair, remediation measures, etc. Isolation and repair: If the abnormal behavior is confirmed to be a security risk, first take isolation measures to prevent the abnormal behavior from further expansion. Then take corresponding repair measures according to the specific risk type, such as patching vulnerabilities, updating software versions, etc. Remediation: Perform remediation measures to repair the detected security issues. For example, undo malicious changes, restore damaged data, reconfigure system settings, etc.

[0072] In a feasible implementation, the following method may be adopted:

[0073] A2: Generate an abnormality alert for the target test software;

[0074] A4: Generate an abnormal behavior report for the target test software based on the behavior detection result, and send the abnormal behavior report and the abnormal alarm to the security maintenance end.

[0075] Optionally, triggering the generation of abnormal behavior reports may include security reports and record archiving. Security reports: Generate detailed security incident reports that describe the abnormal behavior detection process, response measures taken, and final repair results. Record archiving: All abnormal behavior event records are archived for reference by the security maintenance end, including detection results, response measures, remedial actions, and other information.

[0076] In one or more embodiments of the present specification, an electronic device runs target test software on a software supply chain, collects running behavior data of the target test software, and uses the determined target behavior baseline rules to perform running behavior detection processing on the running behavior data to obtain a behavior detection result. If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software. The entire security detection process can be monitored and responded to in real time, and complex and hidden abnormal behavior threats can be effectively identified and responded to, thereby enhancing visibility of potential security threats and improving the accuracy of detecting malicious activities in real environments, making timely security risk response possible, thereby greatly improving the security and reliability of the entire software supply chain.

[0077] See also Figure 3 , Figure 3 This is a flowchart of another embodiment of a software supply chain security detection method proposed in one or more embodiments of this specification. Specifically:

[0078] S202: running the target test software in the software supply chain, and collecting the running behavior data of the target test software;

[0079] For details, please refer to the method steps in other embodiments of this specification, which will not be repeated here.

[0080] S204: extracting key operating features of the target software of the target test software based on the operating behavior data, and acquiring software context information of the target software;

[0081] Environment and context awareness: Ability to conduct more accurate risk assessment based on the specific operating environment and context.

[0082] Considering that, if there are already many rules in the general baseline rule set, it is possible to dynamically and effectively select target baseline rules applicable to specific test software from the general baseline rule set based on key operating characteristics of the target software and software context information of the target software.

[0083] Schematically, key operating characteristics of the target software are extracted from the operating behavior data of the target test software. The key operating characteristics of the target software are operating characteristic data corresponding to pre-specified characteristic types, such as network access mode, resource usage, user interaction behavior, etc.

[0084] Rule characterization: Characterize each rule in the common baseline library, marking the behavior type, environment, or other relevant characteristics to which they are most applicable.

[0085] Context-aware selection is used to extract software context information, which may include software operating environment, software purpose and type, software meta-information, operating system version, network configuration, user permissions, running time, system resource usage, etc. Software context information can be collected through system monitoring tools, configuration files, and environment variables.

[0086] Consider the purpose and type of software: According to the type of test software (such as financial, medical, educational software, etc.) and purpose, you can then comprehensively select relevant baseline rules. Different types of software may face different security threats and behavior patterns.

[0087] S206: Selecting a target behavior baseline rule from a general baseline rule set based on the target software key operation characteristics and the software context information.

[0088] A scoring mechanism can be established in advance, and a scoring algorithm can be developed to evaluate the correlation between the "key operating characteristics of the target software and software context information" of the target test software and each baseline rule to obtain a correlation parameter. The evaluation process can be based on the historical effect of the rule application of the "key operating characteristics of the target software and software context information", feature similarity and other factors to comprehensively calculate a correlation parameter.

[0089] Rule selection: Based on the relevance parameter, the baseline rule with the highest relevance parameter is selected as the target baseline rule. For example, you can set a threshold and select only those rules whose scores exceed this threshold.

[0090] Furthermore, the baseline rules are monitored and adjusted dynamically based on data in real time. Dynamic feedback adjustment: During the software operation, the selected rules are dynamically adjusted based on real-time monitoring data. If it is found that some rules are no longer applicable or cause a high false alarm rate, they are adjusted or replaced in a timely manner.

[0091] Through the above method, it is possible to ensure that the target baseline rules that are most suitable for the current test software are dynamically and accurately selected from a wide range of general baseline rules, effectively improving the efficiency and accuracy of security monitoring.

[0092] See also Figure 4 , Figure 4 The present invention is a flowchart of rule selection, and the following method can be used to select the target behavior baseline rule from the general baseline rule set based on the key operation characteristics of the target software and the software context information:

[0093] S3002: inputting the target software key operation characteristics and the software context information into a rule evaluation model, performing a relevance evaluation on each preset baseline rule in the general baseline rule set through the rule evaluation model, and outputting a relevance parameter for the preset baseline rule;

[0094] Optionally, the relevance parameter may be a relevance score, a relevance rating, etc.;

[0095] In an optional implementation, a rule evaluation model can be pre-trained based on a machine learning model and deployed. The model input of the rule evaluation model is "key operating characteristics of the target software and the software context information", and the model output of the rule evaluation model is "correlation parameters for the preset baseline rules". The model processing process of the rule evaluation model is to call a general baseline rule set, and based on the "key operating characteristics of the target software and the software context information", each preset baseline rule in the general baseline rule set is taken one by one to perform correlation evaluation with the target test software, and the correlation parameters for each preset baseline rule are output;

[0096] The following is an explanation of the model training process of the rule evaluation model:

[0097] Model creation: Create an initial rule evaluation model for the baseline rule evaluation scenario based on the machine learning model, and combine the initial rule evaluation model with the general baseline rule set;

[0098] It should be noted that the baseline rules in the general baseline rule set can be adjusted dynamically;

[0099] Sample data acquisition: A large amount of sample data is acquired. The sample data is "sample software key operation characteristics and sample software context information" extracted from the software operation data of the platform-based test software. The sample data includes "sample software key operation characteristics and sample software context information".

[0100] Sample data labeling: Based on the needs of the baseline rule evaluation scenario, an expert service is introduced to manually label the sample data with corresponding sample labels. The sample labels (also called output result labels) include reference correlation parameters for each preset baseline rule in the general baseline rule set.

[0101] Model training process: input sample data into the initial rule evaluation model for at least one round of model training to obtain a predicted output result, wherein the predicted output result includes a predicted correlation parameter for each preset baseline rule in the general baseline rule set, and a model loss function is used to determine the model loss value based on the predicted feature data (such as predicted correlation parameter) and the output result label (reference correlation parameter). Based on the model loss value, the model parameters of the initial rule evaluation model are adjusted until the model training end conditions are met to obtain the rule evaluation model.

[0102] Optionally, the model training end condition of the model may include, for example, the value of the loss function is less than or equal to a preset loss function threshold, the number of iterations reaches a preset number threshold, etc. The specific model training end condition can be determined based on actual conditions and is not specifically limited here.

[0103] It should be noted that the machine learning models involved in one or more embodiments of this specification include but are not limited to the fitting of one or more machine learning models such as convolutional neural network (CNN) model, deep neural network (DNN) model, recurrent neural network (RNN) model, embedding model, gradient boosting decision tree (GBDT) model, logistic regression (LR) model, etc.;

[0104] Optionally, the model loss function may be a hinge loss function, a cross entropy loss function, a vector distance loss function, a contrast loss function, etc.

[0105] S3004: Selecting a target behavior baseline rule whose correlation parameter is greater than a target threshold from the general baseline rule set.

[0106] S208: Performing operation behavior detection processing on the operation behavior data using the target behavior baseline rule to obtain a behavior detection result.

[0107] For details, please refer to the method steps in other embodiments of this specification, which will not be repeated here.

[0108] S210: If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software.

[0109] For details, please refer to the method steps in other embodiments of this specification, which will not be repeated here.

[0110] In one or more embodiments of the present specification, the aforementioned method can be used to dynamically and effectively select target baseline rules applicable to specific test software from key software operating characteristics and software context information, ensuring that the target baseline rules most suitable for the current test software are dynamically and accurately selected from a wide range of general baseline rules. Abnormal behaviors will be marked as potential security risks, which can effectively improve the efficiency and accuracy of security monitoring.

[0111] See also Figure 5 , Figure 5 It is a flow chart of report generation, which is executed on the behavior detection result to generate an abnormal behavior report for the target test software, which can be implemented in the following ways:

[0112] S4002: Acquire software context information and software-related behavior events of the target test software;

[0113] During the operation of the target test software, software-related behavior events can be recorded. Software-related behavior events refer to other events related to the test software, such as error information in the system log, user operation records, and interaction records with other systems or software. Software-related behavior events are introduced to assist in analyzing these related events to obtain more abnormal safety information and help understand the background and potential causes of abnormal behavior.

[0114] S4004: Based on the software context information, the behavior detection results and the software-related behavior events, a behavior analysis prompt word is used to control the target large language model to perform abnormal behavior analysis processing, and an abnormal behavior report for the target test software is output.

[0115] Behavior analysis prompt words: Pre-create behavior analysis prompt words for the large language model, integrating the software's context information, behavior detection results, and related events. Behavior analysis prompt words are used to guide the target large language model to perform detailed analysis of abnormal behaviors.

[0116] In this specification, a target large language model is pre-trained, and the target large language model is obtained by performing migration training on the basic large language model based on the abnormal behavior analysis scenario. The basic large language model can be quickly applied to a new abnormal behavior analysis scenario without retraining a new model. Only fine-tuning training of the basic large language model is required. Usually, the basic large language model is adapted to the text character understanding processing scenario and cannot be directly adapted to the abnormal behavior analysis scenario. Based on this, with the help of samples in the new scenario, the basic large language model (which can be called the LLM model) can be migrated and converted into a target large language model that is compatible with the abnormal behavior analysis processing scenario. The target large language model can generate abnormal behavior reports;

[0117] The basic large language model may be, for example, a ChatGPT model, a Wenxinyiyan model, an LLM model, etc. The type of the basic large language model is not limited in this specification.

[0118] The software context information, behavior detection results and software-related behavior events are input into the target large language model, and the target large language model is used to parse and process abnormal behaviors using behavior analysis prompts. The target large language model can understand the context and generate a detailed analysis and explanation of the abnormal behavior, and finally output an abnormal behavior report. The report content may include a detailed description of the abnormal behavior, possible root cause analysis, potential security risk assessment and recommended remediation measures. The abnormal behavior report can provide the security team with in-depth analysis results to help them formulate targeted security strategies, fix security vulnerabilities in the software, and optimize future security detection systems.

[0119] The following is an explanation of the model training process of the target large language model:

[0120] Model creation: The electronic device first obtains a basic large language model, and then creates an initial target large language model in an abnormal behavior analysis scenario, which includes at least an abnormal behavior analysis scenario adaptation module and a large language generation module.

[0121] Sample data acquisition: Acquire sample training data; sample training data is determined based on the tasks in the training phase. Sample training data includes sample software context information of sample test applications, sample behavior detection results, and sample software-related behavior events. Then, call the expert-side service to annotate the sample training data with abnormal behavior report labels.

[0122] Model training process: input sample data into the initial target large language model for at least one round of model training to obtain a predicted abnormal behavior report, and use the model loss function to determine the model loss value based on the predicted abnormal behavior report and the abnormal behavior report label. Based on the model loss value, adjust the model parameters of the initial abnormal behavior analysis scenario adaptation module, and control the model parameters of the large language generation module unchanged until the initial target large language model meets the model training end conditions to obtain the target large language model.

[0123] Optionally, the model training end condition of the model may include, for example, the value of the loss function is less than or equal to a preset loss function threshold, the number of iterations reaches a preset number threshold, etc. The specific model training end condition can be determined based on actual conditions and is not specifically limited here.

[0124] In one or more embodiments of this specification, complex behavior detection results and software context information can be effectively combined to generate detailed abnormal behavior reports using the powerful analysis capabilities of large language models. This helps to more accurately identify and understand complex abnormal behaviors, provide specific suggestions and improvement measures, and thus enhance the overall security of the software.

[0125] See also Figure 6 , Figure 6 This is a flowchart of a baseline rule configuration proposed in one or more embodiments of this specification. The following is an explanation of the baseline rule configuration method, specifically:

[0126] S5002: Collecting reference running behavior data of multiple reference test software, and marking the software running behavior type for the reference running behavior data;

[0127] Exemplarily, multiple reference test software in similar environments are pre-selected. These reference test software may be test software with different functions or operation types. These reference test software are run in the same configuration environment to ensure that the behavior data of the multiple reference test software have reference value.

[0128] Furthermore, reference operating behavior data of multiple reference test software are collected through data recording tools (such as system monitoring tools, network analysis tools, log recording tools, etc.), such as network traffic, system calls, file operations, process activities, etc.

[0129] Software operation behavior types may include "connecting to malicious domain names or IP addresses", "intranet scanning", "local disk scanning", "modifying system configuration", "abnormal network traffic", "unauthorized file operations", "unusual system calls or process behaviors", "exploiting known vulnerabilities", "unauthorized service installation or startup", "disguising or imitating normal behaviors", and so on.

[0130] The reference running behavior data is labeled with the software running behavior type, specifically, a label is assigned to each collected reference running behavior data, which can be manually labeled or automatically labeled.

[0131] Manual labeling: Experts or security teams manually label the data to ensure the accuracy of the labels.

[0132] Automated annotation: Use automated tools or algorithms to perform preliminary annotations on the reference operating behavior data, which are then corrected through manual review.

[0133] S5004: Obtain basic operation behavior data of the same type of software operation behavior type, and perform baseline configuration processing on the software operation behavior type based on the basic operation behavior data to obtain preset behavior baseline rules.

[0134] Through the above steps, the reference operation behavior data is classified into types, and all basic operation behavior data under the same software operation behavior type are obtained. These basic operation behavior data should represent a type of operation behavior of the same type of software, and the corresponding software operation behavior type is baseline configured based on the basic operation behavior data;

[0135] Optionally, baseline rules are generated. Specifically, the baseline configuration can be based on the basic operating behavior data to configure preset baseline rules for each behavior type. These preset baseline rules will define the normal range or threshold for each behavior. Rule setting: set rule parameters, such as the normal range of network traffic, frequency limit of system calls, etc.

[0136] Furthermore, after the baseline configuration is completed, rule verification can also be performed. Rule testing: verify the behavior of the test software by applying the generated baseline rules to ensure the accuracy and effectiveness of the rules. Rule optimization: adjust and optimize the baseline rules according to the test results to improve the accuracy and reliability of detection.

[0137] For example, the following are some common malware supply chain behaviors and a possible preset baseline rule for them:

[0138] 1. Connecting to malicious domains or IP addresses

[0139] Behavior content: The software attempts to establish communication with known malicious domain names or IP addresses, which may be used for data leakage or receiving instructions from attackers.

[0140] Preset baseline rules: Maintain a list of malicious domain names and IP addresses and monitor the software's network requests to match this list. Use network monitoring tools, such as IDS / IPS, to detect these communication attempts.

[0141] 2. Intranet scanning

[0142] Behavior: The software searches for other devices and services on the internal network, possibly looking for further targets for infection.

[0143] Preset baseline rules: Monitor and record network scanning activities, such as large numbers of port scan requests. Set up network monitoring tools to detect unusual intranet traffic patterns.

[0144] 3. Local disk scan

[0145] Behavior content: The software scans the local disk to look for sensitive information or available resources.

[0146] Preset Baseline Rules: Use file integrity monitoring tools to track access and changes to sensitive directories and files. Detect unusual file read patterns.

[0147] 4. Modify system configuration

[0148] Behavior: Software changes system settings or configurations, possibly for persistence or to bypass security controls.

[0149] Preset Baseline Rules: Monitor changes to critical system files and registry keys. Use tools such as Sysmon to log system-level change activity.

[0150] 5. Abnormal network traffic

[0151] Behavior content: The software generates unusually large or small amounts of network traffic, which may involve data leakage or secret communications.

[0152] Preset Baseline Rules: Set baseline network traffic levels and use network monitoring tools to detect significant deviations from the baseline.

[0153] 6. Unauthorized file operations

[0154] Behavior content: The software performs unauthorized file operations, such as deleting, encrypting, or modifying important files.

[0155] Preset baseline rules: Monitor access and changes to sensitive files. Use file activity monitoring tools to track unusual file operation behaviors.

[0156] 7. Unusual system calls or process behavior

[0157] Behavior content: The software performs unusual system calls or process behaviors that may indicate unauthorized operations or attempts to gain higher privileges.

[0158] Preset Baseline Rules: Monitor system calls and process activities, and use behavioral analysis tools to identify deviations from normal behavior patterns.

[0159] 8. Exploiting known vulnerabilities

[0160] Behavior content: The software attempts to exploit a known vulnerability, possibly to escalate privileges or execute malicious code.

[0161] Preset Baseline Rules: Deploy vulnerability scanning tools to scan systems and applications regularly. Monitor system logs to detect unusual activities that may indicate attempts to exploit vulnerabilities.

[0162] 9. Unauthorized service installation or startup

[0163] Behavior: Software installation or activation of unauthorized services, possibly to establish a backdoor.

[0164] Preset Baseline Rules: Monitor the installation and startup of new services. Use system monitoring tools to check all newly installed programs and services.

[0165] 10. Pretending or imitating normal behavior

[0166] Behavioral content: Software disguises itself as normal behavior to hide its malicious activity.

[0167] Preset baseline rules: Use behavior-based detection techniques, such as machine learning algorithms, to identify pattern deviations and masquerade techniques.

[0168] In a feasible implementation manner, after the target test software is subjected to security risk response processing, the following method may also be adopted:

[0169] B2: determining an abnormal risk level for the target test software based on the abnormal behavior report, and configuring a target simulation running environment for the target test software based on the abnormal risk level;

[0170] B4: running the target test software in the target simulation running environment, recording the simulation behavior running results and simulation behavior running data of the target test software, and forming a simulation behavior verification set including the simulation behavior running results and the simulation behavior running data for the target behavior baseline rule;

[0171] B6: Adjusting the target behavior baseline rule based on the multiple simulation behavior verification sets.

[0172] In one or more embodiments of the present specification, by systematically collecting and analyzing the behavioral data of multiple reference test software, marking the behavior types, and then generating preset behavioral baseline rules based on the data of similar software, it is possible to provide an accurate baseline configuration for the target test software to be tested subsequently, so as to effectively detect and respond to abnormal behavior and improve the security and stability of the software supply chain.

[0173] The following will be combined Figure 7 , the software supply chain security detection device provided in this specification is introduced in detail. It should be noted that Figure 7 The software supply chain security detection device shown is used to implement this specification Figure 1 to Figure 6 For the convenience of explanation, only the parts related to this specification are shown. For the specific technical details not disclosed, please refer to this specification. Figure 1 to Figure 6 The embodiment shown.

[0174] See also Figure 7, which shows a schematic diagram of the structure of the software supply chain security detection device of this specification. The software supply chain security detection device 1 can be implemented as all or part of the device through software, hardware or a combination of both. According to some embodiments, the software supply chain security detection device 1 includes a data acquisition module 11, a behavior detection module 12 and a risk response module 13, which are specifically used to:

[0175] The data collection module 11 is used to run the target test software in the software supply chain and collect the operation behavior data of the target test software;

[0176] The behavior detection module 12 is used to determine a target behavior baseline rule for the target test software, and perform operation behavior detection processing on the operation behavior data using the target behavior baseline rule to obtain a behavior detection result.

[0177] The risk response module 13 is used to perform security risk response processing on the target test software if the behavior detection result is an abnormal behavior type.

[0178] Optionally, the behavior detection module 12 is used to:

[0179] Acquire all preset baseline rules from the general baseline rule set, and determine all the preset baseline rules as target behavior baseline rules for the target test software; and / or,

[0180] The target software key operation characteristics of the target test software are extracted based on the operation behavior data, the software context information of the target software is obtained, and the target behavior baseline rules are selected from the general baseline rule set based on the target software key operation characteristics and the software context information.

[0181] Optionally, the behavior detection module 12 is used to:

[0182] Inputting the target software key operation characteristics and the software context information into a rule evaluation model, performing relevance evaluation on each preset baseline rule in the general baseline rule set through the rule evaluation model, and outputting relevance parameters for the preset baseline rules;

[0183] A target behavior baseline rule whose correlation parameter is greater than a target threshold is selected from the general baseline rule set.

[0184] Optionally, the data acquisition module 11 is used to:

[0185] Determine a normal behavior baseline based on the target behavior baseline rule, perform normal behavior matching on the operating behavior data and the normal behavior baseline, and obtain a first behavior detection result; and / or determine an abnormal detection rule based on the target behavior baseline rule, perform abnormal behavior matching on the operating behavior data and the abnormal detection rule, and obtain a second behavior detection result;

[0186] A behavior detection result is generated based on the first behavior detection result and / or the second behavior detection result.

[0187] Optionally, the risk response module 13 is used to:

[0188] generating an anomaly alert for the target test software;

[0189] An abnormal behavior report for the target test software is generated based on the behavior detection result, and the abnormal behavior report and the abnormal alarm are sent to a security maintenance terminal.

[0190] Optionally, the risk response module 13 is used to:

[0191] Acquire software context information and software-related behavior events of the target test software;

[0192] Based on the software context information, the behavior detection results and the software-related behavior events, a behavior analysis prompt word is used to control the target large language model to perform abnormal behavior analysis processing, and an abnormal behavior report for the target test software is output.

[0193] Optionally, the device 1 is also used for:

[0194] Collecting reference running behavior data of multiple reference test software, and marking the software running behavior type on the reference running behavior data;

[0195] The basic operation behavior data of the same type of software operation behavior is obtained, and the baseline configuration processing of the software operation behavior type is performed based on the basic operation behavior data to obtain a preset behavior baseline rule.

[0196] It should be noted that the software supply chain security detection device provided in the above embodiment only uses the division of the above functional modules as an example when executing the software supply chain security detection method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the software supply chain security detection device provided in the above embodiment and the software supply chain security detection method embodiment belong to the same concept, and the implementation process thereof is detailed in the method embodiment, which will not be repeated here.

[0197] The above serial numbers in this specification are for description only and do not represent the advantages or disadvantages of the embodiments.

[0198] In one or more embodiments of the present specification, an electronic device runs target test software on a software supply chain, collects running behavior data of the target test software, and uses the determined target behavior baseline rules to perform running behavior detection processing on the running behavior data to obtain a behavior detection result. If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software. The entire security detection process can be monitored and responded to in real time, and can effectively identify and respond to complex and hidden abnormal behavior threats, thereby enhancing visibility of potential security threats and improving the accuracy of detecting malicious activities in real environments, making timely security risk response possible, thereby greatly improving the security and reliability of the entire software supply chain.

[0199] The present specification also provides a computer storage medium, which can store multiple instructions, which are suitable for being loaded and executed by a processor as described above. Figure 1 to Figure 6 The software supply chain security detection method of the embodiment shown in the figure can be found in the specific execution process. Figure 1 to Figure 6 The specific description of the illustrated embodiment will not be repeated here.

[0200] The present specification also provides a computer program product, which stores at least one instruction, and the at least one instruction is loaded and executed by the processor as described above. Figure 1 to Figure 6 The software supply chain security detection method of the embodiment shown in the figure can be found in the specific execution process. Figure 1 to Figure 6 The specific description of the illustrated embodiment will not be repeated here.

[0201] Please refer to Figure 8 , is a block diagram of a structure of an electronic device provided in an embodiment of this specification. The electronic device in this specification may include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, the memory 1020, the input device 1030, and the output device 1040 may be connected via a bus 1050.

[0202] The processor 1010 may include one or more processing cores. The processor 1010 uses various interfaces and lines to connect various parts of the entire terminal, and executes various functions and processes data of the terminal 100 by running or executing instructions, programs, code sets or instruction sets stored in the memory 1020, and calling data stored in the memory 1020. Optionally, the processor 1010 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 1010 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 1010, but may be implemented separately through a communication chip.

[0203] The memory 1020 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 1020 includes a non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, codes, code sets, or instruction sets.

[0204] The input device 1030 is used to receive input instructions or data, and the input device 1030 includes but is not limited to a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 1040 is used to output instructions or data, and the output device 1040 includes but is not limited to a display device and a speaker. In the embodiment of this specification, the input device 1030 can be a temperature sensor for obtaining the operating temperature of the terminal. The output device 1040 can be a speaker for outputting audio signals.

[0205] In addition, those skilled in the art will appreciate that the structure of the terminal shown in the above drawings does not constitute a limitation on the terminal, and the terminal may include more or fewer components than shown, or combine certain components, or arrange the components differently. For example, the terminal also includes a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (WIFI) module, a power supply, a Bluetooth module, and other components, which will not be described in detail here.

[0206] In the embodiments of this specification, the execution subject of each step may be the terminal described above. Optionally, the execution subject of each step is the operating system of the terminal. The operating system may be an Android system, an IOS system, or other operating systems, which is not limited in the embodiments of this specification.

[0207] exist Figure 8 In the electronic device, the processor 1010 can be used to call the program stored in the memory 1020 and execute it to implement the software supply chain security detection method as described in the various method embodiments of this specification, specifically:

[0208] Running the target test software on the software supply chain and collecting the running behavior data of the target test software;

[0209] A target behavior baseline rule for the target test software is determined, and the target behavior baseline rule is used to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result.

[0210] If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software.

[0211] In a feasible implementation manner, the processor 1010 performs the step of determining the target behavior baseline rule for the target test software by performing the following steps:

[0212] Acquire all preset baseline rules from the general baseline rule set, and determine all the preset baseline rules as target behavior baseline rules for the target test software; and / or,

[0213] The target software key operation characteristics of the target test software are extracted based on the operation behavior data, the software context information of the target software is obtained, and the target behavior baseline rules are selected from the general baseline rule set based on the target software key operation characteristics and the software context information.

[0214] In a feasible implementation manner, the processor 1010 executes the step of selecting a target behavior baseline rule from a general baseline rule set based on the target software key operation characteristics and the software context information, and performs the following steps:

[0215] Inputting the target software key operation characteristics and the software context information into a rule evaluation model, performing relevance evaluation on each preset baseline rule in the general baseline rule set through the rule evaluation model, and outputting relevance parameters for the preset baseline rules;

[0216] A target behavior baseline rule whose correlation parameter is greater than a target threshold is selected from the general baseline rule set.

[0217] In a feasible implementation manner, the processor 1010 performs the operation behavior detection processing on the operation behavior data using the target behavior baseline rule to obtain a behavior detection result, and performs the following steps:

[0218] Determine a normal behavior baseline based on the target behavior baseline rule, perform normal behavior matching on the operating behavior data and the normal behavior baseline, and obtain a first behavior detection result; and / or determine an abnormal detection rule based on the target behavior baseline rule, perform abnormal behavior matching on the operating behavior data and the abnormal detection rule, and obtain a second behavior detection result;

[0219] A behavior detection result is generated based on the first behavior detection result and / or the second behavior detection result.

[0220] In a feasible implementation manner, the processor 1010 performs the security risk response processing on the target test software by performing the following steps:

[0221] generating an anomaly alert for the target test software;

[0222] An abnormal behavior report for the target test software is generated based on the behavior detection result, and the abnormal behavior report and the abnormal alarm are sent to a security maintenance terminal.

[0223] In a feasible implementation manner, the processor 1010 executes the step of generating an abnormal behavior report for the target test software based on the behavior detection result, and performs the following steps:

[0224] Acquire software context information and software-related behavior events of the target test software;

[0225] Based on the software context information, the behavior detection results and the software-related behavior events, a behavior analysis prompt word is used to control the target large language model to perform abnormal behavior analysis processing, and an abnormal behavior report for the target test software is output.

[0226] In a feasible implementation manner, the processor 1010 executes the method and further executes the following steps:

[0227] Collecting reference running behavior data of multiple reference test software, and marking the software running behavior type on the reference running behavior data;

[0228] The basic operation behavior data of the same type of software operation behavior is obtained, and the baseline configuration processing of the software operation behavior type is performed based on the basic operation behavior data to obtain a preset behavior baseline rule.

[0229] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only storage memory, or a random access memory, etc.

[0230] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions. For example, the operation behavior data involved in this specification are all obtained with full authorization.

[0231] The above disclosure is only the preferred embodiment of this specification, which certainly cannot be used to limit the scope of rights of this specification. Therefore, equivalent changes made according to the claims of this specification are still within the scope covered by this specification.

Claims

1. A software supply chain security detection method, the method comprising: Running the target test software on the software supply chain and collecting the running behavior data of the target test software; Determine a target behavior baseline rule for the target test software, and use the target behavior baseline rule to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result; If the behavior detection result is an abnormal behavior type, security risk response processing is performed on the target test software.

2. The method according to claim 1, wherein determining a target behavior baseline rule for the target test software comprises: Acquire all preset baseline rules from the general baseline rule set, and determine all the preset baseline rules as target behavior baseline rules for the target test software; and / or, The target software key operation characteristics of the target test software are extracted based on the operation behavior data, the software context information of the target software is obtained, and the target behavior baseline rules are selected from the general baseline rule set based on the target software key operation characteristics and the software context information.

3. The method according to claim 2, wherein the step of selecting a target behavior baseline rule from a set of general baseline rules based on the target software key operating characteristics and the software context information comprises: Inputting the target software key operation characteristics and the software context information into a rule evaluation model, performing a correlation evaluation on each preset baseline rule in the general baseline rule set through the rule evaluation model, and outputting a correlation parameter for the preset baseline rule; A target behavior baseline rule whose correlation parameter is greater than a target threshold is selected from the general baseline rule set.

4. According to the method of claim 1, the step of performing operation behavior detection processing on the operation behavior data using the target behavior baseline rule to obtain a behavior detection result comprises: Determine a normal behavior baseline based on a target behavior baseline rule, perform normal behavior matching on the operating behavior data and the normal behavior baseline, and obtain a first behavior detection result; and / or, determining an anomaly detection rule based on the target behavior baseline rule, performing an abnormal behavior matching between the operation behavior data and the anomaly detection rule, and obtaining a second behavior detection result; A behavior detection result is generated based on the first behavior detection result and / or the second behavior detection result.

5. The method according to claim 1, wherein the performing security risk response processing on the target test software comprises: generating an anomaly alert for the target test software; An abnormal behavior report for the target test software is generated based on the behavior detection result, and the abnormal behavior report and the abnormal alarm are sent to a security maintenance terminal.

6. The method according to claim 5, wherein generating an abnormal behavior report for the target test software based on the behavior detection result comprises: Acquire software context information and software-related behavior events of the target test software; Based on the software context information, the behavior detection results and the software-related behavior events, a behavior analysis prompt word is used to control the target large language model to perform abnormal behavior analysis processing, and an abnormal behavior report for the target test software is output.

7. The method according to claim 1, further comprising: Collecting reference running behavior data of multiple reference test software, and marking the software running behavior type on the reference running behavior data; The basic operation behavior data of the same type of software operation behavior is obtained, and the baseline configuration processing of the software operation behavior type is performed based on the basic operation behavior data to obtain a preset behavior baseline rule.

8. A software supply chain security detection device, the device comprising: A data collection module is used to run the target test software on the software supply chain and collect the operation behavior data of the target test software; A behavior detection module is used to determine a target behavior baseline rule for the target test software, and use the target behavior baseline rule to perform operation behavior detection processing on the operation behavior data to obtain a behavior detection result; The risk response module is used to perform security risk response processing on the target test software if the behavior detection result is an abnormal behavior type.

9. A computer storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 7.

10. A computer program product, the computer program product storing at least one instruction, wherein the at least one instruction is loaded by a processor and executes the method steps according to any one of claims 1 to 7.

11. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the method steps as claimed in any one of claims 1 to 7.

Images