Vehicle-mounted operating system vulnerability detection method and electronic device

Abstract

The application provides a vehicle-mounted operating system vulnerability detection method and electronic equipment. The method comprises the following steps: obtaining each original vulnerability sample data in a vehicle networking product security vulnerability professional library and an operating system vulnerability dataset; splitting a vulnerability code segment to obtain each vulnerability code block; using a large language model to perform information extraction to obtain code function semantic information and vulnerability cause information; encapsulating each information to obtain a structured knowledge item; storing to a knowledge base and establishing an index to obtain a searchable vulnerability knowledge base; retrieving the vulnerability knowledge base based on to-be-detected function semantic information to obtain a candidate knowledge list; using the large language model to perform reasoning and judgment on the candidate knowledge list to obtain a detection result for vehicle-mounted operating system vulnerability detection. The application can effectively solve the problems of the prior art, such as difficulty in finding complex semantic vulnerabilities, low detection efficiency, susceptibility to false positives and false negatives, and the need for manual definition of rules and review.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a method for detecting vulnerabilities in an in-vehicle operating system and an electronic device. Background Technology

[0002] Currently, developing intelligent and connected vehicles is the main development trend and an essential step towards autonomous driving. The security of in-vehicle operating systems, especially those running on key modules such as the telematics box (T-BOX) and vehicle infotainment system in intelligent connected vehicles, is directly related to driving safety and the security of vehicle network information.

[0003] Existing methods for detecting vulnerabilities in in-vehicle operating systems mainly rely on traditional static analysis and penetration testing. However, these methods often suffer from difficulties in discovering complex semantic vulnerabilities, low detection efficiency, susceptibility to false positives and false negatives, and the need for manual rule definition and verification. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method and electronic device for detecting vulnerabilities in an in-vehicle operating system, so as to eliminate or improve one or more defects existing in the prior art.

[0005] The first aspect of this application provides a method for detecting vulnerabilities in an in-vehicle operating system, the method comprising: The process involves acquiring raw vulnerability sample data from a professional database of security vulnerabilities in connected vehicle products and a dataset of vulnerabilities in operating systems; wherein the vulnerability sample data includes vulnerable code segments; splitting the vulnerable code segments to obtain individual vulnerable code blocks; using a large language model to extract information based on the vulnerability sample data and the vulnerable code blocks to obtain code functional semantic information and vulnerability cause information; encapsulating the vulnerability sample data, the vulnerable code blocks, the code functional semantic information, and the vulnerability cause information to obtain structured knowledge entries; and storing each knowledge entry in a knowledge base and establishing an index to obtain a searchable vulnerability knowledge base. The vulnerability knowledge base is retrieved based on the semantic information of the function to be detected to obtain a candidate knowledge list; the candidate knowledge list is then inferred and judged using a large language model to obtain the detection results for vehicle operating system vulnerability detection.

[0006] In some embodiments of this application, the step of using a large language model to extract information based on the vulnerability sample data and the vulnerability code block to obtain code functional semantic information and vulnerability cause information includes: A large language model is used to extract semantic information from each of the aforementioned vulnerable code blocks to obtain the semantic information of the code functions; The vulnerability cause analysis is performed using a large language model combined with the vulnerability sample data and the vulnerability code block to obtain vulnerability cause information. The vulnerability sample data also includes vulnerability number, vulnerability description information and remediation code segment. The vulnerability cause information includes abstract vulnerability description information, triggering action information and remediation scheme information.

[0007] In some embodiments of this application, the mapping data, and the step of using a large language model to perform semantic extraction on each of the vulnerable code blocks to obtain code functional semantic information, include: Construct a first cue word to enable the large language model to generate abstract purpose information for the vulnerable code block; Construct a second cue word to enable the large language model to generate detailed behavioral information describing the vulnerable code block; The abstract purpose information and detailed behavioral information generated by the large language model are used as the semantic information of the code function.

[0008] In some embodiments of this application, the step of using a large language model to combine the vulnerability sample data and the vulnerability code block for vulnerability cause analysis includes: A first-round vulnerability analysis hint word is constructed, which includes the vulnerable code block, the repair code segment, and the vulnerability description, so that the large language model generates the repair code explanation information corresponding to the repair code segment, and the first-round output result is obtained. Based on the first round of output results, a second round of vulnerability analysis hints are constructed to enable the large language model to generate a remediation method for the vulnerability code block, resulting in a second round of output results in a structured format; wherein, the second round of output results includes the abstract vulnerability description information, the triggering action information, and the remediation scheme information; Based on the output results of the second round, construct vulnerability cause verification prompts, verify and improve the output results of the second round.

[0009] In some embodiments of this application, before retrieving the vulnerability knowledge base based on the functional semantic information to be detected to obtain a candidate knowledge list, the method further includes: Obtain the source code of the vehicle operating system to be tested, and split the source code to obtain the individual function code blocks to be tested; The large language model is used to extract semantics from each of the code blocks of the function to be detected, so as to obtain the semantic information of the function to be detected corresponding to each of the code blocks of the function to be detected.

[0010] In some embodiments of this application, the step of retrieving the vulnerability knowledge base based on the functional semantic information to be detected to obtain a candidate knowledge list includes: The functional semantic information to be detected is input into the vulnerability knowledge base as query information to obtain various query results; wherein, the functional semantic information includes code snippet text, abstract purpose information, and detailed behavior information; The similarity scores of each query result are calculated and sorted to obtain a list of search results corresponding to the code snippet text, the abstract purpose information, and the detailed behavior information, respectively. A preset number of the query results are selected in descending order of the similarity score, and these are used as the original knowledge lists corresponding to each of the search result lists. The knowledge entries in each of the original knowledge lists are merged and reordered to obtain a candidate knowledge list.

[0011] In some embodiments of this application, the merging and reordering of the knowledge entries in the respective original knowledge lists includes: Merge the original knowledge lists and remove duplicates based on the unique identifier of each knowledge entry; A fusion score is calculated based on the similarity score corresponding to each of the aforementioned knowledge items. A preset number of knowledge items are selected in descending order of the fusion scores.

[0012] In some embodiments of this application, the reasoning and judgment using the candidate knowledge list of the large language model includes: For each knowledge entry in the candidate knowledge list, the knowledge entry and the corresponding function code block to be detected are combined to construct the prompt word corresponding to the knowledge entry, so that the large language model can perform chain reasoning and obtain the reasoning result. If the reasoning result corresponding to any of the knowledge entries indicates the existence of a vulnerability, then the subsequent judgment is terminated, and the detection result and vulnerability information corresponding to the reasoning result are output.

[0013] The second aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the vehicle operating system vulnerability detection method described in the first aspect above.

[0014] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the vehicle operating system vulnerability detection method described in the first aspect above.

[0015] The fourth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the vehicle operating system vulnerability detection method described in the first aspect above.

[0016] This application provides a method for detecting vulnerabilities in an in-vehicle operating system. The method includes: acquiring various original vulnerability sample data from a professional database of security vulnerabilities in connected vehicle products and a dataset of vulnerabilities in operating systems; wherein, the vulnerability sample data includes vulnerable code segments; splitting the vulnerable code segments to obtain various vulnerable code blocks; using a large language model to extract information based on the vulnerability sample data and the vulnerable code blocks to obtain code functional semantic information and vulnerability cause information; encapsulating the vulnerability sample data, the vulnerable code blocks, the code functional semantic information, and the vulnerability cause information to obtain structured knowledge entries; storing each knowledge entry in a knowledge base and establishing an index to obtain a searchable vulnerability knowledge base; retrieving the vulnerability knowledge base based on the functional semantic information to be detected to obtain a candidate knowledge list; and using a large language model to reason and judge the candidate knowledge list to obtain a detection result for detecting vulnerabilities in an in-vehicle operating system. By designing an in-vehicle vulnerability knowledge base construction system, and introducing repair code segments and vulnerability description information, the system enables the use of existing vulnerability case knowledge for auxiliary analysis during the retrieval phase. Through external access to a dedicated vulnerability database related to in-vehicle operating systems, knowledge updates can be achieved to optimize detection results. By converting knowledge entries into vulnerability knowledge containing functional semantics, triggering conditions, and remediation solutions and storing them in the vulnerability knowledge base, and using the constructed vulnerability knowledge base for subsequent vulnerability detection, the accuracy and interpretability of in-vehicle operating system vulnerability detection can be improved.

[0017] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0018] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a method for detecting vulnerabilities in an in-vehicle operating system according to one embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating the search enhancement generation technique in an application example of this application.

[0021] Figure 3 This is a schematic diagram of the architecture of the vulnerability knowledge base construction system in an application example of this application.

[0022] Figure 4 This is a schematic diagram of the architecture of an in-vehicle operating system vulnerability detection system in an application example of this application.

[0023] Figure 5 This is a flowchart illustrating the process of building a vulnerability knowledge base for an application example of this application.

[0024] Figure 6 This is a flowchart illustrating the in-vehicle operating system vulnerability detection system in an application example of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0026] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0027] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0028] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0029] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0030] In operating system security research, key technologies include secure boot mechanisms, access control technologies, vulnerability detection and protection technologies, and security audit mechanisms. Specifically, the secure boot mechanism, as the system's root of trust, ensures that all stages of the operating system, from boot loading to kernel initialization, are trusted components, preventing malicious bootloaders or tampered firmware from loading, thus guaranteeing system integrity from the source. Combined with trusted computing modules, it enhances the metric chain and hardware-level trust, further improving the security of the boot process. Access control technologies include discretionary access control, mandatory access control, and role-based access control mechanisms, used to restrict the operational permissions of processes and users on system resources (such as files, memory, and devices) to prevent malicious actors from abusing resources. Vulnerability detection and protection technologies are crucial for improving the operating system's resistance to attacks. Traditional static analysis, symbolic execution, and dynamic taint tracking methods are used to identify potential defects during software development, while the deployment phase relies on mitigation mechanisms such as address space layout randomization, stack protection, and system call restrictions to reduce the risk of vulnerability exploitation. Security audit mechanisms support the full lifecycle recording of critical behaviors and security events, providing fundamental data support for later fault location and attack tracing. Combined with anomaly detection methods based on behavioral pattern recognition and machine learning, it is possible to dynamically identify and respond to zero-day attacks and covert intrusion behaviors.

[0031] Current mainstream vulnerability detection technologies can be categorized into several types, including static analysis, dynamic analysis, software component analysis, and signature matching detection. Different methods are suitable for different vulnerability detection scenarios, as detailed below: Static analysis: This method uses white-box testing to examine the application's source code or binary code during the development phase to identify security vulnerabilities. Static analysis is suitable for scenarios such as source code auditing, and can discover issues such as missing input validation and access control vulnerabilities without running the program. The advantages of static analysis are its ability to promptly and comprehensively examine code structure and logic, and to quickly locate potential vulnerabilities. The disadvantages are its reliance on code visibility and rule bases, the need for separate support for different programming languages, and the difficulty in determining the actual exploitability of detected vulnerabilities.

[0032] Dynamic analysis: This method employs black-box testing, simulating attacker behavior to test the system during application runtime. Dynamic analysis is commonly used for vulnerability scanning of running systems or network interfaces, determining the existence of vulnerabilities by sending malicious input and observing the responses. The advantages of dynamic analysis are that it operates from an attacker's perspective, uncovering high-risk security issues during operation, and it allows testing of applications, interfaces, and even the entire vehicle network without requiring source code. The disadvantages are that the test coverage is limited by the exploration strategy, potentially missing complex interactions.

[0033] Software composition analysis: This involves analyzing the components and dependencies of software to identify third-party components and their known vulnerabilities. Applications of software composition analysis include component dependency security analysis and supply chain security analysis, such as generating a software bill of materials and comparing it with vulnerability information for corresponding component versions in publicly available vulnerability databases. This method can accurately identify known vulnerabilities in a system and suggest version upgrades or patching measures. Software composition analysis is fast and has broad coverage, but it can only detect publicly disclosed vulnerabilities and cannot detect closed-source custom components or unknown vulnerabilities.

[0034] Signature matching detection: This method uses a predefined vulnerability signature library to perform pattern matching on the code or binary code of a target system to quickly locate known vulnerabilities. The advantages of signature matching detection are fast scanning speed and high accuracy in identifying known vulnerabilities; the disadvantage is that it can only discover known vulnerabilities with patterns already existing in the signature library, and cannot identify new variants or completely unknown zero-day vulnerabilities. Therefore, signature matching is mostly used for basic rapid screening and needs to be combined with other techniques to cover unknown threats.

[0035] Operating system vulnerability detection based on vulnerability databases typically employs static analysis methods. Traditional static analysis methods are based on syntax rules, control flow, and data flow analysis, identifying typical vulnerabilities such as memory access violations, unvalidated input, and privilege escalation through pattern matching or symbolic execution. These methods are relatively mature in industry and suitable for large-scale source code audits and compliance testing, especially for discovering common coding defects in operating system kernels and driver-level modules. However, their main limitation lies in their reliance on manually defined rules, making it difficult to cover system differences across different versions and vendors. When vulnerabilities appear as logical variations, semantic rewrites, or structural reconstructions, traditional matching methods struggle to capture their deep commonalities, easily leading to missed detections.

[0036] To overcome the limitations of static rule-based detection, researchers have introduced deep learning methods. By inputting vulnerable code and patched code into a neural network model, semantic feature vectors are extracted, enabling automatic learning and generalization of vulnerability and patch patterns. This type of method can understand code context to some extent, identify vulnerability variants with similar structures but different syntaxes, and improve detection accuracy. Its drawbacks include reliance on a large number of labeled samples, resulting in low model interpretability; furthermore, for highly customized environments such as automotive operating systems, sample scarcity and domain differences can reduce model transfer performance.

[0037] With the development of large language models, code semantic detection based on large language models has emerged. These methods leverage the cross-language understanding capabilities of pre-trained models to perform natural language-like reasoning on source code, directly identifying potential vulnerabilities and generating causal explanations and remediation suggestions. Large language models have significant advantages in cross-project and cross-semantic detection, capable of capturing logical vulnerabilities that traditional models struggle to abstract. However, large language models lack the constraints of domain-specific knowledge, and their judgments may be erroneous or biased, making it difficult to guarantee engineering verifiability.

[0038] Therefore, to address the problems of existing technologies, such as difficulty in discovering complex semantic vulnerabilities, low detection efficiency, susceptibility to false positives and false negatives, and the need for manual rule definition and verification, this application provides a vehicle operating system vulnerability detection method, an electronic device, a computer-readable storage medium, and a computer program product to improve the accuracy and interpretability of vehicle operating system vulnerability detection.

[0039] The following examples will provide a detailed description.

[0040] Based on this, embodiments of this application provide a method for detecting vulnerabilities in an in-vehicle operating system that can be executed by an in-vehicle operating system vulnerability detection method device, see [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Obtain raw vulnerability sample data from the professional database of security vulnerabilities in connected vehicle products and the dataset of operating system vulnerabilities; wherein, the vulnerability sample data includes vulnerability code segments; split the vulnerability code segments to obtain individual vulnerability code blocks; use a large language model to extract information based on the vulnerability sample data and the vulnerability code blocks to obtain code functional semantic information and vulnerability cause information; encapsulate the vulnerability sample data, the vulnerability code blocks, the code functional semantic information, and the vulnerability cause information to obtain structured knowledge entries; store each knowledge entry in a knowledge base and establish an index to obtain a searchable vulnerability knowledge base.

[0041] Specifically, vulnerability sample data is obtained from multi-source vulnerability datasets (i.e., a professional database of security vulnerabilities for connected vehicle products and a dataset of vulnerability datasets for operating systems). This data is then extracted using a large language model to obtain the code functional semantic information and vulnerability causation information of the vulnerabilities. This information is further encapsulated into structured knowledge entries and stored in a vulnerability knowledge base. The professional database of security vulnerabilities for connected vehicle products comes from authoritative vulnerability platforms in the automotive industry, such as the Ministry of Industry and Information Technology's Cybersecurity Threat and Vulnerability Information Sharing Platform. The operating system vulnerability dataset can be a publicly available vulnerability dataset.

[0042] It should also be noted that the method proposed in this application can be divided into two parts: vulnerability knowledge base construction and vulnerability detection. The vulnerability knowledge base construction part can be divided into four modules according to function: data preprocessing module, code semantic extraction module, vulnerability cause analysis module, and knowledge persistence module. The vulnerability detection part can be divided into four functional modules: code preprocessing module, code semantic extraction module, knowledge retrieval module, and inference engine module. Each module works together to complete the generation from code text to detection results. The specific implementation method will be described in detail in the following embodiments.

[0043] The data preprocessing module is responsible for connecting to and preprocessing multi-source vulnerability datasets. It acquires vulnerability sample data information, including vulnerability ID, vulnerability description, vulnerable code segment, patch code segment, and patch differences, via offline files. The acquired data is parsed to extract the vulnerable code segment and patch code segment, and irrelevant fields are removed to ensure consistent input format for subsequent processing. Vulnerability sample data from different data sources is transformed into a single structure—a vulnerability data quadruple containing the vulnerability ID, vulnerability description, vulnerable code segment, and patch code segment.

[0044] Step 200: Retrieve the vulnerability knowledge base based on the semantic information of the function to be detected to obtain a candidate knowledge list; use a large language model to reason and judge the candidate knowledge list to obtain the detection result for vehicle operating system vulnerability detection.

[0045] Understandably, the vulnerability knowledge base can be queried based on the BM25 (Best Matching 25) text similarity algorithm to retrieve vulnerability knowledge that is similar to the functional semantic information to be detected. The large language model combines the code block of the function to be detected, its functional semantic information, and the retrieved functional semantic information to perform inference analysis, determine whether there are known types of vulnerabilities, and output the detection results.

[0046] As described above, the vehicle operating system vulnerability detection method provided in this application involves designing a vehicle vulnerability knowledge base construction system, introducing repair code segments and vulnerability description information, so that existing vulnerability case knowledge can be used for auxiliary analysis during the retrieval stage; by externally accessing a dedicated vulnerability database related to vehicle operating systems, knowledge updates can be achieved to optimize detection results; by converting knowledge items into vulnerability knowledge containing functional semantics, triggering conditions, and repair solutions and storing them in the vulnerability knowledge base, and using the constructed vulnerability knowledge base for subsequent vulnerability detection, the accuracy and interpretability of vehicle operating system vulnerability detection can be improved.

[0047] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, in step 100, the method for detecting in-vehicle operating system vulnerabilities uses a large language model to extract information based on the vulnerability sample data and the vulnerability code block to obtain code functional semantic information and vulnerability cause information, specifically including the following: Step 110: Use a large language model to perform semantic extraction on each of the vulnerability code blocks to obtain the semantic information of the code functions.

[0048] Step 120: Utilize a large language model to perform vulnerability cause analysis by combining the vulnerability sample data and the vulnerability code block to obtain vulnerability cause information; wherein, the vulnerability sample data also includes vulnerability description information and remediation code segments, and the vulnerability cause information includes abstract vulnerability description information, triggering action information, and remediation scheme information.

[0049] Specifically, the code semantic extraction module in the vulnerability knowledge base construction section calls a large language model to perform in-depth semantic understanding of the vulnerability code blocks and extract vulnerability knowledge elements; the vulnerability cause analysis module, based on code semantic extraction, further focuses on the information processing and summarization of vulnerability causes and context. Its main function is to combine the differences between the vulnerability code block and the repair code segment and the vulnerability description to extract the root cause and triggering conditions of the vulnerability, providing a higher level of abstract understanding.

[0050] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, in step 110, the method for detecting in-vehicle operating system vulnerabilities utilizes a large language model to perform semantic extraction on each vulnerable code block to obtain code functional semantic information. Specifically, this includes the following: Step 111: Construct a first cue word so that the large language model generates abstract target information of the vulnerable code block.

[0051] Step 112: Construct a second cue word to enable the large language model to generate detailed behavioral information describing the vulnerable code block.

[0052] Step 113: Use the abstract purpose information and detailed behavior information generated by the large language model as the code functional semantic information.

[0053] Specifically, the code semantic extraction module in the vulnerability knowledge base construction section extracts the functional semantics of the code for each vulnerability data entry: it extracts the high-level functional semantics of the vulnerability code, including abstract purpose information and detailed behavioral information. The module generates prompts to ask the large language model about the intent of the vulnerability code fragment, as shown in Table 1.

[0054] Table 1 Code semantic extraction prompts The model returns an abstract description of the code's purpose and a detailed list of its implementation steps or functionalities. Through these two subtasks, the system obtains the functional semantic information of the vulnerable code under normal circumstances. This information not only provides contextual descriptions for knowledge base entries but is also used to construct queries during subsequent knowledge retrieval.

[0055] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, the method for detecting in-vehicle operating system vulnerabilities includes the following steps in step 120: using a large language model to combine the vulnerability sample data and the vulnerability code block for vulnerability cause analysis. Step 121: Construct a first-round vulnerability analysis hint word containing the vulnerable code block, the patch code segment, and the vulnerability description, so that the large language model can generate patch code explanation information corresponding to the patch code segment, and obtain the first-round output result. Step 122: Construct a second round of vulnerability analysis prompts based on the first round of output results, so that the large language model can generate a repair method for the vulnerability code block, and obtain a second round of output results in a structured format; wherein, the second round of output results includes the abstract vulnerability description information, the triggering action information, and the repair scheme information.

[0056] Step 123: Construct vulnerability cause verification prompts based on the second round output results, and verify and improve the second round output results.

[0057] Specifically, the vulnerability cause analysis module employs a two-round nested prompt strategy to construct a vulnerability cause analysis thought chain, guiding the large language model to gradually extract complex information. The first round of prompt strategy provides the model with context such as the vulnerable code block, the fix code segment, and the vulnerability description, as shown in Table 2.

[0058] Table 2 First Round of Prompts The large language model provides an explanation of the function of the repair code segment and extracts the root cause of the vulnerability. In the second round, based on the model's understanding of the meaning of the repair code segment, it is prompted to organize the specific causes of the vulnerability and the repair methods, and is required to give the results in a structured format, as shown in Table 3.

[0059] Table 3 Second Round of Prompts

[0060] The large language model then returns results in JSON format, containing fields such as an abstract vulnerability description, triggering action, and remediation plan. These two rounds of prompting strategies allow the large language model to first interpret the remediation code segment, then organize the causes, reasoning step-by-step based on a thought chain approach, thereby improving the accuracy and structure of the answer.

[0061] The vulnerability cause analysis module further standardizes the vulnerability causes. Based on the results of the second round of prompt word output using the large language model, regression verification and improvement are performed, as shown in Table 4.

[0062] Table 4 Verification Prompts

[0063] The vulnerability cause analysis module ultimately obtains vulnerability cause information, including abstract vulnerability description information, triggering action information, and remediation plan information, namely the vulnerability semantic triple: abstract vulnerability description, direct action that triggers the vulnerability, and an overview of the corresponding remediation measures.

[0064] It should also be noted that the knowledge persistence module integrates the aforementioned vulnerability information and assembles it into structured vulnerability knowledge entries. Each knowledge entry corresponds to a vulnerability instance, and key fields are recorded using a unified JSON format for easy storage and retrieval. The complete knowledge entries are shown in Table 5.

[0065] Table 5 Examples of Knowledge Items After integrating the extracted knowledge, the structured vulnerability knowledge entries are saved in the database. Considering the textual semantic features of the knowledge, a search engine that supports text retrieval algorithms (such as BM25) can be used as the storage backend. Each knowledge unit is stored as a document in the database, and during indexing, triples (such as those containing abstract purpose information, detailed behavioral information, and code snippets) are used as searchable full-text fields.

[0066] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an in-vehicle operating system vulnerability detection method provided in this application embodiment, before retrieving the vulnerability knowledge base based on the semantic information of the function to be detected to obtain a candidate knowledge list in step 200, the following content is specifically included: Step 130: Obtain the source code of the vehicle operating system to be tested, and split the source code to obtain each function code block to be tested.

[0067] Step 140: Use the large language model to perform semantic extraction on each of the code blocks of the function to be detected, and obtain the semantic information of the function to be detected corresponding to each of the code blocks of the function to be detected.

[0068] Specifically, the code preprocessing module of the vulnerability detection part traverses and reads the source code directory of the operating system to be detected, filters out the code files that need to be detected, and then uses the abstract syntax tree interface provided by the compiler Clang to perform abstract syntax tree parsing on each file. The abstract syntax tree allows for the acquisition of code structure information, ensuring accurate identification of function boundaries. This breaks down the code file into function-level blocks, making each code segment a complete piece of logic. Through preprocessing, the original massive codebase is transformed into code blocks of the function to be detected and their identification information that can be understood by a large language model, reducing the complexity of a single analysis and avoiding situations where the code is too long and exceeds the model input length. The code semantic extraction module of the vulnerability detection part generates a functional semantic description for each input code block of the function to be detected, including two parts: abstract purpose and detailed behavior.

[0069] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, in step 200, the method for detecting in-vehicle operating system vulnerabilities retrieves the vulnerability knowledge base based on the semantic information of the function to be detected to obtain a candidate knowledge list, which specifically includes the following: Step 210: Input the functional semantic information to be detected into the vulnerability knowledge base as query information to obtain various query results; wherein, the functional semantic information includes code snippet text, abstract purpose information and detailed behavior information.

[0070] Step 220: Calculate and sort the similarity scores of each query result to obtain a list of search results corresponding to the code snippet text, the abstract purpose information, and the detailed behavior information.

[0071] Step 230: Select a preset number of the query results in descending order of the similarity score, and use them as the original knowledge list corresponding to each of the search result lists.

[0072] Step 240: Merge and reorder the knowledge entries in each of the original knowledge lists to obtain a candidate knowledge list.

[0073] Specifically, the knowledge retrieval module retrieves relevant vulnerability knowledge items from the constructed vulnerability knowledge base based on the code block of the function to be detected and its functional semantic description. This module implements a three-way retrieval and result fusion process based on code snippet text, abstract purpose, and detailed behavior. The vulnerability knowledge base can be built using a distributed search and analysis engine (Elasticsearch), and efficient querying can be achieved using inverted indexes and the BM25 algorithm. Each record in the vulnerability knowledge base contains key fields: vulnerability code snippet text, vulnerability abstract purpose, vulnerability detailed behavior, vulnerability cause, remediation plan, and vulnerability number. The first three fields are mainly used for similarity retrieval, while the latter two fields are provided to the model for reference during final inference.

[0074] When the retrieval module receives a query request containing code snippet text, abstract purpose, and detailed behavior, it constructs three queries: one for the code snippet text, corresponding to the code field in the knowledge base; one for the abstract purpose of the code snippet, corresponding to the purpose field in the knowledge base; and one for the detailed behavior of the code snippet, corresponding to the behavior field in the knowledge base. Parallel queries are performed, and the BM25 algorithm is used for matching. For each query, a list of result documents sorted by relevance is returned, along with a relevance score, as shown in the following formula: in, This indicates document D and the query. The relevance score, This represents the i-th word in the query. Indicator Frequency in document D, Indicator Inverse document frequency, The length of document D is represented by avgdl, and the average length of all documents is represented by avgdl. and Indicates an adjustable parameter. This indicates the total number of documents in the corpus. Indicates the inclusion word The number of documents.

[0075] Each query can select its top 10 results to obtain search result lists A, B, and C corresponding to the code snippet text, the abstract purpose information, and the detailed behavioral information, respectively. A includes several historical vulnerabilities containing similar code snippets; B includes vulnerabilities with similar code functions; and C includes vulnerability cases with similar operational processes. Based on the three search result lists, fusion, deduplication, and sorting optimization are performed to obtain a candidate knowledge list.

[0076] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, the method for detecting in-vehicle operating system vulnerabilities, in step 240, involves fusing and reordering the knowledge entries in the original knowledge lists, specifically including the following: Step 241: Merge the original knowledge lists and remove duplicates based on the unique identifier of each knowledge entry.

[0077] Step 242: Calculate the fusion score based on the similarity score corresponding to each knowledge item.

[0078] Step 243: Select a preset number of knowledge items in descending order of the fusion scores.

[0079] Specifically, the three search result lists are merged, and the knowledge entries in the lists are deduplicated and sorted. Deduplication is mainly based on merging identical knowledge entries according to their vulnerability IDs. Simultaneously, the relevance scores for each vulnerability should be retained during merging. A Reciprocal Rank Fusion (RRF) method can be used to combine the rankings of each vulnerability to calculate the fusion score for subsequent sorting calculations. The formula for the fusion score of a knowledge entry is as follows: in, These represent the ranking of knowledge items in A, B, and C, respectively, with k representing a smoothing constant to reduce the excessive dominance of top rankings. If a knowledge item does not appear, it is considered to have an infinite ranking, and the same knowledge item will receive higher priority if it is retrieved multiple times. The knowledge items in the list are sorted from highest to lowest according to their fusion score, and the top 10 can be selected as a candidate knowledge list. The candidate knowledge list includes a set of vulnerability knowledge items most relevant to the code under test.

[0080] To further improve the accuracy and interpretability of in-vehicle operating system vulnerability detection, in an embodiment of this application, the in-vehicle operating system vulnerability detection method, in step 200, utilizes the candidate knowledge list of the large language model for reasoning and judgment, specifically including the following: Step 250: For each knowledge entry in the candidate knowledge list, combine the knowledge entry and the corresponding function code block to be detected to construct the prompt word corresponding to the knowledge entry, so that the large language model can perform chain reasoning and obtain the reasoning result.

[0081] Step 260: If the reasoning result corresponding to any of the knowledge entries is a vulnerability, then terminate the subsequent judgment and output the detection result and vulnerability information corresponding to the reasoning result.

[0082] Specifically, the inference engine module integrates the code and retrieved knowledge entries, and a large model performs vulnerability assessment. The inference engine module reads each knowledge entry from the candidate knowledge list provided by the knowledge retrieval module, combines it with the corresponding code snippet to form a hint word, and then uses the large language model to infer a conclusion, which is then summarized into a detection report.

[0083] The inference engine module constructs detection prompts for each vulnerability knowledge item, and guides the large language model to perform inference and analysis step by step through a thought chain generation mechanism, including comparing current code differences, aligning vulnerability causes, inferring potential vulnerabilities, and generating remediation suggestions. Detection prompts are shown in Table 6.

[0084] Table 6 Detection prompts

[0085] During vulnerability detection, if the large language model determines that the code has a vulnerability under any knowledge item, the module will record the vulnerability type and reason, and terminate the analysis of the remaining knowledge. Since a highly relevant known vulnerability pattern has been found that matches the code, there is sufficient reason to believe that the code is insecure, so there is no need to redundantly check more knowledge. The inference engine module will define the final result as "Vulnerability detected" and associate the triggered vulnerability knowledge (such as providing the vulnerability number and name) for the report reference. If, after checking all candidate knowledge in turn, the model does not indicate the existence of a vulnerability, the module determines that no known vulnerability has been found in the code segment. The output will provide corresponding explanations, such as no recorded vulnerability pattern was detected, or no significant security vulnerability has been found in the code.

[0086] Understandably, the inference engine module collects vulnerability detection results and ultimately generates a vulnerability detection report, including detection results and vulnerability information. If a vulnerability is detected, it will provide a vulnerability code snippet identifier (i.e., a storage path identifier obtained by the preprocessing module), the knowledge entries that lead to the conclusion, and a description of the vulnerability determined by the inference engine.

[0087] To further illustrate the above embodiments, this application also provides a specific application example of a method for detecting vulnerabilities in an in-vehicle operating system.

[0088] Retrieval-Augmented Generation (RAG) is a general paradigm that enhances large language models by retrieving relevant information from external databases and integrating it into the input. RAG typically consists of three stages: indexing, retrieval, and generation. First, in the indexing stage, external databases and their retrieval indexes are built from external data sources. Second, given a user query, the retrieval system uses these indexes to retrieve relevant document fragments as context. Finally, the retrieved context is integrated into the input prompts of the large language model, which then generates the final output based on the enhanced input. A flowchart illustrating the retrieval-augmented generation technique is shown below. Figure 2 As shown, the process first reads the local document and splits it into text segments using a text segmenter. These segments are then vectorized and stored in a vector database. When a user inputs a request, the input is vectorized, and the most relevant text segments are retrieved from the database based on relevance. These text segments are then loaded into a prompt word template to form the final prompt, which is then fed into the large language model, which generates the final result.

[0089] The in-vehicle operating system vulnerability detection method provided in this application example specifically includes the following: The method for detecting vulnerabilities in vehicle operating systems can be divided into two parts: an automated vulnerability knowledge base construction system and an in-vehicle operating system vulnerability detection system. A schematic diagram of the vulnerability knowledge base construction system is shown below. Figure 3 As shown in the diagram, the architecture of the in-vehicle operating system vulnerability detection system is as follows: Figure 4 As shown.

[0090] An automated vulnerability knowledge base construction system consists of two layers: a data input layer that automatically processes vulnerability sample data from vulnerability databases (such as a professional vulnerability database for connected vehicle products and / or a publicly available vulnerability dataset); a knowledge extraction layer that uses a large language model to perform semantic understanding on each vulnerability sample data, extracting multi-dimensional knowledge information related to the vulnerability, such as code functional semantic information and vulnerability cause information; and a knowledge encapsulation layer that organizes the extracted information into a unified JSON structure, forming structured knowledge entries. These knowledge units are then stored in the knowledge base storage layer to construct the vulnerability knowledge base.

[0091] In-vehicle operating system vulnerability detection system: During actual vulnerability detection, the source code to be detected is segmented into function-level code blocks through code layering. First, a large language model extracts its functional semantics (such as code purpose and detailed behavior) to form functional semantic information, which is then used to query the vulnerability knowledge base to retrieve vulnerability knowledge similar to the functional semantic information to be detected. The large language model combines the function code block to be detected, its functional semantic information, and the retrieved functional semantic information to perform inference analysis, determine whether there are known types of vulnerabilities, and output the detection results.

[0092] The architecture of the vehicle operating system vulnerability detection method can be divided into two parts: offline knowledge accumulation and online knowledge application. The former automatically transforms scattered vulnerability data into structured knowledge, while the latter flexibly applies the knowledge to actual detection tasks.

[0093] Specifically, the vulnerability knowledge base construction system uses structured vulnerability samples as input to ultimately form a vulnerability knowledge base that supports multi-dimensional semantic retrieval. A complete automated process is built around the representation and searchability of vulnerability knowledge, as follows: Figure 5 As shown, the specific content is as follows: (1) Data access phase: The system first accesses the original vulnerability sample data, including fields such as vulnerability number, description information, vulnerability code and patch. These fields constitute the basic corpus for subsequent knowledge extraction.

[0094] (2) Function segmentation of vulnerability code: Function-level segmentation of vulnerability code ensures that the granularity of knowledge extraction is focused on a single functional unit, thereby improving the integrity of semantic expression.

[0095] (3) Semantic extraction of vulnerability code: For the segmented vulnerability function code, a large language model is called to perform prompt-guided analysis to extract the semantic information of code function containing abstract purpose and detailed behavior.

[0096] (4) Vulnerability cause extraction: By comparing the original vulnerability code with the patch and vulnerability description, the vulnerability cause {abstract vulnerability description, triggering action, and remediation plan} is further extracted to help the subsequent model understand the vulnerability triggering context.

[0097] (5) Knowledge Encapsulation: Pack the vulnerability number, original code, semantic information and cause information into structured knowledge entries to prepare for subsequent retrieval.

[0098] (6) Storage and indexing: Store and index knowledge items, set up multi-field composite indexes (such as function code, semantic purpose, behavior), and configure the semantic similarity calculation capability to support BM25.

[0099] The in-vehicle operating system vulnerability detection process is executed in stages using a pipeline approach, including code preprocessing, semantic extraction, knowledge retrieval, and final vulnerability determination. The overall process is as follows: Figure 6 As shown, the specific content is as follows: (1) Code preprocessing and abstract syntax tree (AST) segmentation: First, the operating system source code to be tested is traversed and parsed. The source code is segmented at the function or code fragment level using an abstract syntax tree parsing tool. AST segmentation ensures that each fragment is a semantically independent code unit, facilitating subsequent analysis.

[0100] (2) Code function semantic extraction: For each code segment, the system calls the large language model through prompt words to generate the functional semantic description of the segment, including abstract purpose and detailed behavior, so as to obtain the functional semantic triple for knowledge base retrieval, namely code segment text, abstract purpose and detailed behavior, as the basis for querying vulnerability knowledge.

[0101] (3) Three-way BM25 knowledge retrieval: Using the semantic triples of the code functions mentioned above, relevant vulnerability case entries are retrieved from the vulnerability knowledge base. Each entry in the knowledge base contains vulnerability code and its knowledge information (vulnerability number, abstract purpose and behavioral description of the code fragment, vulnerability triggering behavior, brief description of the vulnerability, and remediation method). The retrieval process is carried out in parallel in three ways: code text-based retrieval, abstract purpose-based retrieval, and detailed behavior-based retrieval. Each retrieval can use BM25 similarity scoring to rank the knowledge base documents and select the 10 items with the highest scores as candidate results.

[0102] (4) Retrieval Result Fusion and Re-ranking: For the candidate vulnerability knowledge set obtained from the three-way retrieval, the system performs fusion, deduplication, and ranking optimization. First, the union of the three candidate lists is taken, and duplicate vulnerability entries are merged. Then, the harmonic mean method is used to fuse the rankings, so that knowledge items with high rankings in multiple ways will get higher comprehensive scores. The candidate set is re-ranked according to the fusion score, and the 10 items with the highest final comprehensive scores can be selected as the most relevant vulnerability knowledge list for subsequent reasoning.

[0103] (5) Large Language Model Reasoning and Judgment: The reasoning engine module uses the selected vulnerability knowledge and the code fragment to be tested to construct prompt words, and calls the large language model to analyze and judge the existence of vulnerabilities one by one. For each candidate vulnerability knowledge, the model will use chain thinking prompts to first compare the behavior of the target code with the cause explanation in the vulnerability knowledge, and then give a conclusion. When the model reports "vulnerability exists", it is considered that a security risk has been found, the result is recorded and the subsequent analysis ends early. If no vulnerability warning is triggered after all knowledge has been analyzed, the conclusion "no known type of vulnerability detected" is output. Through this item-by-item reasoning and short-circuit judgment mechanism, once a highly relevant knowledge item confirms the possibility of vulnerability, the system can give a report in a timely manner; at the same time, multiple rounds of knowledge comparison reduce the possibility of missed judgment.

[0104] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the vehicle operating system vulnerability detection method mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0105] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0106] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the vehicle operating system vulnerability detection method in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the vehicle operating system vulnerability detection method in the above method embodiments.

[0107] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0108] The one or more modules are stored in the memory, and when executed by the processor, the vehicle operating system vulnerability detection method in the embodiment is executed.

[0109] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0110] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0111] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0112] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned vehicle operating system vulnerability detection method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0113] This application also provides a computer program product, specifically comprising a computer program that, when executed by a processor, implements the steps of the vehicle operating system vulnerability detection method mentioned in the foregoing embodiments.

[0114] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0115] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0116] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0117] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting vulnerabilities in an in-vehicle operating system, characterized in that, The method includes: The process involves acquiring raw vulnerability sample data from a professional database of security vulnerabilities in connected vehicle products and a dataset of vulnerabilities in operating systems; wherein the vulnerability sample data includes vulnerable code segments; splitting the vulnerable code segments to obtain individual vulnerable code blocks; using a large language model to extract information based on the vulnerability sample data and the vulnerable code blocks to obtain code functional semantic information and vulnerability cause information; encapsulating the vulnerability sample data, the vulnerable code blocks, the code functional semantic information, and the vulnerability cause information to obtain structured knowledge entries; and storing each knowledge entry in a knowledge base and establishing an index to obtain a searchable vulnerability knowledge base. The vulnerability knowledge base is retrieved based on the semantic information of the function to be detected to obtain a candidate knowledge list; the candidate knowledge list is then inferred and judged using a large language model to obtain the detection results for vehicle operating system vulnerability detection.

2. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 1, characterized in that, The process of extracting information using a large language model based on the vulnerability sample data and the vulnerability code block to obtain code functional semantic information and vulnerability cause information includes: A large language model is used to extract semantic information from each of the aforementioned vulnerable code blocks to obtain the semantic information of the code functions; The vulnerability cause analysis is performed by combining the vulnerability sample data and the vulnerability code block with a large language model to obtain vulnerability cause information. The vulnerability sample data also includes vulnerability description information and remediation code segments. The vulnerability cause information includes abstract vulnerability description information, triggering action information and remediation scheme information.

3. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 2, characterized in that, The step of using a large language model to perform semantic extraction on each of the vulnerable code blocks to obtain code functional semantic information includes: Construct a first cue word to enable the large language model to generate abstract purpose information for the vulnerable code block; Construct a second cue word to enable the large language model to generate detailed behavioral information describing the vulnerable code block; The abstract purpose information and detailed behavioral information generated by the large language model are used as the semantic information of the code function.

4. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 2, characterized in that, The method of using a large language model to combine the vulnerability sample data and the vulnerability code block for vulnerability cause analysis includes: A first-round vulnerability analysis hint word is constructed, which includes the vulnerable code block, the repair code segment, and the vulnerability description, so that the large language model generates the repair code explanation information corresponding to the repair code segment, and the first-round output result is obtained. Based on the first round of output results, a second round of vulnerability analysis hints are constructed to enable the large language model to generate a remediation method for the vulnerability code block, resulting in a second round of output results in a structured format; wherein, the second round of output results includes the abstract vulnerability description information, the triggering action information, and the remediation scheme information; Based on the output results of the second round, construct vulnerability cause verification prompts, verify and improve the output results of the second round.

5. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 1, characterized in that, Before retrieving the vulnerability knowledge base based on the functional semantic information to be detected to obtain a candidate knowledge list, the method further includes: Obtain the source code of the vehicle operating system to be tested, and split the source code to obtain the individual function code blocks to be tested; The large language model is used to extract semantics from each of the code blocks of the function to be detected, so as to obtain the semantic information of the function to be detected corresponding to each of the code blocks of the function to be detected.

6. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 1, characterized in that, The process of retrieving the vulnerability knowledge base based on the functional semantic information to be detected to obtain a candidate knowledge list includes: The functional semantic information to be detected is input into the vulnerability knowledge base as query information to obtain various query results; wherein, the functional semantic information includes code snippet text, abstract purpose information, and detailed behavior information; The similarity scores of each query result are calculated and sorted to obtain a list of search results corresponding to the code snippet text, the abstract purpose information, and the detailed behavior information, respectively. A preset number of the query results are selected in descending order of the similarity score, and these are used as the original knowledge lists corresponding to each of the search result lists. The knowledge entries in each of the original knowledge lists are merged and reordered to obtain a candidate knowledge list.

7. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 6, characterized in that, The process of merging and reordering the knowledge entries in each of the original knowledge lists includes: Merge the original knowledge lists and remove duplicates based on the unique identifier of each knowledge entry; A fusion score is calculated based on the similarity score corresponding to each of the aforementioned knowledge items. A preset number of knowledge items are selected in descending order of the fusion scores.

8. The method for detecting vulnerabilities in an in-vehicle operating system according to claim 1, characterized in that, The reasoning and judgment using the candidate knowledge list of the large language model includes: For each knowledge entry in the candidate knowledge list, the knowledge entry and the corresponding function code block to be detected are combined to construct the prompt word corresponding to the knowledge entry, so that the large language model can perform chain reasoning and obtain the reasoning result. If the reasoning result corresponding to any of the knowledge entries indicates the existence of a vulnerability, then the subsequent judgment is terminated, and the detection result and vulnerability information corresponding to the reasoning result are output.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the vehicle operating system vulnerability detection method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the vehicle operating system vulnerability detection method as described in any one of claims 1 to 8.

Images