Dynamic patch scheduling method and system and vehicle-mounted terminal

Abstract

The invention provides a patch dynamic scheduling method and system and a vehicle-mounted terminal. The patch dynamic scheduling method comprises the following steps: acquiring a multi-source data set in real time; wherein the multi-source data set at least comprises vehicle historical data, vehicle real-time data and third-party data; predicting unknown vulnerabilities and corresponding target risk levels based on the multi-source data set; and performing patch deployment feasibility evaluation based on the current vehicle state data of the target vehicle, so as to obtain a latest patch scheduling strategy based on a feasibility evaluation result, the unknown vulnerability, the target risk level and a historical patch scheduling strategy, and deploying the latest patch scheduling strategy to the target equipment. According to the method, unknown vulnerabilities can be found and quickly responded, so that the vulnerability response speed is increased; and moreover, patch pushing can be dynamically scheduled, driving safety and user experience are prevented from being affected, and patch deployment efficiency and accuracy are improved at the same time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of patch scheduling, in particular to a patch dynamic scheduling method and system and a vehicle terminal. BACKGROUND

[0002] The existing vulnerability discovery method has the possibility of lag, usually needs to rely on the disclosed vulnerability information, is difficult to discover new vulnerabilities, and has a long vulnerability repair time; in addition, generally only in a fixed period of time for patch updating or upgrading, unable to realize dynamic scheduling patch push, to a certain extent, will affect the driving safety and user experience. SUMMARY

[0003] The present application provides a patch dynamic scheduling method, system and vehicle terminal to solve the above technical problems.

[0004] Specifically, the present application provides a patch dynamic scheduling method, comprising the following steps: acquiring a multi-source data set in real time; wherein the multi-source data set at least includes vehicle historical data, vehicle real-time data and third-party data; predicting unknown vulnerabilities and corresponding target risk levels based on the multi-source data set; and performing patch deployment feasibility evaluation based on the current vehicle state data of the target vehicle, to obtain the latest patch scheduling strategy based on the feasibility evaluation result, unknown vulnerabilities, target risk levels and historical patch scheduling strategy and deploy to the target device.

[0005] In the above technical solution, unknown vulnerabilities can be discovered and quickly responded to, to improve the vulnerability response speed; and feasibility analysis is performed, which can evaluate whether the current time vehicle state is suitable for patch deployment, thereby realizing dynamic scheduling patch push, avoiding affecting the driving safety and user experience, and improving the patch deployment efficiency and accuracy.

[0006] Further, the vehicle real-time data at least includes vehicle state data and running code; after acquiring the multi-source data set, comprising: performing static analysis according to the running code to obtain a static analysis result, and generating a runtime vulnerability clue in combination with the static analysis result and dynamic test historical data; wherein the static analysis result at least includes potential vulnerabilities and corresponding initial risk levels and code positions; and extracting external vulnerability information based on the third-party data, and preprocessing and adding a timestamp to the external vulnerability information to obtain external threat information; wherein the preprocessing at least includes deduplication and association.

[0007] In the technical solution, the static analysis can provide basic information for subsequent vulnerability prediction, and the runtime vulnerability clues can comprehensively consider the possible vulnerabilities in the actual running process of the code, thereby improving the accuracy of vulnerability discovery; the operations of deduplication and correlation on the external vulnerability information can improve the quality and availability of the data, and the addition of the time stamp can help track the timeliness of the vulnerability information, so that the subsequent vulnerability prediction and analysis are more accurate.

[0008] Further, the vehicle historical data at least includes device operation logs and software management records; the prediction of unknown vulnerabilities and corresponding target risk levels based on the multi-source data set includes: extracting syntax features and statistical features based on the device operation logs and software management records; obtaining numerical features based on the static analysis results and runtime vulnerability clues; performing keyword vectorization and vulnerability category mapping according to the external threat information to obtain threat features; performing data cleaning on the syntax features, statistical features, numerical features, and threat features respectively to construct an initial feature subset; and performing feature importance evaluation on the initial feature subset to obtain a target feature subset based on the importance evaluation result.

[0009] In the technical solution, the above feature extraction can obtain key data, so that the subsequent vulnerability prediction is more objective and accurate; the data cleaning can remove redundant, missing, or conflicting feature data, thereby improving the quality and consistency of the data; the importance evaluation can filter out a subset highly related to vulnerability prediction, effectively reducing the feature dimension and the model complexity, thereby improving the prediction efficiency and accuracy of the model.

[0010] Further, a vulnerability prediction model is constructed in advance, and the vulnerability prediction model is trained based on historical vulnerability sample data to obtain a final vulnerability prediction model; the prediction of unknown vulnerabilities and corresponding target risk levels based on the multi-source data set also includes: inputting the target feature subset into the final vulnerability prediction model to obtain an initial vulnerability prediction result; and performing confidence analysis on the initial vulnerability prediction result to obtain a target vulnerability prediction result according to the confidence analysis result; wherein the target vulnerability prediction result includes unknown vulnerabilities and corresponding target risk levels.

[0011] In the technical solution, the trained prediction model and the filtered feature subset are used for vulnerability prediction, which can quickly and accurately obtain the vulnerability prediction result, thereby providing a basis for subsequent decision-making; the confidence analysis can evaluate the reliability of the initial vulnerability prediction result, so as to filter out a more reliable target vulnerability prediction result, thereby improving the accuracy and reliability of the vulnerability prediction.

[0012] Further, the obtaining the latest patch scheduling strategy comprises: performing priority ranking on the unknown vulnerabilities based on the feasibility evaluation result and the target risk level, to generate the latest patch scheduling strategy according to a priority ranking result and a historical patch scheduling strategy.

[0013] In the above technical solution, the priority ranking can reasonably arrange the order of vulnerability repair; in combination with the historical patch scheduling strategy, the patch scheduling is more scientific and reasonable, and the efficiency and accuracy of patch deployment are improved.

[0014] Further, the deploying the latest patch scheduling strategy to the target device comprises: performing a one-time verification on the latest patch scheduling strategy, and when the one-time verification passes, transmitting the latest patch scheduling strategy to the target device through a differential update technology; wherein the one-time verification at least comprises a compatibility verification and an integrity verification.

[0015] In the above technical solution, the one-time verification comprises a compatibility verification and an integrity verification, which can ensure that the latest patch scheduling strategy is compatible with the target device and the data is complete and intact; the differential update technology can only transmit the difference between the patch and the existing system, reducing the data transmission amount and improving the transmission efficiency.

[0016] Further, after the transmission of the latest patch scheduling strategy is completed, comprising: performing a second verification on the latest patch scheduling strategy, and when the second verification passes, updating the target device based on the latest patch scheduling strategy; wherein the second verification at least comprises a security verification.

[0017] In the above technical solution, the second verification comprises a security verification, which can ensure the security of the patch update process, prevent malicious code or unsafe patches from being installed on the target device, and ensure the safe and stable operation of the vehicle system.

[0018] Further, when the one-time verification fails, the second verification fails, or the transmission of the latest patch scheduling strategy is abnormal, comprising: rolling back to a previous patch scheduling strategy.

[0019] In the above technical solution, the rollback mechanism can recover to the previous stable patch scheduling strategy in time when a problem occurs, avoiding vehicle system failure or abnormality caused by patch deployment failure, and ensuring the normal operation of the vehicle.

[0020] Based on the same concept, the application also provides a patch dynamic scheduling system, which comprises a multi-source data acquisition module for acquiring a multi-source data set in real time; wherein the multi-source data set at least comprises vehicle historical data, vehicle real-time data and third-party data; a vulnerability prediction module for predicting unknown vulnerabilities and corresponding target risk levels based on the multi-source data set; and a patch scheduling module for performing patch deployment feasibility evaluation based on the current vehicle state data of a target vehicle, to obtain a latest patch scheduling strategy based on the feasibility evaluation result, unknown vulnerabilities, target risk levels and historical patch scheduling strategies and deploy the latest patch scheduling strategy to the target device.

[0021] In the above technical solution, the needs of the safety and usability of the intelligent networked vehicle can be met, the active prediction and patch scheduling of vehicle system vulnerabilities are realized, the impact on the normal use of the vehicle is minimized while ensuring the safety of the vehicle, and the efficiency and accuracy of patch deployment are improved.

[0022] Based on the same concept, the application also provides a vehicle-mounted terminal, which comprises a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to perform the patch dynamic scheduling method.

[0023] Compared with the prior art, the application has the following advantages: The application can discover unknown vulnerabilities and respond quickly, improve the vulnerability response speed, and realize dynamic scheduling patch pushing, avoid affecting driving safety and user experience, and improve the patch deployment efficiency and accuracy. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 A brief flowchart of the patch dynamic scheduling method described in the application.

[0025] Figure 2 A complete flowchart of the patch dynamic scheduling method described in the application.

[0026] Figure 3 A framework diagram of the patch dynamic scheduling system described in the application.

[0027] Figure 4 A workflow diagram of the vulnerability prediction module described in the application.

[0028] Figure 5 A workflow diagram of the patch scheduling module described in the application. DETAILED DESCRIPTION

[0029] The patch dynamic scheduling method, system and vehicle-mounted terminal of the present application will be further described in detail below in combination with specific embodiments and drawings.

[0030] Please refer to Figure 1 The present application provides a patch dynamic scheduling method, comprising the following steps S100-S300.

[0031] In a feasible implementation, please refer to Figure 2 First, a multi-source data set is collected, including at least vehicle state data, running code, device running log and software management record and third party data such as external threat intelligence. The running code needs to be analyzed statically, and dynamic analysis is also needed, i.e. combining the static analysis result and dynamic test historical data to generate runtime vulnerability clues. Then the collected data is standardized and stored. Further, feature extraction, vectorization, data cleaning, feature selection, etc. are performed on the multi-source data set, and then a good optimized vulnerability prediction model is constructed and trained in advance, and based on the processed multi-source data set, vulnerability risk prediction is performed to obtain potential vulnerability probability and corresponding risk level. Further, it is judged whether the vulnerability risk level is high. If the risk level is high, patch scheduling is immediately started, otherwise it is judged whether the vehicle state is suitable. If it is suitable, the patch is scheduled based on the state, if it is not suitable, the patch deployment is delayed. Further, patch scheduling strategy is generated according to the above judgment result and prediction result, and differential update technology is used to transmit the scheduling strategy to the target device. Compatibility and integrity verification need to be performed during transmission, and the state is monitored in real time during deployment. When an exception occurs, it is automatically rolled back to the original version, and after the patch is transmitted, digital signature verification is used to verify the integrity, testing is performed in a secure sandbox environment before execution, system stability is monitored after deployment, and updating is performed after no error is found.

[0032] Next, the steps S100-S300 will be described in detail.

[0033] Step S100: Real-time acquisition of multi-source data set; wherein the multi-source data set at least includes vehicle historical data, vehicle real-time data and third party data.

[0034] The vehicle real-time data at least includes vehicle state data and running code. After the multi-source data set is acquired, static analysis is performed according to the running code to obtain a static analysis result, and runtime vulnerability clues are generated by combining the static analysis result and dynamic test historical data. The static analysis result at least includes potential vulnerabilities and corresponding initial risk level and code location. External vulnerability information is extracted based on third party data, and the external vulnerability information is preprocessed and time stamped to obtain external threat information. The preprocessing at least includes deduplication and association.

[0035] In some embodiments, the vehicle status data includes speed, acceleration, gear position, engine speed, and charging / refueling status; the running code is the code currently stored in the corresponding storage medium to implement the device's functions; dynamic testing is testing performed during code execution to identify relevant vulnerabilities.

[0036] Specifically: Static analysis tools (such as Python) scan the code without running the program, performing lexical, syntactic, and semantic analysis. During the analysis, the static analysis tool records relevant information for each potential vulnerability, including a brief description of the vulnerability type and its potential impact, its severity level (e.g., high, medium, and low), and the code file and line number where the vulnerability is located. Then, the potential vulnerabilities in the static analysis results are correlated with vulnerabilities in historical dynamic testing data. This correlation adjusts the initial risk level in the static analysis results; for example, if a potential vulnerability appears frequently in dynamic testing, its risk level can be increased accordingly. Furthermore, runtime vulnerability clues are generated based on data correlation and risk level adjustments. These vulnerability clues include at least a vulnerability description, risk level, and code location.

[0037] Furthermore, the third-party data, such as tracking CVE (Common Vulnerabilities and Exposures) databases (Red Hat, CNNVD), vendor security bulletins, and vulnerability information related to vehicle systems extracted from industry vulnerability intelligence platforms, needs to be deduplicated and associated after obtaining this third-party data, and the time when the data was obtained should also be added.

[0038] It should be noted that the CVE database uses CVE numbers to enable security professionals, researchers, vendors, and users to share and reference specific vulnerability information among different security information sources, facilitating vulnerability tracking, assessment, and remediation.

[0039] It should also be noted that in step S100, the multi-source dataset needs to be saved according to a unified data structure and fields, and stored in the distributed database of the vehicle's local cache, edge computing nodes, and cloud analysis platform.

[0040] In the above technical solutions, static analysis can provide basic information for subsequent vulnerability prediction, while generating runtime vulnerability clues can more comprehensively consider the vulnerability situations that may occur in the code during actual operation, improving the accuracy of vulnerability discovery; performing operations such as deduplication and correlation on external vulnerability information can improve the quality and availability of data, and adding timestamps can help track the timeliness of vulnerability information, making subsequent vulnerability prediction and analysis more accurate.

[0041] Step S200: Predict unknown vulnerabilities and their corresponding target risk levels based on the multi-source dataset.

[0042] The vehicle historical data includes at least equipment operation logs and software management records. The prediction of unknown vulnerabilities and their corresponding target risk levels based on the multi-source dataset includes: extracting syntactic and statistical features from the equipment operation logs and software management records; obtaining numerical features based on the static analysis results and runtime vulnerability clues; performing keyword vectorization and vulnerability category mapping based on the external threat information to obtain threat features; performing data cleaning on the syntactic features, statistical features, numerical features, and threat features respectively to construct an initial feature subset; and evaluating the feature importance of the initial feature subset to obtain a target feature subset based on the importance evaluation results.

[0043] In some embodiments, the device, such as an ECU (Electronic Control Unit), is an embedded computing device within the vehicle used to control specific functional modules, such as engine control, body control, and infotainment systems. In this embodiment, the device operation log is the ECU operation log, which includes at least system call records, process information, memory usage, and abnormal event records. Furthermore, the software management records may be obtained from the version management records of the in-vehicle software, including code commit records, change differences, commit information, and reasons for changes.

[0044] Furthermore, the syntactic features include at least a function call graph and control flow features; the statistical features include at least the number of modified lines and module dependency; and the numerical features include at least the vulnerability type, recommended warning frequency, and anomaly triggering conditions.

[0045] In the above technical solution, key data can be obtained through feature extraction, making subsequent vulnerability prediction more objective and accurate; data cleaning can remove redundant, missing or conflicting feature data, improving data quality and consistency; importance assessment can screen out a subset that is highly relevant to vulnerability prediction, effectively reducing feature dimensions, reducing model complexity, and thus improving model prediction efficiency and accuracy.

[0046] Furthermore, a vulnerability prediction model is pre-constructed and trained based on historical vulnerability sample data to obtain a final vulnerability prediction model. The prediction of unknown vulnerabilities and their corresponding target risk levels based on the multi-source dataset further includes: inputting the target feature subset into the final vulnerability prediction model to obtain an initial vulnerability prediction result; and performing a confidence analysis on the initial vulnerability prediction result to obtain a target vulnerability prediction result based on the confidence analysis result. The target vulnerability prediction result includes unknown vulnerabilities and their corresponding target risk levels.

[0047] In some embodiments, a lightweight convolutional neural network (CNN) or graph neural network (GNN), i.e., a pre-built vulnerability prediction model, is constructed to handle structured and graph-structured features. An attention mechanism is introduced into the model to highlight the weights of key features. Further supervised training is performed using historical vulnerability sample data to obtain the final vulnerability prediction model. Optimization techniques such as model quantization and pruning are applied to reduce the number of model parameters, enabling real-time operation in ECUs or edge devices. The final vulnerability prediction model then outputs the probability of vulnerability existence and risk level (high / medium / low) for each software module based on a subset of target features. Confidence analysis of the prediction results is performed, and low-confidence results should be submitted for manual review.

[0048] In the above technical solution, vulnerability prediction can be performed using a trained prediction model and a selected feature subset, which can quickly and accurately obtain vulnerability prediction results and provide a basis for subsequent decision-making. Confidence analysis can be used to evaluate the reliability of the initial vulnerability prediction results, thereby selecting more credible target vulnerability prediction results and improving the accuracy and reliability of vulnerability prediction.

[0049] Step S300: Perform a patch deployment feasibility assessment based on the current vehicle status data of the target vehicle, and obtain the latest patch scheduling strategy based on the feasibility assessment results, unknown vulnerabilities, target risk level and historical patch scheduling strategies, and deploy it to the target device.

[0050] In some embodiments, the current state of the vehicle (such as driving, stationary, charging, etc.) is collected, and network bandwidth, latency and stability indicators are obtained, as well as the utilization rate of vehicle hardware resources (CPU, memory, storage space) is detected. Based on the real-time scenario, the impact of the deployment process on driving safety or normal use is estimated, and the patch file size is compared with the current network bandwidth to calculate the transmission time and obtain the feasibility assessment results.

[0051] The step of obtaining the latest patch scheduling strategy includes: prioritizing the unknown vulnerabilities based on the feasibility assessment results and the target risk level, and generating the latest patch scheduling strategy according to the priority ranking results and historical patch scheduling strategies.

[0052] In some embodiments, the target risk level output by the vulnerability prediction model is used as a weight input to the scheduling decision algorithm based on the feasibility assessment results. High-risk vulnerabilities are prioritized for update queues, while medium- and low-risk vulnerabilities can be delayed until low-load periods. Additionally, a Q-learning reinforcement learning algorithm is used to adjust the decision strategy based on historical patch scheduling strategies to obtain a new patch scheduling strategy. The output includes a complete scheduling scheme that includes deployment time windows, patch distribution paths (local / edge / cloud), and update batches.

[0053] In the above technical solutions, priority sorting can be used to reasonably arrange the order of vulnerability repair; combined with historical patch scheduling strategies, patch scheduling becomes more scientific and reasonable, improving the efficiency and accuracy of patch deployment.

[0054] Furthermore, deploying the latest patch scheduling strategy to the target device includes: performing a verification on the latest patch scheduling strategy, so that when the verification passes, the latest patch scheduling strategy is transmitted to the target device using differential update technology; wherein, the verification includes at least compatibility verification and integrity verification.

[0055] In some embodiments, differential update technology is used to push patches to the target ECU. Before deployment, compatibility and integrity are verified in a sandbox environment. During deployment, the status is monitored in real time, and if an anomaly occurs, the system automatically rolls back to the original version.

[0056] It should be noted that a sandbox environment is an isolated operating environment used to execute unverified software under controlled conditions, preventing potential risks from affecting the main system.

[0057] In the above technical solutions, a single verification includes compatibility verification and integrity verification, which can ensure that the latest patch scheduling strategy is compatible with the target device and that the data is complete and without missing parts; differential update technology can transmit only the differences between the patch and the existing system, reducing the amount of data transmission and improving transmission efficiency.

[0058] Furthermore, after the latest patch scheduling policy is transmitted, the process includes: performing a secondary verification on the latest patch scheduling policy, so that when the secondary verification passes, the target device is updated based on the latest patch scheduling policy; wherein, the secondary verification includes at least a security verification.

[0059] In some embodiments, after the patch is transmitted, its integrity is verified by digital signature. Before execution, it is tested in a secure sandbox environment. After deployment, its system stability is monitored. If there are no errors, the update is performed. Otherwise, it is automatically rolled back to the original version.

[0060] It should be noted that digital signature verification uses signature information generated by asymmetric encryption algorithms to verify the integrity and trustworthiness of files during patch transmission and installation.

[0061] In the above technical solution, secondary verification includes security verification, which can ensure the security of the patch update process, prevent malicious code or insecure patches from being installed on the target device, and ensure the safe and stable operation of the vehicle system.

[0062] Furthermore, when a first verification fails, a second verification fails, or the latest patch scheduling policy is transmitted abnormally, the following measures are taken: rollback to the previous patch scheduling policy.

[0063] In the above technical solution, the rollback mechanism can promptly restore to the previous stable patch scheduling strategy when problems occur, avoiding vehicle system failures or anomalies caused by patch deployment failures, and ensuring the normal operation of the vehicle.

[0064] In summary, the patch dynamic scheduling method described in this application can discover unknown vulnerabilities and respond quickly, thereby improving vulnerability response speed; and it performs feasibility analysis to assess whether the current vehicle status is suitable for patch deployment, thus achieving dynamic scheduling of patch push, avoiding impact on driving safety and user experience, while improving patch deployment efficiency and accuracy.

[0065] Based on the same concept, please refer to Figure 3 This application also provides a patch dynamic scheduling system, the system comprising: a multi-source data acquisition module for acquiring multi-source datasets in real time; wherein the multi-source datasets include at least historical vehicle data, real-time vehicle data, and third-party data; a vulnerability prediction module for predicting unknown vulnerabilities and their corresponding target risk levels based on the multi-source datasets; and a patch scheduling module for performing a patch deployment feasibility assessment based on the current vehicle status data of the target vehicle, so as to obtain the latest patch scheduling strategy and deploy it to the target device based on the feasibility assessment results, unknown vulnerabilities, target risk levels, and historical patch scheduling strategies.

[0066] The execution process of the vulnerability prediction module and the patch scheduling module is as follows: Figure 4 and 5 As shown, the specific implementation method can be found in the patch dynamic scheduling method described above, and will not be elaborated here.

[0067] The above technical solution can meet the current needs of intelligent connected vehicles for both security and availability, realize the proactive prediction and patch scheduling of vehicle system vulnerabilities, minimize the impact on normal vehicle use while ensuring vehicle security, and improve the efficiency and accuracy of patch deployment.

[0068] Based on the same concept, this application also provides a vehicle-mounted terminal, which includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set are loaded by the processor and executed using the patch dynamic scheduling method.

[0069] In some embodiments, the memory and processor are interconnected via a bus; the processor may be one or more CPUs. If the processor is a single CPU, it may be a single-core CPU or a multi-core CPU. The processor is used to control various functional modules of the vehicle terminal and process signals. The memory includes, but is not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), and CD-ROM (Compact Disc Read-Only Memory). This memory is used to store computer programs, operating systems, various applications, and data, such as storing computer programs used to implement the patch dynamic scheduling method.

[0070] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.

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

[0072] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0073] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0074] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0075] Although the description of this application has been made in conjunction with the specific embodiments described above, it will be apparent to those skilled in the art that many substitutions, modifications, and variations can be made based on the foregoing. Therefore, all such substitutions, modifications, and variations are included within the spirit and scope of the appended claims.

Claims

1. A patch dynamic scheduling method, characterized in that, Includes the following steps: Real-time acquisition of multi-source datasets; wherein, the multi-source datasets include at least historical vehicle data, real-time vehicle data, and third-party data; Predict unknown vulnerabilities and their corresponding target risk levels based on the aforementioned multi-source dataset; Additionally, a patch deployment feasibility assessment is conducted based on the target vehicle's current vehicle status data. Based on the feasibility assessment results, unknown vulnerabilities, target risk level, and historical patch scheduling strategies, the latest patch scheduling strategy is obtained and deployed to the target device.

2. The patch dynamic scheduling method according to claim 1, characterized in that, The real-time vehicle data includes at least vehicle status data and operating code; After obtaining the multi-source dataset, the following is included: Static analysis is performed on the running code to obtain static analysis results, and runtime vulnerability clues are generated by combining the static analysis results with dynamic test history data; wherein, the static analysis results include at least potential vulnerabilities and their corresponding initial risk levels and code locations; Furthermore, external vulnerability information is extracted based on third-party data, and the external vulnerability information is preprocessed and timestamped to obtain external threat information; wherein, the preprocessing includes at least deduplication and association.

3. The patch dynamic scheduling method according to claim 2, characterized in that, The vehicle historical data includes at least equipment operation logs and software management records; the prediction of unknown vulnerabilities and corresponding target risk levels based on the multi-source dataset includes: Extract syntactic and statistical features based on the device operation logs and software management records; Numerical characteristics are obtained based on the static analysis results and runtime vulnerability clues; Based on the external threat information, keyword vectorization and vulnerability category mapping are performed to obtain threat characteristics; Data cleaning was performed on the grammatical features, statistical features, numerical features, and threat features respectively to construct an initial feature subset; In addition, the initial feature subset is evaluated for feature importance, so as to obtain the target feature subset based on the importance evaluation results.

4. The patch dynamic scheduling method according to claim 3, characterized in that, A vulnerability prediction model is pre-built and trained based on historical vulnerability sample data to obtain the final vulnerability prediction model; the prediction of unknown vulnerabilities and their corresponding target risk levels based on the multi-source dataset also includes: The target feature subset is input into the final vulnerability prediction model to obtain the initial vulnerability prediction result; Furthermore, a confidence analysis is performed on the initial vulnerability prediction results to obtain target vulnerability prediction results based on the confidence analysis results; wherein, the target vulnerability prediction results include unknown vulnerabilities and their corresponding target risk levels.

5. The patch dynamic scheduling method according to claim 4, characterized in that, The latest patch scheduling strategy includes: The unknown vulnerabilities are prioritized based on the feasibility assessment results and the target risk level, and the latest patch scheduling strategy is generated based on the priority ranking results and historical patch scheduling strategies.

6. The patch dynamic scheduling method according to claim 5, characterized in that, Deploying the latest patch scheduling policy to the target device includes: The latest patch scheduling policy is verified once, and if the verification passes, the latest patch scheduling policy is transmitted to the target device using differential update technology; wherein, the verification includes at least compatibility verification and integrity verification.

7. The patch dynamic scheduling method according to claim 6, characterized in that, After the latest patch scheduling policy is transmitted, it includes: The latest patch scheduling policy is subjected to secondary verification, so that when the secondary verification passes, the target device is updated based on the latest patch scheduling policy; wherein, the secondary verification includes at least security verification.

8. The patch dynamic scheduling method according to claim 7, characterized in that, When the first verification fails, the second verification fails, or the latest patch scheduling policy is transmitted abnormally, including: Roll back to the previous patch scheduling strategy.

9. A system employing the patch dynamic scheduling method as described in any one of claims 1-8, characterized in that, The system includes: A multi-source data acquisition module is used to acquire multi-source datasets in real time; wherein, the multi-source datasets include at least historical vehicle data, real-time vehicle data, and third-party data; The vulnerability prediction module is used to predict unknown vulnerabilities and their corresponding target risk levels based on the multi-source dataset. It also includes a patch scheduling module, which is used to conduct a patch deployment feasibility assessment based on the current vehicle status data of the target vehicle, and to obtain the latest patch scheduling strategy based on the feasibility assessment results, unknown vulnerabilities, target risk level and historical patch scheduling strategies, and then deploy it to the target device.

10. A vehicle-mounted terminal, characterized in that, The vehicle-mounted terminal includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the patch dynamic scheduling method as described in any one of claims 1-8.

Images