Blockchain-based methods, systems, devices, and media for managing vulnerabilities in the Internet of Vehicles (IoV).

Abstract

This invention provides a blockchain-based method, system, device, and medium for managing vehicle network vulnerabilities, relating to the field of vehicle network technology. The method utilizes a dynamic and static vulnerability detection mechanism to comprehensively identify potential vehicle security risks and generate structured vulnerability reports. By using blockchain to hash and store key data from the report and subsequent remediation processes, the entire process of vulnerability discovery, analysis, and remediation is tamper-proof and traceable, enhancing data authenticity and trustworthiness. Cloud-based verification of report integrity, combined with an AI analysis engine linking CVE databases and threat intelligence, enables intelligent generation and decision support for remediation solutions. On-vehicle verification of OTA patches via on-chain hash digests ensures the credibility of patch sources and the integrity of content. Finally, feedback on installation results and re-archiving on the blockchain completes a closed-loop management system from vulnerability discovery to remediation verification.

Description

Technical Field

[0001] This invention relates to the field of vehicle network technology, and in particular to a blockchain-based method, system, device, and medium for managing vehicle network vulnerabilities. Background Technology

[0002] With technological advancements, intelligent connected vehicles (ICVs) have become a crucial direction for the automotive industry. However, under the trend of software-defined vehicles (SDVs), vehicle function iteration and performance optimization increasingly rely on software and firmware updates, especially the widespread adoption of over-the-air (OTA) updates. This has led to a surge in software code size and unprecedented security challenges arising from network connectivity. From in-vehicle entertainment systems to core power and braking control systems, vulnerabilities in any software component can be maliciously exploited, threatening the lives and property of passengers. Current security solutions for intelligent connected vehicles mainly focus on traditional vulnerability scanning and management systems, in-vehicle intrusion detection systems (IDS), and centralized OTA upgrade platforms. However, these methods suffer from issues such as a lack of trust and transparency, delayed and passive responses, isolated and inefficient processes, and security vulnerabilities during OTA updates. Summary of the Invention

[0003] The purpose of this invention is to provide a blockchain-based method, system, device, and medium for managing vehicle network vulnerabilities, in order to solve one or more technical problems existing in the prior art, or at least provide a beneficial option or create conditions.

[0004] The solution to the technical problem of this invention is as follows: On the one hand, this invention provides a blockchain-based method for managing vehicle network vulnerabilities, comprising the following steps:

[0005] The system acquires the vehicle's in-vehicle software files and real-time data streams, performs dynamic and static vulnerability detection, and determines whether to trigger a vulnerability alert event based on the vulnerability detection results.

[0006] Generate a structured vulnerability report based on the vulnerability alert events;

[0007] The hash digest of the vulnerability report is uploaded to the blockchain for evidence storage, and the vulnerability report is encrypted and transmitted to the cloud platform; the on-chain evidence storage refers to uploading to the consortium blockchain through a smart contract to complete the evidence storage;

[0008] On the cloud platform, the integrity of the vulnerability report is verified by the hash digest of the vulnerability report, and the AI ​​analysis engine is invoked to associate the CVE database and threat intelligence to generate a remediation plan and store it on the blockchain.

[0009] An OTA patch is developed based on the aforementioned repair scheme. The hash digest of the OTA patch is then stored on the blockchain and pushed to the vehicle.

[0010] On the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch, the OTA patch is installed, an installation result report is generated, and the report is sent back to the cloud platform and stored on the blockchain.

[0011] Furthermore, the process of acquiring the vehicle's in-vehicle software files and real-time data streams, performing dynamic and static vulnerability detection, and determining whether to trigger a vulnerability alert event based on the vulnerability detection results includes the following steps:

[0012] The vehicle software file is obtained, static vulnerability detection is performed, the vehicle software file is matched with a preset vulnerability signature database, and it is determined whether the matching result triggers a vulnerability alarm event; the vehicle software file includes key configuration files and a vehicle software list;

[0013] The system acquires the vehicle's CAN bus messages, Ethernet communication data, CPU and memory usage, and file read / write operation logs to form a multi-dimensional real-time data stream.

[0014] The real-time data stream is input into a pre-trained anomaly detection model to perform dynamic vulnerability detection, obtain anomaly detection results, and determine whether the anomaly detection results trigger a vulnerability alarm event.

[0015] Furthermore, generating a structured vulnerability report based on the vulnerability alert event includes the following steps:

[0016] Obtain the raw data of the vulnerability alert event;

[0017] The raw data includes alarm type, trigger time, detection source identifier, associated vehicle identification number, and vehicle operating status;

[0018] The raw data is structured based on a preset report template to extract vulnerability feature fields;

[0019] The vulnerability feature fields include vulnerability number, risk level, affected vehicle components, detection evidence hash value, alarm source identifier, and abnormal indicators;

[0020] The blockchain smart contract interface is invoked to correlate and verify the vulnerability feature fields with the vehicle baseline data stored on the chain, generating a trusted data fragment containing a timestamp and digital signature.

[0021] Integrate the vulnerability feature fields with trusted data fragments to generate a structured vulnerability report;

[0022] The vulnerability report includes a hash digest, a smart contract storage address, and specific original evidence data that triggered the vulnerability alert event.

[0023] Furthermore, on the cloud platform, the integrity of the vulnerability report is verified through its hash digest, and an AI analysis engine is invoked to correlate the CVE database with threat intelligence, generate a remediation plan, and upload it to the blockchain for evidence storage. This includes the following steps:

[0024] On the cloud platform, the completeness of the vulnerability report is verified by querying the hash digest of the vulnerability report stored on the consortium blockchain through the blockchain smart contract interface.

[0025] If the verification passes, the AI ​​analysis engine is invoked to access the associated CVE database and the threat intelligence to generate the remediation plan, which is then stored on the blockchain for verification. Specifically, this includes:

[0026] The AI ​​analysis engine is invoked to perform in-depth analysis on the vulnerability feature fields in the vulnerability report, and the analysis results are obtained, including the vulnerability number, affected components and abnormal indicators corresponding to the vulnerability alarm event.

[0027] By connecting to the CVE database through the API interface, the vulnerability details corresponding to the vulnerability number are matched;

[0028] By integrating the real-time threat intelligence, the actual severity of the vulnerability alert event is dynamically assessed to obtain a dynamic severity level;

[0029] Based on the analysis results, the vulnerability details, and the dynamic severity level, a preliminary solution is generated.

[0030] The preliminary plan includes vulnerability cause analysis, temporary mitigation measures, and OTA patch development recommendations;

[0031] Based on the criticality level and repair complexity of the affected components, the preliminary solutions are prioritized and reviewed to obtain the repair solutions, which are then stored on the blockchain for evidence.

[0032] Furthermore, the process of developing an OTA patch based on the aforementioned repair scheme, storing the hash digest of the OTA patch on the blockchain, and then pushing it to the vehicle includes the following steps:

[0033] OTA patch development is carried out based on the aforementioned repair scheme, generating OTA patch files to be pushed.

[0034] The smart contract is invoked to upload the hash digest of the OTA patch file to the consortium blockchain to complete the notarization, and a blockchain transaction record including the notarization timestamp is generated;

[0035] The OTA patch file is encrypted and transmitted to the vehicle via a vehicle-to-everything (V2X) secure communication protocol.

[0036] The vehicle terminal refers to the T-BOX terminal of the target vehicle.

[0037] The transmission status is monitored in real time during the push process. If an interruption occurs, the breakpoint resume mechanism is triggered to ensure that the OTA patch file is delivered completely.

[0038] Furthermore, on the vehicle side, the integrity of the OTA patch is verified through its hash digest, the OTA patch is installed, an installation result report is generated, and this report is fed back to the cloud platform and stored on the blockchain. This includes the following steps:

[0039] After receiving the OTA patch file, the integrity of the OTA patch is verified by the hash digest of the OTA patch;

[0040] If the verification is successful, the vehicle-side secure execution environment is started, and the OTA patch file is decompressed, verified, and integrated into the system according to the preset installation process;

[0041] After installation, the installation result report is generated and sent to the cloud platform to update the vulnerability remediation status dashboard.

[0042] The installation result report includes the installation time, patch version, vehicle identification number, and execution status.

[0043] Based on the installation result report, the corresponding hash digest is extracted and stored on the blockchain.

[0044] Furthermore, on the cloud platform, the integrity of the vulnerability report is verified by using the hash digest of the vulnerability report according to the consensus algorithm;

[0045] On the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch according to the consensus algorithm.

[0046] On the other hand, this application provides a blockchain-based vehicle networking vulnerability management system, including a vulnerability alarm triggering module, a vulnerability report on-chain evidence storage module, a remediation solution on-chain evidence storage module, an OTA patch on-chain evidence storage module, and an OTA patch verification and installation module.

[0047] The vulnerability alarm triggering module is used to obtain the vehicle's in-vehicle software files and real-time data streams, perform dynamic and static vulnerability detection, and determine whether to trigger a vulnerability alarm event based on the vulnerability detection results.

[0048] The vulnerability report on-chain evidence storage module is used to generate a structured vulnerability report based on the vulnerability alert event; store the hash digest of the vulnerability report on the blockchain for evidence storage, and encrypt and transmit the vulnerability report to the cloud platform; the on-chain evidence storage refers to uploading to the consortium blockchain through a smart contract to complete the evidence storage;

[0049] The on-chain evidence storage module for the remediation solution is used on the cloud platform to verify the integrity of the vulnerability report through the hash digest of the vulnerability report, and to call the AI ​​analysis engine to associate the CVE database and threat intelligence to generate a remediation solution and store it on the blockchain.

[0050] The OTA patch on-chain notarization module is used to develop an OTA patch based on the repair scheme, and push the hash digest of the OTA patch on-chain notarization to the vehicle.

[0051] The OTA patch verification and installation module is used on the vehicle to verify the integrity of the OTA patch through the hash digest of the OTA patch, execute the installation of the OTA patch, generate an installation result report, and feed it back to the cloud platform and on-chain evidence storage.

[0052] On the other hand, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned blockchain-based vehicle network vulnerability management method.

[0053] On the other hand, this application provides a computer storage medium including a computer program, which, when executed by a processor, implements the aforementioned blockchain-based vehicle network vulnerability management method.

[0054] The beneficial effects of this invention are as follows: This application provides a blockchain-based method for managing vehicle network vulnerabilities. This method, through a combination of dynamic and static vulnerability detection mechanisms, can comprehensively identify potential vehicle security risks and generate structured vulnerability reports. By utilizing blockchain to perform hash digest storage on key data in the report and subsequent remediation stages, the entire process of vulnerability discovery, analysis, and remediation is tamper-proof and traceable, improving data authenticity and trustworthiness. By verifying the integrity of the report in the cloud and combining it with an AI analysis engine to link the CVE database and threat intelligence, intelligent generation and decision support for remediation solutions are achieved. On the vehicle side, verification of the on-chain hash digest of OTA patches ensures the credibility of the patch source and the integrity of its content, effectively preventing malicious update attacks. Finally, through feedback on the installation results and re-archiving on the blockchain, a complete closed-loop management system from vulnerability discovery to remediation verification is formed. This application also provides corresponding systems, devices, and media. The beneficial effects of the systems, devices, and media are similar to those of the method and will not be elaborated here.

[0055] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0056] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0057] Figure 1 This is a flowchart of the blockchain-based vehicle networking vulnerability management method provided in this application;

[0058] Figure 2 This is a structural diagram of the blockchain-based vehicle network vulnerability management system provided in this application. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0060] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0061] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0063] Intelligent Connected Vehicles (ICVs) have become an important component of future transportation systems. Modern ICVs are no longer merely traditional mechanical transportation tools, but highly complex cyber-physical systems integrating numerous electronic control units (ECUs), sensors, in-vehicle infotainment systems, advanced driver assistance systems (ADAS), and even autonomous driving systems. Through vehicle-to-everything (V2X) technology, vehicles communicate in real-time with cloud platforms, other vehicles, road infrastructure, and mobile devices, enabling various new functions such as remote diagnostics, intelligent navigation, and cooperative driving.

[0064] Against this backdrop, the concept of "Software-Defined Vehicle" (SDV) is increasingly becoming mainstream. Vehicle functionality increasingly relies on software and firmware updates and upgrades, and the traditional hardware-dominated model is gradually being replaced by a flexible, software-driven architecture. Over-the-Air (OTA) technology, as a core means of enabling remote software updates, has been widely used in OEM product iterations to fix defects, optimize performance, enhance user experience, and address emerging security threats.

[0065] However, with the exponential growth of vehicle software code (some high-end models have exceeded 100 million lines of code) and the increasing openness of network interfaces, intelligent connected vehicles face unprecedented cybersecurity challenges. Attackers can launch attacks on vehicles through various means (such as Bluetooth, Wi-Fi, cellular networks, USB interfaces, and even via CAN bus or in-vehicle Ethernet). Once an attack is successful, it may not only lead to privacy breaches and hijacking of vehicle control, but more seriously, it may endanger the lives of passengers. For example, remote vulnerabilities could be used to control the vehicle's braking system, steering system, or engine start-stop function, highlighting the urgency of establishing an efficient, reliable, and closed-loop vehicle network security management system.

[0066] Currently, the industry primarily employs the following technical methods to address the security risks of connected vehicles. First, there are traditional vulnerability scanning and management systems. These systems draw on IT security practices, performing static or dynamic analysis of the firmware of onboard ECUs during vehicle R&D, testing, or production to identify potential software vulnerabilities. Second, there are in-vehicle intrusion detection systems (IDS). These systems are deployed within the vehicle's internal network (such as CAN bus or in-vehicle Ethernet) and monitor communication traffic, system calls, and process behavior, using rule-based detection (signature-based detection) or anomaly-based detection algorithms to identify potential attack behaviors. When abnormal traffic or illegal commands are detected, the system logs information and sends alerts to the cloud platform. Third, there is OTA (Over-The-Air) technology, which effectively improves the flexibility and efficiency of vehicle software maintenance. Mainstream platforms typically use HTTPS / TLS encrypted transmission and digital signature verification to ensure communication security.

[0067] While the aforementioned technologies have mitigated vehicle-to-everything (V2X) security risks to some extent, they have revealed several key shortcomings when faced with increasingly complex attack scenarios and stringent compliance requirements.

[0068] First, traditional vulnerability scanning is mostly performed periodically or at specific development nodes, failing to provide continuous 24 / 7 monitoring of vehicle operation and making it difficult to promptly detect new or unknown vulnerabilities. While in-vehicle IDS possess some real-time detection capabilities, they often only reach the "alarm" level, lacking integration with cloud analysis, patch development, and OTA updates, resulting in an excessively long time window from vulnerability discovery to remediation. For "zero-day vulnerabilities," existing systems are almost entirely unable to proactively predict and respond quickly, exhibiting a passive and lagging overall defense system.

[0069] Secondly, while existing OTA platforms employ encryption and signature technologies, significant security vulnerabilities remain: If a centralized OTA server is compromised, attackers can tamper with patch content or forge update commands, pushing malicious firmware to a large number of vehicles, causing catastrophic consequences. Most vehicles only verify the security of the communication link (such as TLS certificates), while the source and integrity of the patch package itself depend on the server's trustworthiness, lacking an independent, decentralized verification mechanism. The entire process from patch release to installation lacks immutable audit logs, making it impossible to prove whether a particular vehicle has actually installed the correct patch, impacting compliance audits and insurance claims.

[0070] Furthermore, existing systems still heavily rely on the experience and judgment of security experts during the vulnerability analysis phase, resulting in low levels of automation. Faced with massive amounts of alert data and complex vehicle architectures, manual analysis is time-consuming, costly, and susceptible to subjective influences. Simultaneously, the lack of capabilities for risk assessment, impact analysis, and remediation suggestion generation based on historical data and AI models hinders the accurate and efficient prioritization of vulnerabilities and the formulation of appropriate remediation strategies.

[0071] To address the aforementioned challenges, this application proposes a blockchain-based method, system, device, and medium for managing vehicle network vulnerabilities. This effectively enhances the credibility and transparency of the entire security process, enables proactive and intelligent vulnerability detection and analysis, and strengthens the security of OTA updates.

[0072] Specifically, this method combines static signature matching with dynamic behavior analysis to achieve real-time proactive detection of known and unknown vulnerabilities. By storing hash digests of key data such as vulnerability reports, remediation plans, OTA patches, and installation results on the blockchain, it leverages the immutability and multi-party consensus mechanism of the consortium blockchain to ensure the transparency and traceability of the entire process, preventing data forgery and repudiation. An AI analysis engine is introduced in the cloud to automatically link CVE databases and threat intelligence, intelligently generating remediation strategies, which are then manually reviewed and confirmed on the blockchain, improving response efficiency and decision-making accuracy. During OTA updates, the vehicle proactively verifies the patch hash from the blockchain before installation, ensuring that only consensus-certified official patches are installed, effectively resisting supply chain attacks. This method represents a leap from "passive response" to "proactive defense, intelligent decision-making, and trusted execution," effectively enhancing the overall security, trustworthiness, and operational efficiency of the connected vehicle system.

[0073] First, the blockchain-based vehicle network vulnerability management method provided in this application will be described in detail below with reference to the accompanying drawings.

[0074] Reference Figure 1 The implementation process of the blockchain-based vehicle network vulnerability management method provided in this application includes, but is not limited to, the following steps.

[0075] Step S110: Obtain the vehicle's in-vehicle software files and real-time data stream, perform dynamic and static vulnerability detection, and determine whether to trigger a vulnerability alarm event based on the vulnerability detection results.

[0076] In step S110, static analysis of in-vehicle software files (such as ECU firmware, operating system images, application packages, etc.) can identify code characteristics of known vulnerabilities, insecure programming patterns, and disclosed CVE vulnerabilities in third-party components. Simultaneously, real-time data streams during vehicle operation (such as CAN bus communication, in-vehicle Ethernet traffic, system call logs, process behavior, etc.) are collected, and combined with dynamic behavior monitoring technology, potential attack behaviors such as abnormal commands, unauthorized access, and protocol violations can be captured. This combined static and dynamic detection approach ensures a high detection rate for known risks while effectively discovering early signs of unknown vulnerabilities or zero-day attacks. When the detection results meet preset alarm thresholds or match high-risk rules, the system will automatically trigger a vulnerability alarm event, marking the initiation of the security response process. The core significance of this step lies in shifting from passive defense to proactive monitoring, ensuring that security threats are discovered at an early stage, laying the foundation for subsequent rapid response and closed-loop handling.

[0077] Step S120: Generate a structured vulnerability report based on the vulnerability alert event.

[0078] In step S120, after detecting a vulnerability alert event, the original detection results are transformed into standardized, processable, and traceable structured information. The structured vulnerability report typically includes key fields such as vulnerability type (e.g., buffer overflow, privilege escalation, remote code execution), affected components (ECU name, software version, firmware hash), severity level (CVSS score), detection time, vehicle identification number (VIN), geographical location, contextual environment (e.g., vehicle operating status, network connectivity), and original log fragments. This report not only provides complete context for subsequent analysis but also supports automated processing and cross-system sharing.

[0079] The significance of this step lies in three aspects: first, it avoids information loss or ambiguity, improving the accuracy of information transmission; second, it facilitates unified parsing and aggregation analysis on the cloud platform; and third, it provides a consistent data format for on-chain evidence storage, ensuring the standardization and auditability of blockchain records. By generating structured reports, the transformation from "raw alarms" to "actionable intelligence" is achieved, which is a key step in building an efficient and secure operation system.

[0080] Step S130: Upload the hash digest of the vulnerability report to the blockchain for evidence storage, and encrypt and transmit the vulnerability report to the cloud platform.

[0081] Among them, on-chain evidence storage refers to the process of uploading evidence to the consortium blockchain via a smart contract.

[0082] In step S130, the structured vulnerability report is processed using a hash algorithm (such as SHA-256) to generate a unique hash digest. This digest is then submitted to a pre-established consortium blockchain network via a smart contract deployed on the vehicle or edge node to complete the on-chain operation. Due to the immutability and timestamping characteristics of the blockchain, once the hash value is recorded, it means that the existence, integrity, and occurrence time of the vulnerability report are permanently fixed. Any subsequent modifications to the original report will result in a hash value mismatch, which can be easily identified, effectively preventing data tampering or denial.

[0083] Meanwhile, the original vulnerability report is securely transmitted to the cloud platform via an encrypted channel (such as TLS or end-to-end encryption), ensuring the confidentiality of the data during transmission. The significance of this step lies in establishing a data trust anchor from the vehicle to the cloud, achieving "anti-counterfeiting" and "traceability" of vulnerability information, providing strong technical support for subsequent liability determination, compliance audits, and judicial evidence collection. Furthermore, the consortium blockchain mechanism balances decentralization and controllability, making it suitable for the complex ecosystem of multi-party collaboration (OEMs, suppliers, regulatory agencies) in the automotive industry.

[0084] Step S140: On the cloud platform, the integrity of the vulnerability report is verified by the hash digest of the vulnerability report, and the AI ​​analysis engine is called to associate the CVE database and threat intelligence to generate a remediation plan and store it on the blockchain.

[0085] In step S140, after receiving the encrypted vulnerability report, the cloud platform first recalculates its hash value and compares it with the hash digest already stored on the blockchain. If they match, it proves that the report has not been tampered with during transmission, ensuring the integrity and authenticity of the data. After successful verification, the system calls the integrated AI analysis engine to automatically correlate the vulnerability characteristics with publicly available CVE databases, vendor-owned vulnerability databases, and third-party threat intelligence platforms (such as MITRE ATT&CK and VulDB) to identify the cause, scope of impact, attack path, and potential severity of the vulnerability. Based on this, the AI ​​engine can generate preliminary remediation suggestions, such as patch strategies, configuration adjustments, and temporary mitigation measures. These suggestions are then reviewed and confirmed by security experts to form the final remediation plan. This remediation plan also generates a hash digest and stores it on the blockchain to ensure its authority and non-repudiation.

[0086] The significance of this step lies in: realizing a leap from "manual analysis" to "intelligent decision-making," significantly improving vulnerability response efficiency; enhancing the ability to identify complex attack patterns through the integration of AI and threat intelligence; and further strengthening the transparency and auditability of the entire process by storing the remediation solution on the blockchain, providing a trustworthy foundation for multi-level collaborative governance.

[0087] Step S150: Develop an OTA patch based on the repair scheme, store the hash digest of the OTA patch on the blockchain, and then push it to the vehicle.

[0088] In step S150, after the repair solution is confirmed, the OTA patch is developed, tested, and packaged. This patch may be a firmware update for an ECU, an operating system patch, or an application upgrade package. After the patch development is completed, the system first calculates its hash value and stores it on the blockchain via a smart contract. This operation has multiple security implications: on the one hand, storing the patch hash on the blockchain is equivalent to "publicly announcing" the official and unique legitimate version across the entire network, and any subsequent tampering will result in hash mismatch; on the other hand, this storage constitutes an official record of the patch release, which can be used to track the patch's source, release time, and responsible party. Only after the blockchain storage is completed is the patch allowed to be pushed to the target vehicle.

[0089] The core function of this step is to: establish a "trusted source" for OTA patches, preventing malicious attackers from forging or hijacking update packages; achieve strong consistency and verifiability of patch releases through the "first evidence, then distribution" mechanism; and provide authoritative reference values ​​for subsequent integrity verification on the vehicle side, which is a key line of defense to ensure the security of OTA updates.

[0090] Step S160: On the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch, the OTA patch is installed, an installation result report is generated, and the report is sent to the cloud platform and stored on the blockchain.

[0091] In step S160, when the vehicle receives the OTA patch, it does not install it immediately. Instead, it first queries the official hash digest corresponding to the patch from the consortium blockchain and compares it with the recalculated hash value of the locally downloaded patch file. Only when the two are completely consistent is the installation process allowed to start, thereby effectively preventing risks such as man-in-the-middle attacks and malicious patch pushes caused by server intrusion.

[0092] The installation process is typically performed under the protection of Secure Boot and a Trusted Execution Environment (TEE) to ensure that the update process is not interfered with. After installation, the vehicle generates an installation result report containing information such as installation status (success / failure), timestamp, version number, and error logs. This report is encrypted and uploaded to the cloud platform for centralized monitoring, and its hash value is also stored on the blockchain again, forming a complete audit record of the entire chain of "vulnerability discovery - analysis - remediation - verification".

[0093] The significance of this step lies in: achieving an "end-to-end closed loop" of security strategy, ensuring that remediation measures are truly implemented; improving operational transparency through verifiable feedback on installation results; and simultaneously, putting all key node data on the blockchain to build an immutable "digital evidence chain," providing a solid data foundation for quality traceability, compliance auditing, insurance claims, and incident investigation.

[0094] In some embodiments of this application, on the cloud platform, the integrity of the vulnerability report is verified by the hash digest of the vulnerability report according to the consensus algorithm; on the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch according to the consensus algorithm.

[0095] Traditional connected vehicle security systems generally rely on centralized servers or authoritative institutions as "trust anchors," such as OEMs unilaterally releasing vulnerability analysis results or OTA patches through their cloud platforms. This architecture presents a significant single point of failure risk: once the central server is controlled by an attacker, the attacker can forge vulnerability reports, generate malicious patches, and push them out on a large scale, leading to catastrophic consequences such as "supply chain attacks" or "fake official updates." Furthermore, due to the lack of multi-party verification mechanisms, vehicles cannot independently verify the authenticity of the data they receive and can only passively trust the central node, which severely weakens the overall security and credibility of the system.

[0096] This application's embodiment fundamentally changes this trust model by introducing blockchain consensus algorithms (such as PBFT, Raft, PoS, and other consensus mechanisms suitable for consortium blockchain scenarios). In this design, whether it's a cloud platform verifying a vulnerability report or an in-vehicle device verifying an OTA patch, the basis is no longer the statement of a single server, but rather the consensus result reached by multiple participating nodes in the blockchain network. Specifically:

[0097] When the cloud platform needs to verify a vulnerability report uploaded from the vehicle, it doesn't directly trust the data from the transmission channel or a single server. Instead, it sends a query request to the consortium blockchain network to obtain the on-chain record of the report's hash. Only when a majority of consensus nodes (such as OEMs, Tier 1 suppliers, regulatory agencies, and independent security auditors) confirm that the hash value has been correctly recorded and has not been tampered with, does the system consider the vulnerability report authentic and complete. This consensus-based verification mechanism effectively prevents data forgery caused by the compromise of individual nodes or malicious actions by insiders.

[0098] Similarly, when verifying the integrity of OTA patches on the vehicle side, the vehicle no longer relies on the "signature" provided by the OEM server as the sole means of verification. Instead, it actively connects to the vehicle-to-everything (V2X) consortium blockchain to query whether the patch hash has been confirmed and stored on the blockchain by the consensus network. If the hash value is not recognized by a majority of nodes, or if multiple conflicting versions exist, the vehicle will refuse to install it, even if the patch appears to come from an "official" channel. This mechanism achieves decentralized identity and content authentication, ensuring that even if an attacker compromises the OTA distribution server, they cannot bypass the collective supervision of the blockchain consensus network.

[0099] In some embodiments of this application, the process of obtaining the vehicle's in-vehicle software files and real-time data stream in step S110, performing dynamic and static vulnerability detection, and determining whether to trigger a vulnerability alarm event based on the vulnerability detection results includes, but is not limited to, the following steps.

[0100] Step S210: Obtain the vehicle software file, perform static vulnerability detection, match the vehicle software file with the preset vulnerability signature database, and determine whether the matching result triggers a vulnerability alarm event.

[0101] The in-vehicle software files include key configuration files and an in-vehicle software list.

[0102] In step S210, by comparing and analyzing the characteristics of known software components in the vehicle system, publicly disclosed or predefined security vulnerabilities are quickly identified. Specifically, the system actively collects key in-vehicle software files, including firmware images of each Electronic Control Unit (ECU), operating system core files, application executable files, system configuration files (such as permission settings and service startup items), and the Software Bill of Materials (SBOM). This information collectively constitutes a "digital profile" of the vehicle's current software environment. Subsequently, the system uses a pre-built vulnerability signature library—which typically contains software version numbers, file hash values, code snippet characteristics, or configuration defect patterns corresponding to known vulnerabilities (such as CVE numbers)—to perform high-speed matching of the aforementioned files. Once a known vulnerability is found in a file version, the system immediately classifies it as a high-confidence threat and triggers an alarm event. The advantages of this step are fast detection speed, low resource consumption, low false positive rate, and the ability to efficiently filter a large number of known risks, reducing the burden on subsequent dynamic detection. Its significance lies in enabling accurate identification and rapid response to "known threats," making it particularly suitable for scenarios such as reviewing vulnerabilities left over from OTA updates, security auditing of supply chain components, and compliance checks. It serves as the first line of defense in building a defense-in-depth system.

[0103] Step S220: Obtain the vehicle's CAN bus messages, Ethernet communication data, CPU and memory usage, and file read / write operation logs to form a multi-dimensional real-time data stream.

[0104] It should be noted that modern intelligent connected vehicles have a complex internal communication network architecture, including multiple bus protocols such as traditional Controller Area Network (CAN), high-speed in-vehicle Ethernet, LIN, and FlexRay, while running multiple operating systems and applications.

[0105] In step S220, in order to comprehensively perceive the real-time safety status of the vehicle, the system continuously monitors and collects data from different levels through T-BOX, domain controller, or dedicated security agent, as follows:

[0106] (1) CAN bus messages are used to record control commands and status feedback between ECUs, such as engine speed, brake signal, steering angle, etc. Their communication frequency, ID distribution, data field changes, etc. can reflect potential attack behaviors (such as forging brake commands).

[0107] (2) Ethernet communication data is used to capture TCP / IP traffic between high-performance modules such as intelligent cockpit and autonomous driving domain, and can be used to analyze application layer protocol anomalies, unauthorized access or malicious data injection.

[0108] (3) CPU and memory usage are used to monitor the resource usage of critical ECUs or vehicle computing platforms. Abnormal resource spikes may indicate mining programs, backdoor processes or denial-of-service attacks.

[0109] (4) File read and write operation logs are used to record access behavior to critical system directories (such as / etc, / boot, registry) through file system hooks, and to identify illegal modification, persistent implantation or ransomware activities.

[0110] By unifying the timestamps of these heterogeneous data sources and merging them, a high-dimensional, continuous real-time data stream is formed, providing a rich and comprehensive input foundation for subsequent AI model analysis. The significance of this step lies in breaking through the limitations of traditional single-dimensional monitoring, constructing a three-dimensional perception network covering the "network layer, system layer, and application layer." This makes it difficult for any hidden abnormal behavior to escape the system's monitoring scope, providing solid data support for achieving accurate dynamic vulnerability detection and attack chain reconstruction.

[0111] Step S230: Input the real-time data stream into the pre-trained anomaly detection model to perform dynamic vulnerability detection, obtain the anomaly detection result, and determine whether the anomaly detection result triggers a vulnerability alarm event.

[0112] In step S230, unlike static detection that relies on rule matching, this step employs an AI-based anomaly detection model (such as an autoencoder, Long Short-Term Memory network LSTM, Isolation Forest, or Graph Neural Network GNN). This model has been trained on a large amount of real or simulated vehicle operating data before deployment, learning and establishing a "normal behavior baseline" for the vehicle under normal operating conditions. When the real-time collected data stream is input into the model, the system evaluates the degree of deviation between the current behavior and the normal baseline. For example, the model might detect an ECU that should be communicating at low frequency suddenly sending specific CAN ID messages at high frequency, or a system process frequently calling sensitive system calls (such as execve) during non-startup phases, or abnormal fluctuations in memory usage patterns. Once the anomaly score output by the model exceeds a preset safety threshold, the system determines it as a potential security event and triggers a dynamic vulnerability alert.

[0113] In some embodiments of this application, the process of generating a structured vulnerability report based on vulnerability alert events in step S120 includes, but is not limited to, the following steps.

[0114] Step S310: Obtain the raw data of the vulnerability alert event.

[0115] The raw data includes alarm type, trigger time, detection source identifier, associated vehicle identification number, and vehicle operating status.

[0116] In step S310, when the vehicle-side system triggers an alarm during static or dynamic detection, the system immediately collects raw data related to the event from multiple dimensions. This data includes not only the alarm type (such as "CAN bus abnormal broadcast", "critical configuration file modified", "remote code execution feature matching", etc.), but also the trigger time (timestamp accurate to milliseconds, used for event sequencing and causal analysis), the detection source identifier (indicating which ECU, safety agent module, or detection algorithm triggered the alarm, such as "T-BOX IDS module" or "cockpit domain AI detection engine"), and the vehicle identification number (VIN, used to uniquely identify the vehicle involved and support cross-system tracking).

[0117] In addition, the system collects the vehicle's operating status at the time of the alarm, such as speed, gear, whether it is in autonomous driving mode, network connection status, and power mode. This contextual information is crucial for determining the severity of the vulnerability, the feasibility of the attack, and the scope of its impact. For example, an alarm triggered when the vehicle is stationary and the engine is off will have a significantly different risk level and response priority than an alarm triggered while the vehicle is traveling at high speed and in autonomous driving mode. By comprehensively collecting this raw data, this step ensures that the vulnerability report has sufficient detail to support subsequent intelligent analysis and decision-making, avoiding misjudgments or delayed responses due to missing information.

[0118] Step S320: Based on the preset report template, the raw data is structured and the vulnerability feature fields are extracted.

[0119] The vulnerability feature fields include vulnerability number, risk level, affected vehicle components, detection evidence hash value, alarm source identifier, and abnormal indicators.

[0120] In step S320, after acquiring the raw alarm data, it undergoes structured processing using a standardized report template. This transforms unstructured logs and event information into unified, parsable, and exchangeable structured fields, a crucial step in achieving automated security operations. The pre-defined report template defines the data architecture and semantic specifications for vulnerability reports, ensuring consistency across different vehicle models and detection modules. This facilitates aggregation analysis, machine learning modeling, and cross-vehicle comparison on the cloud platform. During this process, the system extracts key vulnerability feature fields from the raw data, as follows:

[0121] (1) Vulnerability ID: If a known CVE or internal vulnerability database entry is matched, a standard ID is assigned to facilitate association with historical data;

[0122] (2) Risk level: Based on CVSS (General Vulnerability Scoring System) or a custom scoring model, combined with factors such as vulnerability exploitation difficulty, impact scope, and vehicle operating status, the risk level is automatically assessed as "high risk", "medium risk" or "low risk".

[0123] (3) Affected vehicle components: Clearly indicate the specific ECU, software module or system function affected by the vulnerability (such as "BCM body control module" or "T-BOX communication firmware").

[0124] (4) Detect evidence hash value: perform hash calculation on the key log fragments or data packets that trigger the alarm for subsequent integrity verification;

[0125] (5) Alarm source identifier: Records the identity information of the detection module, supporting traceability and credibility assessment;

[0126] (6) Abnormal indicators: Parameters that quantify abnormal behavior, such as "CAN ID 0x2F1 transmission frequency exceeds threshold 300%" and "memory usage suddenly increases to 95% for 10 seconds".

[0127] Through structured processing, the system transforms messy raw data into machine-readable and semantically clear "security intelligence," greatly improving data processing efficiency and analysis accuracy, and laying a solid foundation for subsequent AI analysis, blockchain evidence storage, and cross-system collaboration.

[0128] Step S330: Call the blockchain smart contract interface to verify the vulnerability feature field with the vehicle baseline data stored on the chain, and generate a trusted data fragment containing a timestamp and digital signature.

[0129] In step S330, after completing the structured processing, the system does not directly generate a final report. Instead, it actively queries and verifies the vehicle's historical trusted data by calling the smart contract interface deployed on the consortium blockchain. "Vehicle baseline data" refers to core information such as software configuration, firmware version, and system fingerprints that are stored on the blockchain during vehicle manufacturing, OTA updates, or security audits. This data has immutability and timestamp attributes. By comparing the currently extracted vulnerability feature fields (such as the affected component version) with the on-chain baseline, the system can verify whether the vulnerability actually exists in the vehicle's current configuration, thereby eliminating false alarms caused by misreporting, data forgery, or environmental drift. For example, if an alarm claims that "ECU_A firmware has a CVE-2023-12345 vulnerability," but the on-chain baseline shows that the vehicle has never installed that firmware version, the system can determine that the alarm is invalid.

[0130] Based on this, the smart contract generates a "trusted data fragment" containing a timestamp and digital signature for the verification result. The timestamp ensures the traceability of the event sequence, while the digital signature (issued by the smart contract or a trusted node) proves the authenticity and integrity of the fragment. This mechanism not only enhances the authority of vulnerability reports but also establishes a strong binding relationship between "real-world events" and "trusted on-chain records," effectively preventing man-in-the-middle tampering or subsequent repudiation, and is a key guarantee for achieving judicial-grade auditability.

[0131] Step S340: Integrate vulnerability feature fields and trusted data fragments to generate a structured vulnerability report.

[0132] The vulnerability report includes a hash digest, the smart contract's storage address, and the specific original evidence data that triggered the vulnerability alert.

[0133] In step S340, the various information that has undergone structured processing and on-chain verification is integrated into a complete, authoritative, and traceable structured vulnerability report. This report not only includes the vulnerability characteristic fields extracted in the previous steps (such as vulnerability number, risk level, affected components, etc.), but also integrates "trusted data fragments" generated by smart contracts, thus forming a logically rigorous security event archive with a complete chain of evidence. Specifically, the report explicitly includes the following key information:

[0134] (1) Hash digest: A unique fingerprint obtained by calculating the entire report content using algorithms such as SHA-256, which is used for subsequent on-chain evidence storage and integrity verification;

[0135] (2) Smart contract storage address: Records the specific storage location of the report or its hash value on the blockchain (such as block height, transaction ID), so that any participant can query and verify it through the public interface;

[0136] (3) Specific original evidence data: Includes key logs, data packet screenshots, behavior sequences and other original evidence that triggered the alarm, supporting manual review and in-depth analysis.

[0137] This integration generates a vulnerability report that is not only a technical document but also a legally valid "digital evidence package." It supports multi-party collaborative review (such as OEM security teams, third-party auditing firms, and regulatory bodies) and can be used for incident investigations, liability determination, insurance claims, and compliance reporting. More importantly, the report's design ensures verifiability across the entire chain from "data collection" to "evidence solidification," truly achieving transparency, automation, and high credibility in the management of connected vehicle security incidents. This represents a significant technological practice in promoting the modernization of the intelligent connected vehicle security governance system.

[0138] In some embodiments of this application, in step S140, the process of verifying the integrity of the vulnerability report through the hash digest of the vulnerability report on the cloud platform, and calling the AI ​​analysis engine to associate the CVE database and threat intelligence to generate a remediation plan and store it on the blockchain includes, but is not limited to, the following steps.

[0139] Step S410: On the cloud platform, through the blockchain smart contract interface, query the hash digest of the vulnerability report stored on the consortium blockchain to verify the integrity of the vulnerability report.

[0140] In step S410, after the cloud platform receives the complete vulnerability report sent by the vehicle through an encrypted channel (such as HTTPS or MQTT over TLS), it does not directly trust its content. Instead, it immediately calls a pre-defined blockchain smart contract interface to proactively initiate a query request to the vehicle network consortium blockchain to obtain the original hash digest of the report, which was already stored on the blockchain when it was generated on the vehicle. Subsequently, the platform recalculates the hash value of the received full text of the report using the same hash algorithm (such as SHA-256) and compares the local calculation result with the on-chain query result. Only when the two are completely consistent does the system recognize the report as complete and authentic, allowing it to proceed to the next analysis step; if they are inconsistent, a security alarm is immediately triggered, the report is rejected, and a potential attack event is recorded. This mechanism fundamentally solves the trust deficiency of "the server is the truth" in traditional centralized systems, achieving end-to-end data tamper-proof verification. Even if attackers hijack the communication link or infiltrate some edge nodes, they cannot forge a valid vulnerability report, thus ensuring that the foundation of the entire security response system is not compromised.

[0141] Step S420: If the verification is successful, the AI ​​analysis engine is invoked to associate the CVE database and threat intelligence, generate a remediation plan, and upload it to the blockchain for evidence storage. This includes the following steps.

[0142] (1) Call the AI ​​analysis engine to perform in-depth analysis on the vulnerability feature fields in the vulnerability report and obtain the analysis results, including the vulnerability number, affected components and abnormal indicators corresponding to the vulnerability alarm event.

[0143] After confirming the authenticity and credibility of the vulnerability report, this step activates a cloud-based AI analysis engine to perform semantic-level deep analysis of the structured vulnerability feature fields in the report. This aims to quickly understand the essential attributes and contextual information of the vulnerability, providing accurate input for subsequent intelligent decision-making. AI analysis engines are typically built based on Natural Language Processing (NLP), Knowledge Graph, or rule-based reasoning models, and can automatically identify and extract key information, such as: Vulnerability ID: determining whether it is a known CVE, internal vulnerability ID, or unknown vulnerability (zero-day); Affected Components: accurately identifying the type of ECU where the vulnerability resides (e.g., ADAS domain controller, powertrain domain gateway), software module name, and version number; Anomaly Indicators: quantifying the dynamic characteristics of attack behavior, such as "CAN bus ID 0x1F0 transmission frequency abnormally increased by 300%" or "a process continuously calls mmap() system calls beyond the threshold."

[0144] The significance of this step lies in transforming raw structured data into machine-understandable "security semantics," enabling the system to automatically construct a "digital profile" of vulnerabilities and providing high-quality contextual input for subsequent threat matching, impact surface analysis, and remediation strategy generation. Through AI-automated parsing, the time cost of manually reading logs and extracting information is significantly reduced, resulting in a marked improvement in response efficiency. This is a crucial prerequisite for achieving intelligent security operations.

[0145] (2) Connect to the CVE database through the API interface and match the vulnerability details corresponding to the vulnerability number.

[0146] After obtaining the vulnerability ID, this step automatically queries the publicly available CVE database using standard API interfaces (such as NVD, MITRE CVE, vendor-owned vulnerability databases, etc.) to obtain detailed technical information about the vulnerability, including: vulnerability type (CWE classification), attack vector (AV), attack complexity (AC), permission requirements (PR), user interaction requirements (UI), scope of impact (CIA three-factor score), exploit availability, and public disclosure time. This information forms the basis of the CVSS (Common Vulnerability Scoring System) score and is the authoritative basis for assessing the severity of the vulnerability. For example, if a vulnerability has a CVSS score of 9.8 (severity level) and the attack vector is "remote network attack" without user interaction, it indicates that it has a high risk of remote exploitation.

[0147] This step aims to correlate local alerts detected on the vehicle with the external threat landscape, achieving a comprehensive upgrade in understanding from specific points to a broader picture. It not only helps the system quickly assess the prevalence and severity of vulnerabilities but also provides technical support for generating remediation recommendations (such as officially recommended patch versions and mitigation measures), avoiding reinventing the wheel and enhancing the professionalism and compliance of remediation solutions.

[0148] (3) By integrating real-time threat intelligence, the actual harm of vulnerability alert events is dynamically assessed to obtain dynamic harm levels.

[0149] While CVSS scores provide a static benchmark of vulnerability severity, they fail to reflect the actual exploitation risk in the real world. Therefore, this step introduces real-time threat intelligence for dynamic supplementation, enabling more accurate risk assessment. The system integrates with third-party threat intelligence platforms (such as Alienvault OTX, RecordedFuture, and FireEye iSIGHT) or industry-shared intelligence networks to obtain the latest dynamic information related to the vulnerability, such as: whether there is active in-the-wild exploitation; whether it is widely used by ransomware or APT groups; whether there are publicly available exploit kits or Proof-of-Concept (PoC) code; and whether related IP addresses, domains, or malware hashes are blacklisted.

[0150] Based on this intelligence, the AI ​​engine will weight and adjust the original CVSS score to generate a dynamic risk score. For example, a vulnerability with a CVSS score of 7.5 may have its dynamic risk score upgraded to "critical" if it has been frequently used by multiple APT groups recently; conversely, if there are no actual attack records for a long period, its risk score may be downgraded appropriately. The significance of this mechanism is to make risk assessments more closely reflect the real threat environment, avoid "theoretical discussions," support security teams in prioritizing high-risk events based on actual risks, optimize resource allocation, and improve overall defense efficiency.

[0151] (4) Based on the analysis results, vulnerability details, and dynamic severity level, generate a preliminary solution. The preliminary solution includes vulnerability cause analysis, temporary mitigation measures, and OTA patch development recommendations.

[0152] After completing multi-source information fusion and risk assessment, this step uses an AI analysis engine to automatically generate a preliminary remediation plan based on all input data, serving as an initial decision recommendation for security response. This plan comprises three core parts: First, vulnerability cause analysis: based on an AI inference model, it automatically summarizes the root causes of vulnerabilities, such as "outdated third-party open-source library versions," "incorrect permission configuration leading to privilege escalation," and "incomplete input validation causing buffer overflows." Second, temporary mitigation measures: before the official patch is released, it proposes immediately implementable emergency strategies, such as "closing unnecessary network ports," "limiting the communication frequency of specific ECUs," and "enabling firewall rules to block malicious IPs," to reduce the attack surface. Third, OTA patch development recommendations: clearly indicating which development team should be responsible, the software modules to be updated, the recommended remediation methods (such as code patches or configuration changes), and the official patch versions to be referenced, forming an executable work order.

[0153] The significance of this step lies in transforming complex, multi-dimensional analysis results into specific, actionable instructions, significantly shortening the time window from "problem discovery" to "solution formulation" and improving the automation level of security operations. Simultaneously, the preliminary solutions generated by AI provide a high-quality reference benchmark for subsequent manual review, reducing repetitive work.

[0154] (5) Prioritize and review the preliminary solutions based on the criticality level and repair complexity of the affected components, obtain the repair solutions and store them on the blockchain.

[0155] In this step, the system first prioritizes the preliminary solutions based on the criticality level of the affected components (e.g., braking system > steering system > cockpit entertainment system) and the complexity of the repair (e.g., whether it involves functional safety ASIL-D level modules or whether the whole vehicle needs to be shut down for upgrades), ensuring that high-risk vulnerabilities are dealt with first.

[0156] The solution is then automatically assigned to security experts or engineering teams in the relevant fields for manual review. The experts will review the AI's analysis conclusions, assess the side effects of the temporary measures, the compatibility and stability of the patches, and may optimize the solution (such as using hot patches instead of full upgrades to reduce risks).

[0157] The final confirmed remediation plan will generate a hash digest again and be stored on the blockchain via a smart contract, recording "who, when, and what remediation strategy was approved." This mechanism not only ensures the rigor of technical decisions and prevents system failures caused by AI misjudgments, but also enables traceability of responsibility through blockchain, providing an immutable chain of evidence for subsequent quality management, compliance audits, and incident accountability, truly realizing a new security governance model driven by both "intelligence" and "human."

[0158] In some embodiments of this application, the implementation process of developing an OTA patch based on the repair scheme, storing the hash digest of the OTA patch on the blockchain, and then pushing it to the vehicle in step S150 includes, but is not limited to, the following steps.

[0159] Step S510: Develop an OTA patch based on the repair plan and generate an OTA patch file to be pushed.

[0160] In step S510, the remediation plan generated and approved in the cloud is transformed into a deployable software update package. The remediation plan clearly identifies the affected vehicle components, the cause of the vulnerability, recommended remediation methods (such as code patching, configuration adjustments, or library version upgrades), and the responsible development entity. Based on this plan, the development team develops patches in a controlled and secure development environment, ensuring the patch logic is correct, highly compatible, and does not introduce new security risks. After patch development is complete, the system performs differential compilation or full packaging on the target ECU or software module, generating a standardized OTA patch file (such as an incremental differential package or a complete firmware image), along with metadata information (such as patch version number, applicable vehicle models, dependencies, signing certificate, etc.). This patch file is specifically designed to address a particular vulnerability, featuring minimal changes, high reliability, and verifiability. The significance of this step lies in the engineering implementation of the security strategy, serving as a bridge between "vulnerability analysis" and "endpoint remediation," ensuring the technical feasibility and accurate implementation of the remediation measures, and laying the foundation for subsequent secure distribution and trusted installation.

[0161] Step S520: Call the smart contract to upload the hash digest of the OTA patch file to the consortium blockchain to complete the notarization and generate a blockchain transaction record including the notarization timestamp.

[0162] In step S520, after the patch file is generated, the system first uses a cryptographic hash algorithm (such as SHA-256) to calculate its unique digest value, and then submits the hash value to the vehicle-to-everything (V2X) consortium blockchain network through a pre-defined blockchain smart contract interface. Once successfully uploaded to the blockchain, the system obtains an immutable record containing a notarization timestamp, transaction hash, block height, and multi-party consensus confirmation. This step has the following important significance: the on-chain hash becomes the standard for the patch, and any subsequent tampering will result in a local hash mismatch, thus being rejected by the vehicle; even if the OTA distribution server is compromised, attackers cannot forge a patch that can pass on-chain verification; OEMs, regulatory agencies, and third-party auditors can all query the patch release record through public interfaces to verify its legality; the notarization timestamp accurately records the moment the patch was released, which can be used for compliance reporting, accident investigation, and SLA assessment.

[0163] Step S530: The OTA patch file is encrypted and transmitted to the vehicle via the vehicle-to-everything (V2X) security communication protocol.

[0164] Among them, the vehicle end refers to the T-BOX terminal of the target vehicle.

[0165] In step S530, after the patch is notarized on the blockchain, the patch file is securely and reliably delivered to the target vehicle, ensuring a physical channel for remote repair. The system establishes an encrypted transmission channel using a dedicated secure communication protocol for vehicle networking (such as HTTPS based on TLS 1.3, MQTT over TLS, or a dedicated V2X security protocol) to ensure that the patch is not eavesdropped on, tampered with, or hijacked during over-the-air transmission. The patch file is typically also end-to-end encrypted before being sent (e.g., using the vehicle's public key for encryption), so even if the communication link is intercepted by a man-in-the-middle attack, the attacker cannot obtain the plaintext content.

[0166] The target node for transmission is the vehicle's T-BOX (Telematics Box) terminal. As a core communication module of the Internet of Vehicles (IoV), the T-BOX possesses security capabilities such as secure boot, a Trusted Execution Environment (TEE), and a Hardware Security Module (HSM), enabling it to securely receive, store, and subsequently verify patches. The significance of this step lies in constructing a "secure tunnel" from the cloud to the vehicle. Combined with an on-chain evidence storage mechanism, it achieves dual protection of "trustworthy content + confidential transmission," effectively resisting network layer attacks (such as MITM and DNS hijacking) and ensuring that patches remain intact and confidential until delivery.

[0167] Step S540: Monitor the transmission status in real time during the push process. If an interruption occurs, trigger the breakpoint resume mechanism to ensure that the OTA patch file is delivered completely.

[0168] In step S540, the system continuously monitors the transmission status during the push process, including indicators such as download progress, network latency, packet loss rate, and connection stability. Once a transmission interruption is detected (such as network disconnection, connection timeout, or verification failure), the system will not require the entire patch file to be downloaded again. Instead, it automatically triggers a resume from breakpoint mechanism, requesting only the incomplete data segment to continue transmission. This mechanism, based on HTTP Range requests or a dedicated chunking protocol, greatly saves communication resources and shortens update waiting time, making it particularly suitable for distributing large patches (such as autonomous driving system upgrade packages) on low-bandwidth or high-latency networks. Furthermore, the system may combine multipath transmission and redundant coding technologies to further improve reliability. The core significance of this step lies in improving the robustness and success rate of OTA updates, avoiding update failures or prolonged vehicle offline times due to network fluctuations, ensuring normal user operation and timely security repairs. It is a key technical link in achieving large-scale, high-concurrency, stable, and reliable OTA operation.

[0169] In some embodiments of this application, in step S160, on the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch, the OTA patch is installed, an installation result report is generated, and the report is fed back to the cloud platform and stored on the blockchain. The implementation process includes, but is not limited to, the following steps.

[0170] Step S610: After receiving the OTA patch file, verify the integrity of the OTA patch through the hash digest of the OTA patch.

[0171] In step S610, after receiving the OTA patch file, the vehicle's T-BOX terminal does not immediately execute the installation. Instead, it first queries the official hash digest corresponding to the patch from the consortium blockchain via the blockchain smart contract interface (this digest has been stored on the blockchain in the cloud in step S520). Subsequently, the vehicle terminal recalculates the hash value of the locally received patch file using the same hash algorithm (such as SHA-256) and compares the local result with the on-chain query result. Only when the two are completely consistent does the system determine that the patch is complete and trustworthy, allowing it to proceed to the subsequent installation process; otherwise, the system will refuse installation, record the security event, and report the anomaly. This mechanism breaks through the traditional single verification mode that relies on the digital signature of a central server, introducing a decentralized blockchain as a "trust anchor," so that even if the OEM's OTA server is compromised, attackers cannot forge a patch that can be verified on the blockchain. The significance of this step is that it enables the vehicle terminal to independently and verifiably judge the source and content of the patch, builds an active defense capability on the terminal side, and greatly improves the security and autonomous controllability of the vehicle software update.

[0172] Step S620: If the verification is successful, start the vehicle-side secure execution environment and perform OTA patch file decompression, verification and system integration according to the preset installation process.

[0173] In step S620, after confirming the integrity of the patch, the actual installation and execution phase begins. Its core function is to ensure the patch is securely deployed in a controlled and trusted environment, preventing interference or hijacking of the installation process. The system first activates the vehicle-side Secure Execution Environment (SEA). This environment is typically built upon a Hardware Security Module (HSM), Trusted Platform Module (TPM), or Trusted Execution Environment (TEE), possessing isolation, tamper resistance, and key protection capabilities, enabling secure handling of sensitive operations (such as key decryption and firmware writing). Within this secure environment, the system executes the pre-defined standardized installation process sequentially:

[0174] (1) Decompression: Decrypt and decompress the encrypted or compressed patch package to restore the original file structure;

[0175] (2) Secondary verification: Verify the digital signature, version number and dependencies of the patch file again in a secure environment to ensure compatibility with the target ECU;

[0176] (3) System integration: Write the new firmware to the specified storage area (such as Flash or eMMC), update the boot configuration, and back up the old version for rollback.

[0177] The entire process takes place in a protected memory space, preventing malicious processes from eavesdropping or tampering with it. The significance of this step lies in upgrading patch installation from a "normal system operation" to a "high-security trusted operation," ensuring that the repair process itself cannot be exploited by attackers, and providing a fundamental guarantee for safe and reliable vehicle software upgrades.

[0178] Step S630: After installation, generate an installation result report, send it to the cloud platform, and update the vulnerability remediation status dashboard.

[0179] The installation result report includes the installation time, patch version, vehicle identification number, and execution status.

[0180] In step S630, the repair results from the terminal are synchronized to the cloud in real time, supporting centralized monitoring, statistical analysis, and operational decision-making. After the patch is successfully installed, the vehicle-side system automatically generates a structured installation result report, including key fields: Installation Time: Accurately records the moment the patch takes effect, used to assess response timeliness; Patch Version: Confirms the installed patch number to prevent version mismatch; Vehicle Identification Number (VIN): Uniquely identifies the executing vehicle, supporting individual tracking; Execution Status: Indicates results such as "success," "failure," and "rollback," and includes error codes or log summaries.

[0181] After the report is uploaded to the cloud platform via an encrypted channel, the system automatically updates the vulnerability remediation status dashboard, displaying in real time the remediation progress, success rate, and remaining risks for each vehicle model, region, and vulnerability. For example, the security operations team can intuitively see that "CVE-2023-XXXX vulnerability has been patched on 95% of vehicles, and the remaining 5% are awaiting retry due to network issues." The significance of this mechanism lies in achieving a leap from "single-vehicle remediation" to "global governance," supporting refined security management for large-scale fleets, improving operational efficiency, and providing data support for compliance audits, insurance assessments, and product iterations.

[0182] Step S640: Based on the installation result report, extract the corresponding hash digest and store it on the blockchain.

[0183] In step S640, after receiving the installation result report in the cloud, the system immediately calculates its hash digest and uploads it to the consortium blockchain for notarization via a smart contract. This operation has multiple profound implications: from "vulnerability discovery → report on the blockchain → remediation plan on the blockchain → patch on the blockchain → installation result on the blockchain," all key nodes are recorded, forming a complete, time-ordered, and undeniable security event chain; if a security incident occurs subsequently, the on-chain records can prove whether a vehicle has installed the specified patch, clarifying the boundaries of responsibility for OEMs, suppliers, or vehicle owners; it meets the mandatory requirements of "security event record retention" in automotive functional safety and cybersecurity regulations such as ISO / SAE 21434 and UN R155; all participants (including regulatory agencies, insurance companies, and third-party auditors) can independently verify the remediation results, enhancing the trust level of the entire ecosystem.

[0184] Through this step, this application not only achieves technical vulnerability repair, but also completes the "evidence loop" at the legal and governance levels. It is a key design to promote the intelligent connected vehicle safety system to a new era of high credibility, regulatory oversight, and accountability.

[0185] In summary, the blockchain-based vehicle network vulnerability management method provided in this application has the following technical effects.

[0186] This method, through the deep integration of artificial intelligence and blockchain technology, constructs a trusted, intelligent, and closed-loop management system covering the entire lifecycle of vulnerabilities, significantly improving the credibility, transparency, and automation level of vehicle-to-everything (V2X) security. At the vehicle end, it employs a dynamic and static combined AI detection mechanism to proactively discover known and unknown vulnerabilities. In the cloud, an AI analysis engine connects the CVE database and threat intelligence to intelligently generate remediation solutions. Utilizing the immutability and consensus mechanism of a consortium blockchain, key data such as vulnerability reports, remediation solutions, OTA patches, and installation results are hashed and stored on the blockchain, forming a complete digital evidence chain from "discovery—analysis—remediation—verification," achieving an end-to-end security closed loop. This system not only effectively prevents data tampering, supply chain attacks, and malicious updates, but also constructs a multi-party governance trust model through a decentralized consensus verification mechanism, enhancing the system's anti-attack capabilities and auditability.

[0187] Furthermore, this method effectively improves security response efficiency and operational intelligence, achieving a leap from "passive response" to "proactive defense, intelligent decision-making, and reliable execution." Through reliable installation and breakpoint resumption mechanisms within the vehicle-side security environment, the integrity and high availability of OTA updates are ensured; real-time feedback of installation results and blockchain evidence support visualized monitoring and accountability for global repair status. The entire solution meets the stringent requirements of cybersecurity management, providing solid technical support for the secure operation of intelligent connected vehicles in complex network environments, and promoting a comprehensive upgrade of the vehicle network security governance system towards trustworthiness, automation, and compliance.

[0188] Secondly, refer to Figure 2 This application provides a blockchain-based vehicle network vulnerability management system, including a vulnerability alarm triggering module 710, a vulnerability report on-chain evidence storage module 720, a remediation solution on-chain evidence storage module 730, an OTA patch on-chain evidence storage module 740, and an OTA patch verification and installation module 750.

[0189] The vulnerability alarm triggering module 710 is used to acquire the vehicle's in-vehicle software files and real-time data streams, perform dynamic and static vulnerability detection, and determine whether to trigger a vulnerability alarm event based on the vulnerability detection results.

[0190] The vulnerability report on-chain evidence storage module 720 is used to generate structured vulnerability reports based on vulnerability alert events. It stores the hash digest of the vulnerability report on the blockchain and then encrypts and transmits the vulnerability report to the cloud platform. On-chain evidence storage refers to the process of uploading the report to the consortium blockchain via a smart contract to complete the evidence storage.

[0191] The 730 remediation solution on-chain evidence storage module is used on the cloud platform to verify the integrity of the vulnerability report through the hash digest of the vulnerability report, and call the AI ​​analysis engine to associate the CVE database and threat intelligence to generate a remediation solution and store it on the blockchain.

[0192] The OTA patch on-chain notarization module 740 is used to develop OTA patches based on the repair scheme, and push the hash digest of the OTA patch on the blockchain for notarization to the vehicle.

[0193] The OTA patch verification and installation module 750 is used on the vehicle side to verify the integrity of the OTA patch through the hash digest of the OTA patch, execute the installation of the OTA patch, generate an installation result report, and feed it back to the cloud platform and on-chain evidence storage.

[0194] Furthermore, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned blockchain-based vehicle network vulnerability management method.

[0195] Furthermore, embodiments of this application provide a computer storage medium including a computer program, which, when executed by a processor, implements the aforementioned blockchain-based vehicle network vulnerability management method.

[0196] Similarly, the technical effects of the system, device and medium provided in the embodiments of this application are the same as the technical effects of the above method embodiments, and will not be repeated here.

[0197] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0198] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0199] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0200] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0201] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable programs for implementing logical functions, and can be specifically implemented in any computer-readable medium for program execution systems, apparatuses, or devices (such as computer-based systems, including processors).

[0202] The computer-readable medium may be used by or in connection with a program execution system, apparatus, or device (or other system that can retrieve and execute a program from or in connection with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" may be any means that can contain, store, communicate, propagate, or transmit a program for use by or in connection with a program execution system, apparatus, or device.

[0203] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or, if necessary, processing in a suitable manner, and then stored in computer memory.

[0204] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0205] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0206] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0207] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A blockchain-based method for managing vulnerabilities in the Internet of Vehicles (IoV), characterized in that: Includes the following steps: The process involves acquiring the vehicle's onboard software files and real-time data streams, performing dynamic and static vulnerability detection, and determining whether to trigger a vulnerability alert based on the detection results. This includes the following steps: The vehicle software file is obtained, static vulnerability detection is performed, the vehicle software file is matched with a preset vulnerability signature database, and it is determined whether the matching result triggers a vulnerability alarm event; the vehicle software file includes key configuration files and a vehicle software list; The system acquires the vehicle's CAN bus messages, Ethernet communication data, CPU and memory usage, and file read / write operation logs to form a multi-dimensional real-time data stream. The real-time data stream is input into a pre-trained anomaly detection model to perform dynamic vulnerability detection, obtain anomaly detection results, and determine whether the anomaly detection results trigger a vulnerability alarm event. Generate a structured vulnerability report based on the vulnerability alert events; The hash digest of the vulnerability report is uploaded to the blockchain for evidence storage, and the vulnerability report is encrypted and transmitted to the cloud platform; the on-chain evidence storage refers to uploading to the consortium blockchain through a smart contract to complete the evidence storage; On the cloud platform, the integrity of the vulnerability report is verified by the hash digest of the vulnerability report, and the AI ​​analysis engine is invoked to associate the CVE database and threat intelligence to generate a remediation plan and store it on the blockchain. An OTA patch is developed based on the aforementioned repair scheme. After the hash digest of the OTA patch is stored on the blockchain and then pushed to the vehicle, the process includes the following steps: OTA patch development is carried out based on the aforementioned repair scheme, generating OTA patch files to be pushed. The smart contract is invoked to upload the hash digest of the OTA patch file to the consortium blockchain to complete the notarization, and a blockchain transaction record including the notarization timestamp is generated; The OTA patch file is encrypted and transmitted to the vehicle via a vehicle-to-everything (V2X) secure communication protocol. The vehicle terminal refers to the T-BOX terminal of the target vehicle. The transmission status is monitored in real time during the push process. If an interruption occurs, the breakpoint resume mechanism is triggered to ensure that the OTA patch file is delivered completely. On the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch, the OTA patch is installed, an installation result report is generated, and the report is sent back to the cloud platform and stored on the blockchain. The process of installing the OTA patch includes: If the integrity verification of the OTA patch passes, the vehicle-side secure execution environment is started, and the OTA patch file is decompressed, verified, and integrated into the system according to the preset installation process. The secure execution environment is built based on a hardware security module, a trusted platform module, or a trusted execution environment, and is used to isolate sensitive operations.

2. The blockchain-based vehicle network vulnerability management method according to claim 1, characterized in that, The process of generating a structured vulnerability report based on the vulnerability alert event includes the following steps: Obtain the raw data of the vulnerability alert event; The raw data includes alarm type, trigger time, detection source identifier, associated vehicle identification number, and vehicle operating status; The raw data is structured based on a preset report template to extract vulnerability feature fields; The vulnerability feature fields include vulnerability number, risk level, affected vehicle components, detection evidence hash value, alarm source identifier, and abnormal indicators; The blockchain smart contract interface is invoked to correlate and verify the vulnerability feature fields with the vehicle baseline data stored on the chain, generating a trusted data fragment containing a timestamp and digital signature. Integrate the vulnerability feature fields with trusted data fragments to generate a structured vulnerability report; The vulnerability report includes a hash digest, a smart contract storage address, and specific original evidence data that triggered the vulnerability alert event.

3. The blockchain-based vehicle network vulnerability management method according to claim 1, characterized in that, The cloud platform verifies the integrity of the vulnerability report using its hash digest, and uses an AI analysis engine to correlate the CVE database with threat intelligence to generate a remediation plan and store it on the blockchain, including the following steps: On the cloud platform, the completeness of the vulnerability report is verified by querying the hash digest of the vulnerability report stored on the consortium blockchain through the blockchain smart contract interface. If the verification passes, the AI ​​analysis engine is invoked to access the associated CVE database and the threat intelligence to generate the remediation plan, which is then stored on the blockchain for verification. Specifically, this includes: The AI ​​analysis engine is invoked to perform in-depth analysis on the vulnerability feature fields in the vulnerability report, and the analysis results are obtained, including the vulnerability number, affected components and abnormal indicators corresponding to the vulnerability alarm event. By connecting to the CVE database through the API interface, the vulnerability details corresponding to the vulnerability number are matched; By integrating the real-time threat intelligence, the actual severity of the vulnerability alert event is dynamically assessed to obtain a dynamic severity level; Based on the analysis results, the vulnerability details, and the dynamic severity level, a preliminary solution is generated. The preliminary plan includes vulnerability cause analysis, temporary mitigation measures, and OTA patch development recommendations; Based on the criticality level and repair complexity of the affected components, the preliminary solutions are prioritized and reviewed to obtain the repair solutions, which are then stored on the blockchain for evidence.

4. The blockchain-based vehicle network vulnerability management method according to claim 1, characterized in that, On the vehicle side, the integrity of the OTA patch is verified through its hash digest, the OTA patch is installed, an installation result report is generated, and the report is sent back to the cloud platform and stored on the blockchain. This process includes the following steps: After receiving the OTA patch file, the integrity of the OTA patch is verified by the hash digest of the OTA patch; If the verification is successful, the vehicle-side secure execution environment is started, and the OTA patch file is decompressed, verified, and integrated into the system according to the preset installation process; After installation, the installation result report is generated and sent to the cloud platform to update the vulnerability remediation status dashboard. The installation result report includes the installation time, patch version, vehicle identification number, and execution status. Based on the installation result report, the corresponding hash digest is extracted and stored on the blockchain.

5. The blockchain-based vehicle network vulnerability management method according to claim 1, characterized in that, On the cloud platform, the integrity of the vulnerability report is verified by using the hash digest of the vulnerability report according to the consensus algorithm; On the vehicle side, the integrity of the OTA patch is verified by the hash digest of the OTA patch according to the consensus algorithm.

6. A blockchain-based vehicle network vulnerability management system, characterized in that, This includes a vulnerability alert triggering module, a vulnerability report on-chain evidence storage module, a remediation solution on-chain evidence storage module, an OTA patch on-chain evidence storage module, and an OTA patch verification and installation module; The vulnerability alert triggering module is used to acquire the vehicle's in-vehicle software files and real-time data streams, perform dynamic and static vulnerability detection, and determine whether to trigger a vulnerability alert event based on the vulnerability detection results, including the following steps: The vehicle software file is obtained, static vulnerability detection is performed, the vehicle software file is matched with a preset vulnerability signature database, and it is determined whether the matching result triggers a vulnerability alarm event; the vehicle software file includes key configuration files and a vehicle software list; The system acquires the vehicle's CAN bus messages, Ethernet communication data, CPU and memory usage, and file read / write operation logs to form a multi-dimensional real-time data stream. The real-time data stream is input into a pre-trained anomaly detection model to perform dynamic vulnerability detection, obtain anomaly detection results, and determine whether the anomaly detection results trigger a vulnerability alarm event. The vulnerability report on-chain evidence storage module is used to generate a structured vulnerability report based on the vulnerability alert event; store the hash digest of the vulnerability report on the blockchain for evidence storage, and encrypt and transmit the vulnerability report to the cloud platform; the on-chain evidence storage refers to uploading to the consortium blockchain through a smart contract to complete the evidence storage; The on-chain evidence storage module for the remediation solution is used on the cloud platform to verify the integrity of the vulnerability report through the hash digest of the vulnerability report, and to call the AI ​​analysis engine to associate the CVE database and threat intelligence to generate a remediation solution and store it on the blockchain. The OTA patch on-chain notarization module is used to develop an OTA patch based on the repair scheme, and push the hash digest of the OTA patch on-chain notarization to the vehicle, including the following steps: OTA patch development is carried out based on the aforementioned repair scheme, generating OTA patch files to be pushed. The smart contract is invoked to upload the hash digest of the OTA patch file to the consortium blockchain to complete the notarization, and a blockchain transaction record including the notarization timestamp is generated; The OTA patch file is encrypted and transmitted to the vehicle via a vehicle-to-everything (V2X) secure communication protocol. The vehicle terminal refers to the T-BOX terminal of the target vehicle. The transmission status is monitored in real time during the push process. If an interruption occurs, the breakpoint resume mechanism is triggered to ensure that the OTA patch file is delivered completely. The OTA patch verification and installation module is used on the vehicle to verify the integrity of the OTA patch through the hash digest of the OTA patch, execute the installation of the OTA patch, generate an installation result report, and feed it back to the cloud platform and on-chain evidence storage. The process of installing the OTA patch includes: If the integrity verification of the OTA patch passes, the vehicle-side secure execution environment is started, and the OTA patch file is decompressed, verified, and integrated into the system according to the preset installation process. The secure execution environment is built based on a hardware security module, a trusted platform module, or a trusted execution environment, and is used to isolate sensitive operations.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the blockchain-based vehicle network vulnerability management method as described in any one of claims 1 to 5.

8. A computer storage medium comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the blockchain-based vehicle network vulnerability management method as described in any one of claims 1 to 5.

Images