AOSP security patch intelligent analysis method and system based on function level difference semantic compression and multi-level shunt

Abstract

This invention discloses an intelligent analysis method and system for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting, belonging to the technical fields of source code security analysis and software supply chain security analysis. The method includes: acquiring AOSP code submission data; performing differential structure parsing on the submitted code; performing submission hash matching based on a vulnerability knowledge base; performing reverse static filtering; performing precise extraction of function-level differential context and compressed representation of call relationships; generating structured code input and performing large-scale model analysis; and performing result verification, traffic splitting into the database, and failure retry control. This method, by combining rapid matching of known CVEs, precise differential extraction, compressed representation of call relationships, and structured security reasoning, significantly reduces the proportion of invalid submissions entering the deep analysis chain, improving the efficiency of AOSP security patch identification, the reproducibility of results, and the stability of model auditing.

Description

Technical Field

[0001] This invention belongs to the field of source code security analysis and software supply chain security analysis technology, specifically involving an intelligent analysis method and system for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting. Background Technology

[0002] With the rapid development of the Android ecosystem, AOSP (Android Open Source Project), as the core open-source code foundation of the Android system, is crucial for system maintenance and security governance. Intelligent identification and analysis of security patches in the AOSP code repository has urgent practical application needs in many fields: First, in the field of Android ecosystem security governance, there is a need for automated security semantic analysis of the large number of commit records generated daily by multiple Git sub-repositories of AOSP; second, in the field of software supply chain security analysis, there is a need to provide downstream manufacturers of customized systems based on AOSP with security assessment results of upstream patches, shortening security response latency; third, in the field of security vulnerability intelligence collection, by combining public vulnerability databases and in-depth analysis of silent patches, the sources of security intelligence can be expanded; fourth, in the field of code security auditing, as an auxiliary tool for the underlying framework code of the Android system, it can provide structured results to support manual review.

[0003] AOSP is characterized by frequent commits, numerous modules, and complex patch types. Security analysts typically need to quickly identify patches with genuine security significance from a large number of routine feature fixes, documentation updates, and interface adjustments when analyzing AOSP commits. Currently, traditional methods mainly rely on manually reading commit messages and analyzing code change differences (diff). This purely manual approach is not only inefficient but also extremely difficult to maintain consistency in analysis results across multiple repositories, models, and rounds of analysis.

[0004] In recent years, various automated methods have been proposed to address the problem of identifying security patches submitted by open-source software, but significant limitations remain. Specifically: traditional machine learning-based methods (such as support vector machines or multi-classifier voting) heavily rely on manually designed feature engineering, resulting in insufficient feature representation, difficulty in modeling long dependencies, and complex code semantics; deep learning-based methods (such as PatchRNN and GraphSPD) have improved code semantic modeling, but are typically limited to function-level feature extraction, neglecting cross-function vulnerability semantics, and the training efficiency of graph models decreases significantly with increasing code complexity; pre-trained model-based methods (such as CodeBERT and CodeT5+) improve semantic understanding, but still suffer from low recall and insufficient understanding of remediation intent. More importantly, the above methods are mostly geared towards general open-source repositories, lacking specialized processing for complex scenarios specific to AOSP, such as multiple repositories and high-frequency submissions.

[0005] In real-world engineering environments, existing automated security patch analysis methods (such as those based on program slicing or graph clustering) are highly susceptible to analysis failures or performance crashes, specifically in the following four aspects: First, they are severely limited by patch size, easily leading to node explosion. For example, existing graph-based methods (such as UTANGO) experience an exponential expansion of data flow and control flow graph nodes when faced with security patches involving numerous lines of code changes, directly causing analysis failures or a precipitous drop in accuracy. Second, direct analysis of large models easily leads to context overflow and illusions. Real-world open-source patches often contain a large number of non-core files (such as test case documents and UI resources). If input directly without compression, they easily exceed the context length (Token) limit of large models, resulting in structured parsing failures. Third, they lack precise extraction mechanisms for patch semantics. Existing methods often input the entire code change difference (diff) and even a large amount of irrelevant context into the analysis model, causing core security information to be overwhelmed by noise. Summary of the Invention

[0006] To address the problems in existing AOSP patch security analysis, such as a high percentage of invalid submissions, inability to quickly identify known vulnerabilities, severe patch context redundancy, unstable model analysis results, and repeated blocking of batch processing failure tasks, this invention proposes an intelligent AOSP security patch analysis method and system based on function-level differential semantic compression and multi-level traffic splitting. This method can process AOSP patches in a technical and structured manner, enabling rapid filtering using known vulnerability knowledge, high-quality function-level patch semantic compression and security inference for unknown submissions, and ensuring stable storage of analysis results through strict result verification, model isolation, and retry control.

[0007] Technical Solution: To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] An intelligent analysis method for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting includes the following steps:

[0009] S1. Obtain AOSP code commit data: Perform incremental updates on the AOSP source code repository and extract the committed code;

[0010] S2. Perform differential structure parsing on the submitted code to obtain the set of changed files, the set of code blocks, and addition / deletion statistics;

[0011] S3. Pre-processing of known vulnerability submissions: Based on the vulnerability knowledge base, perform submission hash matching and directly write submissions that match known CVE mapping relationships into the security result database.

[0012] S4. Perform reverse static filtering on submissions that do not hit known CVEs, and only send submissions that meet the security analysis conditions into the deep analysis link.

[0013] S5. Execution function level differential semantic compression: Accurately extracts and compresses the call relationship representation of the submitted execution function level differential context entering the deep analysis link to generate a compact semantic context;

[0014] S6. Generate structured code input and perform large model analysis: Input the compact semantic context into the constrained large model structured analysis engine and output the security issue type, severity, issue description, cause, availability and test hints.

[0015] S7. Execution result verification, distributed entry into database and failure retry control: Perform field integrity verification on the structured analysis results, and write submissions with security issues and those without security issues into mutually isolated result databases according to the model identifier.

[0016] As a preferred option, the specific implementation details in S1 are as follows:

[0017] Perform repo-level incremental updates on the AOSP repository and identify multiple Git sub-repositories in the corresponding directory; perform git log retrieval for each sub-repository by time window to obtain the commit hash, author, commit date, and commit message; then perform git show code extraction for each commit, and only retain the code body starting with diff --git as input for subsequent analysis.

[0018] As a preferred option, the specific implementation details in S2 are as follows:

[0019] The system uses differential file matching rules to identify the original and new file paths of the commits. It uses code block header parsing rules to extract the original starting line number, new starting line number, modification range, and context header information of each code block. Based on the statistics of added and deleted lines within the code block, it generates the number of commit-level files, the number of code blocks, the number of added lines, and the number of deleted lines.

[0020] As a preferred option, the specific implementation details in S3 are as follows:

[0021] The vulnerability knowledge base loads the announcement date range, CVE number, severity, announcement date, and commit hash mapping relationship; case-insensitive matching is performed on the commit hash of the submission to be analyzed; when one or more CVE numbers are matched, the severity levels are merged to generate a set of CVE numbers, severity levels, and announcement dates corresponding to the submission, and this is written directly into the security results database as a known secure submission, without entering the subsequent deep analysis chain.

[0022] As a preferred option, the specific implementation details in S4 are as follows:

[0023] For submissions that do not match known vulnerability mappings, the system first checks whether there are analysis records in the security result library and non-security result library corresponding to the current model. If they exist, the system skips them. If they do not exist, the system checks whether the modified file is empty. If the modified file is not empty, the system further checks whether all the files involved belong to the preset non-core file types. If all the modified files are non-core files, the system makes a joint judgment based on the security information in the submission message and the code text. If the judgment is that it is not related to security, the submission does not need to enter the deep analysis chain.

[0024] As a preferred option, the specific implementation details in S5 are as follows:

[0025] The function name is identified from the header information of each code block; when the function name cannot be directly identified, the valid context identifier in the code block header is identified back; only the modified lines in the code block that start with an add or delete marker are retained to form a function-level differential context; at the same time, the file to which it belongs, the function name, the code block header and the set of modified lines are recorded, and a compact semantic carrier is constructed by combining the commit-level statistics.

[0026] As a preferred option, the specific implementation details in S6 are as follows:

[0027] The constrained large-model structured analysis engine includes: pre-built system prompts for Android AOSP, Linux, and system security analysis; requiring the model to reason about vulnerability remediation, permission boundaries, verification logic, memory safety issues, process boundaries, and security policy changes, and forcing the output of JSON structured results; inputting the large model with submission hashes, dates, and compact semantic context as user prompts; and marking the analysis as a failure when the model's returned content cannot be parsed into a JSON object.

[0028] An intelligent analysis system for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting, implementing the intelligent analysis method for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting described in any of the above items, includes:

[0029] Data update module: Used to perform incremental updates to the AOSP source code repository and identify Git sub-repositories within the scope of analysis;

[0030] The commit data extraction module is used to extract commit hash, author, date, commit message, and code difference body by time window.

[0031] Differential parsing module: used to parse changed files, code block headers, added / deleted lines, and commit-level statistics in committed code;

[0032] CVE identification module: used to quickly identify and directly archive known vulnerability submissions based on the mapping relationship between submission hash and vulnerability knowledge base;

[0033] Reverse static filtering module: It combines deduplication, empty submission removal, non-core file identification and security signal judgment to perform pre-screening on submissions that do not hit the knowledge base;

[0034] Function-level semantic compression module: used to identify function context and extract added, deleted, and modified lines, and generate function-level differential context;

[0035] Lightweight graph construction module: used to extract call names from function-level difference context and construct a representation of local call relationships;

[0036] The structured analysis module is used to take a compact semantic context as input to a large, constrained model and output structured security analysis results.

[0037] The result verification and database storage module is used to perform integrity verification on structured results and write them into the secure result database and the non-secure result database according to the model identifier.

[0038] Failure control module: Used to record the number of retries for failed analysis tasks and control whether to re-analyze or permanently mark a failed task based on a threshold.

[0039] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0040] (1) By introducing a pre-identification mechanism that maps submission hashes to vulnerability knowledge bases, this invention eliminates the need for known security patches to re-enter the deep semantic analysis stage, thereby significantly shortening the overall analysis chain and improving the certainty and efficiency of known vulnerability submissions.

[0041] (2) By introducing reverse static filtering and function-level differential semantic compression mechanism, this invention significantly reduces the interference of irrelevant files, invalid contexts and ordinary code noise on the model input, making the model more focused on key security semantics such as permission check changes, verification logic changes, boundary processing changes and resource lifecycle changes.

[0042] (3) By introducing a lightweight call relationship representation, this invention provides local call relationship support for code patch analysis without performing full program-level static analysis, thus balancing analysis cost and security semantic expression capabilities.

[0043] (4) By introducing a constrained large model structured analysis mechanism, the present invention enables different submitted analysis results to be output in a unified field form and directly compared, retrieved and verified, thereby improving the consistency, parsability and reproducibility of the results.

[0044] (5) By introducing a model-isolated result storage and failure retry control mechanism, this invention avoids state pollution and result overwriting between different model analysis results, and prevents failed tasks from continuously occupying resources during batch processing, thereby improving the stability of the system in long-term batch operation. Attached Figure Description

[0045] Figure 1 This is the overall flowchart of the method of the present invention;

[0046] Figure 2 This is a system architecture diagram of the present invention;

[0047] Figure 3 This is a schematic diagram of the various functional modules of the system of the present invention and their functions. Detailed Implementation

[0048] The present invention will be further illustrated below with reference to specific embodiments. These embodiments are implemented based on the technical solutions of the present invention, and it should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0049] Example 1

[0050] This embodiment provides an intelligent analysis method for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting, specifically including the following steps:

[0051] S1. Obtain AOSP code commit data: Perform incremental updates on the AOSP source code repository and extract the committed code;

[0052] like Figure 1 As shown, in this step, the AOSP code repository is synchronized, the target code repository is synchronized using repo, and the extraction and patch acquisition are performed based on git, log, git show, extraction, and commit hash, message, and diff code.

[0053] Incremental updates and code extraction for commits include: performing repo-level incremental updates on the AOSP repository and identifying multiple Git sub-repositories in the corresponding directory; performing a time-window-bound git log search for each sub-repository to obtain the commit hash, author, commit date, and commit message; and then performing git show code extraction for each commit, retaining only the code body starting with diff--git as input for subsequent analysis.

[0054] Furthermore, the specific implementation process of S1 is as follows: First, in the root directory of the AOSP repository, initialize the specified branch to be tracked (denoted as this branch). Then, N concurrent tasks (where N is the number of parallel synchronization tasks) are started to force synchronization of the latest code in the current branch and detach the head pointer. After synchronization is complete, a complete list of paths for all projects in the repository is extracted, and the overall integrity of the project directory is verified accordingly.

[0055] Then, the valid Git sub-repositories are identified and a set of sub-repositories is constructed by traversing the frameworks directory. ,in, Let represent the k-th sub-repository (k = 1, 2, …, K) in set R, where K is the total number of valid Git sub-repositories identified in this instance; let the current date be . The set back date is (Default value is) The starting point of the time window is defined as... .from Starting with each sub-repository in the set, its historical commit records are retrieved, and relevant metadata is extracted in a structured manner, including: commit hash, author name, author email, commit date, and commit description.

[0056] For each commit, further extract its original complete change patch and filter it using a function. The process involves cleaning, retaining only the patch body containing the differences in standard code additions and deletions as input for subsequent analysis. Then, the analysis will be conducted using the following information: repository path, author, email, date, message, patch body, and initial analysis status (recorded as status value). The tuple consisting of ")" is incrementally written to the corresponding database table; if a record with the same commit hash value already exists in the database, the uniqueness constraint is triggered and the insertion is ignored.

[0057] When performing the version control retrieval operation described above, if the system throws a security exception indicating questionable directory ownership, it generates a normalized path set for the current repository path, including local absolute paths and Uniform Naming Convention (UNC) variants. Then, this path set is sequentially registered and appended to the system's secure directory whitelist configuration, and the previous operation is automatically retried, thereby ensuring the continuous analyzability of the AOSP repository in network sharing or Samba directory mounting scenarios.

[0058] S2. Perform differential structure parsing on the submitted code to obtain the set of changed files, the set of code blocks, and addition / deletion statistics;

[0059] Differential structure parsing includes: using differential file matching rules to identify the original file path and new file path of the commit; using code block header parsing rules to extract the original starting line number, new starting line number, modification range and context header information of each code block; and generating the number of commit-level files, the number of code blocks, the number of added lines and the number of deleted lines based on the statistics of added and deleted lines within the code block.

[0060] Furthermore, the specific rules for matching differential files in S2 are as follows: The body of the code patch is scanned line by line, and a specific regular expression is applied to match each line of text that begins with a standard difference identifier (such as the string "diff--git" in the text). Specifically, the following settings are configured: For the code before submission, This is the code after submission. Through matching and extraction, the first capture group is mapped to the original file path. The second capture group corresponds to the new file path. This constructs a file-level change set F={(oldpath)} j ,newpath j )}.

[0061] The code block header parsing rule in S2 is as follows: For each line of text starting with a double symbol (such as @@), apply the corresponding regular expression. This expression can precisely capture the following parameters in sequence: the starting line number of the original file. Number of lines changed in the original document New file starting line number Number of lines changed in the new document and code block context header information (The default number of rows here is) ), thereby constructing a set of code blocks H={hunk t}

[0062] During the parsing process, only lines that begin with "+" but not "+++" are identified as new lines A. t Lines that begin with "-" but do not start with "---" are identified as lines to be deleted (D). t Then, the commit-level statistic is calculated using the following formula: Number of changed documents N files =|distinct(F)|, number of code blocks N hunks =|H|, increase the number of rows N add =Σ t |A t |, Number of rows deleted N del =Σ t |D t The `distinct()` function is used to remove duplicate elements from the input set. This prevents the same file from being recorded multiple times in a patch (e.g., when the same file contains multiple code blocks), thus avoiding duplicate counting of changed files.

[0063] like Figure 1 As shown, in this step, structured parsing is performed on the code text to parse and identify changed file paths, chunk code block header information, original starting line number, new starting line number, modification range, and added / deleted line statistics, thereby obtaining the number of commit-level files, the number of code blocks, the number of added lines, and the number of deleted lines, providing a structural foundation for subsequent reverse static filtering and function-level semantic compression.

[0064] S3. Pre-processing of known vulnerability submissions: Based on the vulnerability knowledge base, perform submission hash matching and directly write submissions that match known CVE mapping relationships into the security result database.

[0065] The submission hash matching based on the vulnerability knowledge base includes: loading the announcement date range, CVE number, severity, announcement date, and submission hash mapping relationship from the vulnerability knowledge base; performing case-insensitive matching on the submission hash of the submission to be analyzed; when one or more CVE numbers are matched, the severity levels are merged to generate a set of CVE numbers, severity levels, and announcement dates corresponding to the submission, and this set is directly written into the security results database as a known secure submission in the form of a known vulnerability submission, without entering the subsequent deep analysis chain.

[0066] Furthermore, the specific implementation process of S3 is as follows: First, a set of vulnerability entries is obtained by parsing the official Android security bulletin page. Each entry can be represented as a six-tuple, which contains the set of fix submission hashes corresponding to the vulnerability (denoted as...). The above entries are persisted to the vulnerability knowledge base table, with the primary key set as a tuple consisting of the CVE number and the submission hash. This supports a many-to-many mapping relationship where one CVE corresponds to multiple fix submissions. The commits to be analyzed are executed using a case-insensitive matching function, the mathematical expression of which is as follows:

[0067]

[0068] in, This represents the hash value of the current code commit to be analyzed. This represents the triple representing the known vulnerability metadata returned after a match is found: ,in, This indicates the CVE number corresponding to the submission in the Android security bulletin. This indicates the severity of the vulnerability as assessed by the official authorities. This indicates the official release date of the Android security bulletin to which the vulnerability belongs; This represents the set of hashes of all known fix submissions corresponding to this vulnerability in the vulnerability knowledge base, while This indicates a specific known hash value within the set; This represents a normalized processing function that converts a string to lowercase. The formula introduces an existential quantifier (...). )and This function aims to achieve case-insensitive, precise table lookup matching, thereby effectively avoiding the underreporting of known vulnerabilities caused by inconsistent case formats of hash strings in different data sources.

[0069] When the matching result set If the value is not empty, the submission is considered a known vulnerability submission.

[0070] When a single match returns multiple severity levels, the level mapping function φ is used. sev Perform merge: φ sev (Critical)=4, φ sev (High)=3, φ sev (Moderate)=φ sev (Medium)=2, φ sev (Low)=1; Severity SEV after merging merged The one who gets the highest score, i.e. The Critical (meaning the most severe vulnerability with the widest impact and most serious consequences, such as remote exploitation to execute arbitrary code, breach device security sandboxes, or cause permanent device failure) and High (meaning a high level of vulnerability severity, such as local privilege escalation, bypassing user authorization to access sensitive data, or causing critical function malfunctions) are uniformly grouped into "high". Moderate (meaning a medium level of vulnerability severity, such as being exploitable under certain conditions to leak non-sensitive information, cause denial-of-service attacks, or bypass lower-level protection) and Medium (meaning a medium level, an equivalent of Moderate in some historical announcements or third-party vulnerability databases, which this invention treats uniformly with Moderate) are uniformly grouped into "medium". All others are marked as "unknown". Finally, the submitted metadata, CVE number set, and merged severity levels are combined. The announcement date set is directly written into the security results database and will not be included in subsequent in-depth analysis. Low indicates a low level of vulnerability severity, corresponding to situations where it can only be exploited in extremely restricted scenarios and will not cause substantial security consequences.

[0071] like Figure 1 As shown, in this step, CVE association matching is performed, and hash matching vulnerability knowledge base is submitted. If a match is found, the security result is directly mapped. It is then determined whether a known CVE is matched. If not, the known vulnerability is directly archived and written to the security result database. If it is matched, then S4 is executed.

[0072] S4. Perform reverse static filtering on submissions that do not hit known CVEs, and only send submissions that meet the security analysis conditions into the deep analysis link.

[0073] Reverse static filtering includes: checking whether the submission already exists in the secure or insecure result library corresponding to the current model; if it already exists, skip it directly; when there is no analyzed record in the submission, determine whether the changed file is empty; if the changed file is not empty, further determine whether all the changed files belong to the preset non-core file type, and make a joint judgment by combining the submission message and the corresponding secure submission information in the diff content; when all the changed files are non-core files and there is no secure submission information, the submission is determined not to enter the deep analysis link.

[0074] like Figure 1As shown, this step involves deduplication, empty submission removal, non-core file filtering, and joint security information determination. It then determines whether in-depth analysis is needed; if not, it archives / skips the submission in different databases; otherwise, it executes step S5. Specifically: For submissions that do not match known vulnerability mappings, it first checks whether analysis records already exist in the security result database and non-security result database corresponding to the current model. If they do, it skips the submission; if not, it checks whether the changed file is empty; if the changed file is not empty, it further determines whether all involved files belong to the preset non-core file type; if all changed files are non-core files, it performs a joint determination based on the security information in the submission message and code text; if the determination is unrelated to security, the submission does not need to enter the in-depth analysis process.

[0075] Furthermore, the reverse static filtering mechanism in the S4 stage is implemented through a cascaded combination of four decision functions:

[0076] (1) The analytical decision function (denoted as) ): When the model This function returns true if the record for the current submission already exists in the corresponding secure or insecure result database;

[0077] (2) Empty change determination function (denoted as) When the set of changed files is an empty set (i.e.) When the condition is met, the function returns true;

[0078] (3) Non-core file determination function: Set the preset set of regular expressions for non-core files as follows: (Including but not limited to .md, .txt, .rst, image files, style sheets, configuration files, and README* files, etc.). Define a non-core function for determining the validity of a single file as follows: Therefore, the function for determining purely non-core files within the entire change set is defined as follows:

[0079]

[0080] in, This represents a "pure non-core file determination function" that operates on the entire set of changed files in a single commit, and its value is a boolean; it determines whether a change occurs if and only if all changed files in the set have new file paths. All were When determined to be a non-core file, Returns true, otherwise returns false.

[0081] (4) Safety signal determination function: Set the predefined set of key safety signal words as follows Specifically:

[0082]

[0083] in, This represents authentication-related code, used to identify modifications involving authentication logic; These are permission-related codes used to identify modifications involving the Android permission model, permission checks, and authorization decisions. This indicates cryptography-related codes used to identify modifications involving encryption / decryption algorithms, key management, and signature verification. This indicates overflow-related code, used to identify modifications that involve memory safety issues such as buffer overflows and integer overflows; The memory copy function is a common memory operation primitive in C / C++ that can potentially cause buffer overflows. The string copy function is a common string manipulation primitive in C / C++ that can potentially cause buffer overflows. This indicates sandbox-related code, used to identify modifications involving isolation mechanisms such as process isolation, SELinux domains, and application sandbox boundaries; This represents the user identifier, used to identify modifications involving the identity and permission boundaries of an application / process in the Android system.

[0084] Define the current commit message as The main patch is Then the mathematical expression of the decision function is:

[0085]

[0086] in, This represents the joint decision function for security signals, whose purpose is to check the commit message. With the main patch Does it contain any of the keywords from the aforementioned set of security-related keywords? This represents a set of key security signal words; This indicates the concatenation of strings. This indicates a normalized function for converting to lowercase. This indicates a substring inclusion relationship. That is, the function returns true if any security key signal word exists in the concatenated lowercase text.

[0087] Based on the above judgment conditions, the logical expression of the final decision function of reverse static filtering is:

[0088]

[0089] in, This is a final decision flag indicating whether the current submission should enter the subsequent in-depth analysis chain. It takes the value of Boolean. When it is true, the submission will be sent to the large model structured analysis stage. When it is false, it will directly enter the result routing branch without consuming the model call budget. This indicates the analysis and judgment function, which determines whether the submission has been analyzed by the current model in the previous run. If it is, it returns true; otherwise, it returns false. This represents the empty change determination function, which determines whether the set of change files F corresponding to the commit is empty. If it is, it returns true; otherwise, it returns false. This represents a function for determining whether all changed files in a commit are non-core files. This represents a joint security signal determination function, which determines whether security-related keywords exist in the submitted message and patch content.

[0090] When decision variables If the evaluation is true, the system will determine that the submission has further review value and thus enter the in-depth analysis link; otherwise, the filtering mechanism will be triggered directly, and the submission will be introduced into the result diversion branch.

[0091] S5. Execution function level differential semantic compression: Accurately extracts and compresses the call relationship representation of the submitted execution function level differential context entering the deep analysis link to generate a compact semantic context;

[0092] Accurate extraction of function-level differential context includes: identifying function names from the header information of each code block; when the function name cannot be directly identified, backtracking to identify valid context identifiers in the code block header; retaining only the modified lines in the code block that begin with an add or delete marker to form a function-level differential context; and simultaneously recording the file to which it belongs, the function name, the code block header, and the set of modified lines, and combining this with commit-level statistics to construct a compact semantic carrier.

[0093] The call relationship compression representation includes: extracting call names from each function-level differential context and constructing a lightweight call graph; encoding the commit message, commit statistics, function-level differential context, and lightweight call graph into a compact JSON context, and truncating the input when the length exceeds a preset character threshold.

[0094] Constructing a lightweight call relationship representation: Based on the function-level difference context, the call names in the modification region are extracted in a regularized manner, and a lightweight call relationship graph is constructed with the current function as the starting point and the set of call names as the ending point; when the number of call targets exceeds a preset threshold, only a portion of the representative call nodes are retained to control the graph structure size and model input length.

[0095] Furthermore, the specific implementation process of S5 is as follows:

[0096] (1) Fine extraction of function definition and hard truncation of differential context line number: First, for each code block, the differential code block header information (Header) is extracted. The system uses a predefined regular expression to extract a list of matching candidate declarations. Since the code block header may contain multiple levels of complex nested declarations, the system extracts the last item in the candidate declaration list as the identifier for the currently modified function. .

[0097] If the first regular expression fails to match, the system automatically executes a fallback mechanism: adjusting the header information of the differential code block according to whitespace. Perform word segmentation and extract the last non-empty tag object from the list of segmented word tags as the identifier name for the change function. If the function still cannot be recognized after word segmentation, the function identifier name will be changed. Assign a default unknown flag .

[0098] Subsequently, in order to avoid interference from irrelevant context on the subsequent analysis of large models, the system constructs a differential context tuple for each code block. Its mathematical formal definition is:

[0099]

[0100] in, This indicates the target file path to which the current change belongs. This indicates the change of the function identifier name, which is the one extracted above; This represents the header information of the differential code block, while This represents the set of valid change lines after purification. The construction of the valid change line set... At that time, the system traverses the entire code block, strips out all context base lines that have not undergone substantial code modification, and retains only the lines that have undergone substantial modification, with the first character being either the addition symbol "+" or the deletion symbol "-".

[0101] To prevent long-tailed, malformed patches or extensive code formatting adjustments from causing a large number of symbols and creating a large model illusion or even leading to analysis crashes in subsequent stages, the system implements a hard truncation constraint on the size of the effective change row set: when the number of elements in the effective change row set... When the following conditions are met:

[0102]

[0103] in, Modify the preset threshold for the maximum number of rows for a single function (the default configuration in this embodiment is...). (line), the system automatically sets the valid change lines. The truncation interception is performed in the original line-by-line order, retaining only the first few lines. Make modifications to eliminate redundant noise in the context at the source.

[0104] (2) Lightweight local call graph construction: After the code purification is completed, in order to capture the key cross-function call semantics, and at the same time prevent the traditional full control flow graph from causing graph node explosion and high-time analysis failure when facing complex patches, the system establishes a lightweight local call graph construction mechanism oriented towards change lines.

[0105] Specifically, for the set of valid change rows in each function-level difference context. The system uses a pre-defined second regular expression to precisely extract function call behaviors, generating a candidate set of calling functions. To control the breadth and scale of the call topology and eliminate the impact of call loops on inference, the system first removes recursive self-calling nodes from the candidate set of calling functions (i.e., removes nodes that satisfy the condition that the call name equals...). (The elements), then the remaining valid call names are forcibly sorted lexicographically, and only the first few are truncated. One invocation target (the default configuration in this embodiment is 1) (each of these) is used to assemble the final set of deduplication call functions. .

[0106] Based on the extracted local topology nodes, the system constructs a lightweight local call graph specifically centered around the currently modified line of code. Its formal mathematical definition is:

[0107]

[0108] in, Represents a set of nodes; Represents an edge set.

[0109] Node set Explicitly defined as the union of the currently modified function identifier name and the truncated set of external call functions, specifically:

[0110]

[0111] Edge set Defined as the set of directed edges pointing from the current modification function to each external target calling function, specifically:

[0112]

[0113] in, 1 represents the set of call names Any of the called function names in the current modified function An external function called within its modified line of code; each tuple Indicates a line from point to The directed call edges, with the direction pointing from the caller to the callee, construct a local function call relationship graph near the patch modification area.

[0114] This lightweight local call graph effectively compresses the traditional macroscopic full call graph into a compact word-typical call relationship topology with low computational overhead, while retaining the semantics of the core call chain and completely avoiding the risk of failure in building complex dependency graphs.

[0115] (3) Input assembly and global overflow prevention control: Finally, the system will submit the original commit message. The submission-level attribute statistics calculated by S2 Functional level difference context set and the constructed lightweight local call graph They are uniformly serialized and encoded, and assembled into a compact context carrier object. To further reduce the overall context volume, the function-level difference context set... Only extract the first part according to the original extraction order. The record is as follows:

[0116]

[0117] in, This represents the object serialization function, which serializes the structured JSON object payload, consisting of the commit message, commit-level statistics, function-level difference context set, and lightweight call graph, into a plain string in JSON text format so that it can be used as the text input for the downstream large model; it performs truncation when its output length exceeds the preset limit. Represents the function-level difference context set The first in Each element corresponds to a quadruple context extracted from the code block. , , , ),in, The file path to which this code block belongs, To change the function identifier name, For code block context header, This is a sequence of modified rows that only retain newly added and deleted rows.

[0118] In the compact context carrier object Before the intelligent analysis engine for large models with constraints across network inputs, the system implements global overflow prevention control and interception, and performs real-time calculations on the carrier objects. Serialized string character length Once it meets the following over-limit triggering conditions:

[0119]

[0120] in, The preset global input character length hard threshold (in this embodiment, the advanced configuration item is set to...) (Characters), the system will force a hard truncation operation on the end of the serialized string, directly discarding the character segment that exceeds the threshold.

[0121] This global overflow prevention mechanism ensures that the data size entering the large model intelligent analysis engine is strictly limited, fundamentally eliminating the large model context window overflow crash caused by abnormally long patches, and achieving highly available, highly noise-resistant compact semantic context output.

[0122] like Figure 1 As shown, in this step, function-level differential context is extracted, retaining only the added, deleted, and modified rows and identifying the function context to construct a lightweight call graph.

[0123] S6. Generate structured code input and perform large model analysis: Input the compact semantic context into the constrained large model structured analysis engine and output the security issue type, severity, issue description, cause, availability and test hints.

[0124] The commit hash, commit date, commit message, commit statistics, function-level differential context, and lightweight call relationship representation are encoded into a compact structured context; truncation and compression are performed when the context length exceeds a preset threshold; the context is then input into a constrained large model analysis engine, which requires the model to output structured fields such as whether it constitutes a security issue, issue type, severity, issue description, issue cause, availability, and test hints.

[0125] The constrained large-model structured analysis engine includes: pre-built system prompts for Android AOSP, Linux, and system security analysis; requiring the model to reason about vulnerability remediation, permission boundaries, verification logic, memory safety issues, process boundaries, and security policy changes, and forcing the output of JSON structured results; inputting the large model with submission hashes, dates, and compact semantic context as user prompts; and marking the analysis as a failure when the model's returned content cannot be parsed into a JSON object.

[0126] Furthermore, the specific implementation process of step S6 is as follows:

[0127] (1) Construction and parameter configuration of the constrained large-scale model structured analysis engine: The "constrained large-scale model" of this invention is not a single base model trained from scratch end-to-end, but a general-purpose large language model with deep code semantic understanding capabilities (including but not limited to general models such as GPT-4o, Claude Opus4, and Claude Sonnet 4). On the client side, a unified instant messaging call interface is abstracted and encapsulated so that the backend can hot-swap different underlying models according to policy requirements. The analysis engine uses multiple external control mechanisms such as prompt word constraints, sampling parameter constraints, output parsing constraints, and dynamic analysis plugin hooks to jointly shrink the open generation space of the general model into a structured judgment space for AOSP security patch analysis, thereby obtaining security analysis results with high consistency, high parsability, and high reproducibility at low computing power cost.

[0128] During the analysis and invocation phase, the system first initializes and configures the inference parameters of the constrained large-scale model structured analysis engine. To suppress the creative divergence and potential illusions inherent in large language models, and to ensure the determinism and logical rigor of the secure inference results, the system establishes strict inference boundary constraints. Specifically, the model's generation sampling temperature parameter is formally set as follows: The maximum number of tokens generated in a single instance is the threshold. And turn off streaming mode (i.e., set) ).

[0129] (2) System prompt word constraint construction: Three types of strong constraint rules are explicitly embedded in the system prompt words, namely: role qualifier: forcibly anchoring the target entity identity of the model as "Android AOSP / Linux / System underlying system security expert"; reasoning scope qualifier: forcing the model to perform deep semantic reasoning only around specific security multidimensional attributes such as control flow changes, vulnerability introduction and repair mechanisms, permission boundary verification, input validation logic defects, memory security (including memory overflow, use of UAF after release, array out of bounds), process boundaries, and system security policy changes; output format and semantic constraint: explicitly defining a strict structured object schema (JSON Schema) protocol, forcing the model to output only pure key-value pair structured objects. In addition, two complete few-shot learning examples (i.e., including a standard positive security repair example and a reverse non-security conventional repair example) are explicitly embedded in the system prompt words to regulate the model's context compliance.

[0130] (3) User prompt word constraint construction: For the current target submission to be analyzed, the compact semantic context output from step S5 is assembled into a text serialization. Its formal string concatenation formula is defined as:

[0131]

[0132] in, This function represents the sequential concatenation of multiple strings. This indicates the unique hash identifier value to be analyzed and submitted. Indicates the date and timestamp of the current submission. This represents the compact semantic context carrier object output after being truncated by global overflow prevention control in step S5. This refers to the user prompt sent to the constrained large model. It is a text string composed of a commit hash, commit date, and compact semantic context concatenated in a fixed template order. Its function is to provide the model with all the necessary contextual input for the current commit to be analyzed, in conjunction with the system prompt. (Used to inject role limitations, reasoning scope and output format constraints) Combined together, they constitute the complete reasoning input of the model.

[0133] During the analysis phase, the analysis engine calls the large model inference interface in an asynchronous thread, inputting a message sequence consisting of system prompts and user prompts. To avoid worthless submissions consuming the model budget, for submissions that are determined by S4 reverse static filtering to not require deep analysis (should_analyze is false), the analysis engine directly classifies them as non-security issues, records the filtering reason, and skips the model call.

[0134] (4) JSON Structured Output Parsing and Failure Determination: The analysis engine uses a two-level parsing strategy to extract structured results from the text returned by the model. First, it attempts to directly parse the entire returned text into a JSON object. If direct parsing fails, it then uses regular expressions to match the first substring enclosed in curly braces in the returned text and attempts to parse it. The model call is considered successful only if the parsing result is a valid JSON object (dictionary structure) (llm_success is true); otherwise, the analysis is considered to have failed (llm_success is false), the reason for failure is recorded, and a preset default result is used as a placeholder (problem type is error, security question is false) for S7's failure retry control. The parsed structured fields include at least: whether it constitutes a security issue (is_security_issue), issue type (issue_type), severity, issue description, cause, exploitability, and test hint. When the issue type is matched to none, no, false, or null by standardization, the security issue is forcibly corrected to false to eliminate any inconsistencies that may occur between the fields in the model.

[0135] (5) Dynamic Analysis Plugin Enhancement: After obtaining the structured results of the model, the analysis engine further loads the dynamic analysis plugins in the analyzer script directory and executes them one by one. Each plugin takes the current submission status and model results as input and can return several fields to patch or overwrite the model results. When a plugin fails to execute, it is ignored and subsequent plugins continue to be executed to ensure that the analysis process is not interrupted by a single plugin. Thus, the constrained large model structured analysis engine can extend customized analysis capabilities for specific vulnerability families or specific subsystems without changing the main reasoning process. Finally, it outputs security analysis results with a unified field structure and records the model identifier used for verification and database storage by S7.

[0136] S7. Execution result verification, distributed entry into database and failure retry control: Perform field integrity verification on the structured analysis results, and write submissions with security issues and those without security issues into mutually isolated result databases according to the model identifier.

[0137] Perform structural integrity checks on the model output; when a security issue is identified, write the submission information, set of changed files, compact semantic context, lightweight call relationships, and analysis results to the security result library corresponding to the current model; when a non-security issue is identified, write the corresponding results to the non-security result library corresponding to the current model; when the model's returned content cannot be parsed or key fields are missing, record the current number of retries; when the number of retries has not reached the threshold, retain the pending status; when the threshold is reached, mark the submission as permanently failed and remove it from the pending queue.

[0138] The structured results should include at least: whether it constitutes a security issue, the type of issue, the severity, the issue description, the cause of the issue, the availability, and test hints; and allow for patching or overwriting of the output of the large model through dynamic analysis plugins to form the final security analysis results.

[0139] Field integrity verification and result persistence include: performing non-empty checks on fields such as issue type, severity, issue description, issue cause, availability, and test hints; when an issue is determined to be a security issue, the commit information, change file set, lightweight call graph, compact semantic context, patch content, and verification error information are written to the security result database corresponding to the current model; when an issue is determined to be a non-security issue, the corresponding information is written to the non-security result database corresponding to the current model; different models use independent database paths and independent analysis status column names after model name security processing.

[0140] Failure retry control includes: recording the current number of retries for submissions that have entered the deep analysis chain but failed to call the large model; when the number of retries is less than a preset threshold, only updating the number of retries and retaining the pending status; when the number of retries reaches the preset threshold, marking the submission as permanently failed and removing it from the pending queue to avoid the batch processing engine repeatedly fetching the same failed submission and causing blockage.

[0141] Furthermore, the specific implementation process of S7 includes three stages: field integrity verification, database sharding persistence isolated by model, and three-state control for failure retry.

[0142] (1) Field Integrity Validation: For the structured results output by S6, perform non-empty validation on each required field (such as issue_type, severity, cause, exploitability, etc.). If the string after removing leading and trailing whitespace is empty, add an error flag to the validation error set. After the validation is completed, the error set is transmitted along with the status and used as the validation error information field when storing in the subsequent database sharding; this validation only records the field missing situation and does not block the database entry, so as to retain the problem traces without affecting the overall batch processing progress.

[0143] (2) To completely avoid state contamination and analysis result overwriting caused by minor deviations in field definitions between heterogeneous models during parallel testing or parallel switching of different large models, the system implements a multi-model sandboxing physical isolation persistence mechanism. Specifically, the system dynamically obtains the identifier name string of the large model executing secure inference in the current round and performs secure desensitization and replacement processing on it: using preset regular expression rules, all non-alphanumeric characters in the model name string are uniformly replaced with underscores, thereby constructing a unique secure model identifier. Based on this security model identification During persistent scheduling, the system dynamically generates a dedicated physical storage path for the current model's database, which includes a dedicated secure results repository path. and insecure result library paths Furthermore, to eliminate the discrepancy in severity representation among different underlying large-scale models, the system introduces a severity level normalization mapping function before data entry and statistical analysis. Its formal mathematical definition is:

[0144]

[0145] in, This represents the final severity level label output after normalization mapping; This represents the raw severity string directly output by the underlying large model, without any normalization processing; The normalized severity rating is "critical," corresponding to the original output containing the word "critical," indicating that the vulnerability has the widest impact and the most severe consequences. The normalized severity level label "high risk" corresponds to the original output containing the word "high", indicating that the vulnerability can cause high harm such as local privilege escalation and sensitive data leakage; The normalized severity rating is "medium," corresponding to the case where the original output contains the word "medium," indicating that the vulnerability can be exploited under certain conditions to cause moderate harm. Another common way to express that the original output is equivalent to "medium risk" (this term is used in some models and announcement systems). This invention classifies it and "medium" into the "medium" level. The normalized severity level label "low risk" corresponds to the case where the original output contains the word "low", indicating that the vulnerability can only be exploited in limited scenarios and will not cause substantial security consequences. This indicates the "unknown" level after normalization, corresponding to situations where the original output is empty, does not match any of the above level keywords, or the model fails to provide a valid severity judgment. It is used to ensure that the field is required while explicitly marking uncertain results.

[0146] By normalizing the mapping function The severity of the original blur output from the large model The unified convergence standard greatly facilitates subsequent cross-database retrieval, horizontal comparison, and manual cross-verification of results from multi-track analysis of heterogeneous models.

[0147] (3) Three-state control for retrying failures: For submissions that have entered the deep analysis chain (should_analyze is true) and have initiated a model call (llm_attempted is true) but the call failed (llm_success is false), they are considered retryable failures. Let the current number of retries be r and the preset retry threshold be r. (The default value is 3), then the updated number of retries is r' = r + 1. When r' is less than When r' reaches or exceeds a certain threshold, the data to be analyzed in this round remains in a pending state so that the next batch of processing can continue to retrieve the submission for retry; when r' reaches or exceeds a certain threshold, the data to be analyzed in this round remains in a pending state so that the next batch of processing can continue to retrieve the data for retry. If the system determines that the current data cannot be analyzed, it enters a permanent failure state, thus removing the data from the processing queue. This prevents the batch processing engine from repeatedly fetching the same failed submission, which could lead to data retrieval stagnation or deadlock. In the three-state control, state 0 indicates pending analysis or retry, state 1 indicates analysis completed and data stored, and state 2 indicates permanent failure. These three states are distinct to ensure that failed tasks do not continuously occupy analysis resources during long-cycle batch processing.

[0148] In this embodiment, the method organizes each analysis stage using a workflow orchestration approach. First, a directed state flow-based workflow orchestration framework is used to connect and schedule each node, enabling submissions to automatically flow between different analysis stages according to predetermined conditions.

[0149] In this embodiment, the workflow entry point first extracts the set of submissions to be analyzed, and then sequentially connects to the differential parsing node, the known vulnerability pre-identification node, the reverse static filtering node, the function-level semantic compression node, the lightweight call relationship construction node, the structured analysis node, the result verification node, and the result storage node. The reverse static filtering node determines whether a submission directly enters the result routing branch or the deep semantic analysis branch based on whether the submission has further analytical value. This forms a multi-level routing mechanism of "deterministic identification first, deep analysis later." This overall technical approach is completely consistent with the workflow orchestration, pre-identification, reverse static filtering, function-level fine extraction, structured analysis, database storage, and failure control in the original document.

[0150] In this embodiment, the system first performs an incremental update on the AOSP code repository and identifies multiple Git sub-repositories in the target directory. For each sub-repository, the system performs a commit retrieval based on a preset time window, extracting the commit hash, author, date, and commit message. Then, it performs code extraction, retaining only the differential body starting with `diff--git` as the object for subsequent processing. This allows for unified extraction of code data in a multi-repository environment, avoiding the mixing of irrelevant log information into the subsequent analysis context.

[0151] In this embodiment, the system performs differential structure parsing on the submitted code, identifying the original file path, new file path, code block header, original starting line number, new starting line number, and the range of added and deleted lines, and counts the number of commit-level files, code blocks, added lines, and deleted lines. The results of differential structure parsing are used to support the pre-identification of known vulnerabilities and reverse static filtering, and also to provide structural boundaries for function-level differential semantic compression.

[0152] In this embodiment, the system performs pre-identification of known vulnerabilities before in-depth analysis. Specifically, the system loads the announcement date range, CVE number, severity, and commit hash mapping from the vulnerability knowledge base, and performs case-insensitive matching on the commits to be analyzed. When one or more CVE records are matched, the system merges the severity levels and directly writes the commit as a known secure commit into the security results database, without proceeding to the subsequent large-scale model analysis stage. This approach moves the knowledge base mapping forward, allowing the limited model budget to be concentrated on unknown commits.

[0153] In this embodiment, for submissions that do not match the knowledge base, the system further performs reverse static filtering. The system first queries the security result library and non-security result library corresponding to the current model. If the submission has already been analyzed, it is skipped directly; if it has not been analyzed, it determines whether there are valid modified files; if there are valid modified files, it further determines whether all modified files belong to the preset non-core file type; if so, it combines the security information keywords in the submission message and code text for joint judgment, and only continues subsequent analysis when there are obvious security signals. This mechanism is not a simple keyword whitelist, but a joint screening method of "duplicate removal - empty submission elimination - non-core identification - security signal fallback".

[0154] In this embodiment, the system performs function-level differential semantic compression on the filtered submissions. The system extracts the function name from the header of each code block; if the function name cannot be directly identified, it falls back to using the last valid identifier in the code block header as the function context. Subsequently, the system retains only newly added and deleted lines starting with "+" or "-" within the code block, omitting ordinary context lines, thus obtaining differential semantic fragments oriented towards function modifications. For each function-level differential fragment, the system further records its file, function name, code block header, and set of modified lines, and encodes these together with submission-level statistics into a compact context. This allows the original high-noise diff to be compressed into a semantic carrier more conducive to model inference.

[0155] In this embodiment, the system constructs a lightweight call relationship representation based on function-level differential fragments. Specifically, the system extracts call names appearing in the function body using call matching rules, and constructs local call relationships starting from the current function and ending with the set of call names. Unlike full-program static analysis, this lightweight call relationship does not pursue complete semantic closure, but emphasizes supplementing local security relationships near the committed code at a lower cost, making the model more likely to identify security-related changes such as permission check calls, boundary check calls, and resource release calls.

[0156] In this embodiment, the system inputs a large model analysis engine constrained by submission hashes, submission dates, and a compact semantic context. Model hints pre-limit its reasoning around vulnerability remediation, permission boundaries, verification logic, memory safety, process boundaries, and security policy changes, and force the output of structured results in JSON format. The structured results include at least: whether it constitutes a security issue, issue type, severity, issue description, issue cause, exploitability, and testing hints. If the model's returned content cannot be parsed into a JSON object, the analysis is marked as failed. Dynamic analysis plugins can also be used to patch or overwrite the model results to adapt to the engineering needs of specific vulnerability families and subsystems.

[0157] In this embodiment, after the model returns results, the system performs integrity checks on fields such as problem type, severity, problem description, problem cause, availability, and test prompts. When a problem is determined to be a security issue, the relevant results are written to the security result database corresponding to the current model; when a problem is determined to be a non-security issue, the results are written to the non-security result database corresponding to the current model. Unlike the multi-model result co-storage method, this embodiment generates a secure model identifier based on the model name and establishes an independent database path, an independent analysis status column, and an independent retry count column based on this identifier to avoid state contamination and result overwriting between different models.

[0158] In this embodiment, for a submission that enters the deep analysis chain but fails to call the model, the system records the current number of retries. When the number of retries does not reach the preset threshold, only the number of retries is updated and the pending status is retained. When the threshold is reached, the submission is marked as permanently failed and removed from the pending queue to prevent failed tasks from being repeatedly captured in the batch processing chain and causing blockage.

[0159] In this embodiment, for scenarios where the AOSP repository is located in a network shared directory or Samba directory, if Git returns a questionable error regarding repository ownership, the system automatically generates a standardized representation and a UNC variant representation of the repository path, writes them into the safe.directory configuration, and then retryes executing the Git command to ensure that the automatic analysis process can continue to run in a shared directory environment.

[0160] In summary, this invention forms an intelligent analysis link for AOSP security patches that starts with pre-identification, uses reverse filtering and function-level differential semantic compression as its core, employs structured large model analysis as its judgment method, and relies on distributed storage and failure control as stability guarantees. It is suitable for AOSP patch security analysis scenarios involving multiple warehouses, batches, and long cycles.

[0161] This invention targets commit records in the AOSP code repository, employing a stateful process orchestration technique based on LangGraph. It organizes commit parsing, candidate filtering, differential context extraction, model identification, result verification, and result archiving into a schedulable directed state graph. CVE association matching technology directly maps known vulnerability commits to a security result database. For other commits, reverse static filtering removes document-type, interface-type, and duplicate analyzed commits, improving the identification efficiency of candidate security remediation commits. For commits that pass filtering, differential structure parsing and function-level context extraction are further employed, combined with regularized function identification and lightweight call graph construction to generate a compact semantic context. Subsequently, constrained large-model security patch analysis is used to output structured results such as vulnerability type, severity, cause, exploitability, and test hints under preset security analysis prompts. Finally, result verification, model-isolated dual-database persistence, and failure retry control techniques are used to complete the database storage of analysis results.

[0162] To verify the beneficial effects of the technical solution of this invention, this application conducted actual operation and manual verification of the method and system on a real AOSP code repository. The results show that the method can run stably in AOSP submission scenarios with multiple repositories, batch processing, and long cycles, and completes the end-to-end processing flow from incremental submission acquisition, differential structure parsing, prior identification of known vulnerabilities, reverse static filtering of unknown submissions, function-level differential semantic compression, structured large model analysis to result sharding and storage. Finally, the identified security patches are written into the security result library of the corresponding model in a structured form, and submissions without security significance are written into the insecure result library. The two are isolated from each other and do not contaminate each other.

[0163] Regarding the accuracy of known vulnerability identification, this method correctly discovered and archived multiple publicly disclosed security patches, such as CVE-2025-32328, CVE-2025-48573, CVE-2025-48572, CVE-2025-48580, and CVE-2025-32323. The identification results were verified on a real physical device, confirming that the security issues and remediation actions corresponding to the submissions were accurate, and all verifications were successful. This indicates that the structured security analysis conclusions output by this method are consistent with actual security semantics, possess interpretability and verifiability, and can be verified in a real-world operating environment.

[0164] Most importantly, in practical operation, this method can not only quickly identify publicly disclosed security patches through preliminary matching of submission hashes with vulnerability knowledge bases, but also perform deep semantic analysis on submissions that do not match known CVE mappings. This allows it to identify and verify silent security patches that have not yet been published in the official Android security bulletins—submissions that objectively fix security issues but are not disclosed in public security bulletins. For example, this method identified a submission with the hash 954631abb9004d1ddbb3ae2bfebe06154e118a79, which was manually verified as a security fix. This result demonstrates that the beneficial effects of this method are not limited to the rapid archiving of known vulnerabilities, but also lie in its proactive discovery capabilities for silent security patches. It expands the sources of security vulnerability intelligence and shortens the time lag between the emergence of upstream patches and the security response for downstream vendors. This is difficult to achieve with existing methods that rely solely on matching known vulnerability knowledge bases or manually reading submission messages and differentials.

[0165] Based on the above-mentioned results from actual operation, database archiving, manual review, and verification with real physical devices, this invention demonstrates feasibility, verifiability, and proactive discovery capabilities for the AOSP security patch intelligent analysis task. It verifies the advantages of this application's technical solution over existing methods in terms of analysis link efficiency, security semantic focus, and intelligence coverage. It should be noted that the above verification focuses on the actual verification of the correctness of the identification results and the ability to discover silent patches. Further quantitative comparative experiments with existing methods can be conducted on a unified benchmark dataset to more comprehensively characterize the performance of this method in terms of recall, precision, and other metrics.

[0166] Example 2

[0167] This embodiment provides an intelligent analysis system for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting.

[0168] like Figure 2 The system architecture of the present invention is shown, including an input layer, a data cleaning engine, a multi-level gating and semantic compression engine, and a structured analysis and result orchestration engine.

[0169] The input layer includes: AOSP code repository / commit information / diff code / CVE library.

[0170] The data cleaning engine includes: an incremental update module, a commit data extraction module, and a differential parsing module.

[0171] The multi-level gating and semantic compression engine includes: a CVE identification module, a context-accurate extraction module, a static filtering module, and a call graph construction module.

[0172] The structured analysis and results orchestration engine includes: a structured large model analysis module, a failure retry control module, a database persistence module, and a results verification module.

[0173] like Figure 3 As shown, the various modules of the system of the present invention are illustrated, including a data update module, a commit data extraction module, a differential parsing module, a CVE identification module, a reverse static filtering module, a function-level semantic compression module, a lightweight call graph construction module, a structured analysis module, a result verification and database storage module, and a failure control module. Among them, the modules work together to complete the incremental acquisition of AOSP submitted patches, differential parsing, known vulnerability identification, unknown submission filtering, semantic compression, structured security analysis, and result persistence.

[0174] Data update module: Used to perform incremental updates to the AOSP source code repository and identify Git sub-repositories within the scope of analysis.

[0175] The commit data extraction module is used to extract commit hashes, authors, dates, commit messages, and code difference bodies by time window.

[0176] Differential parsing module: used to parse change files, code block headers, added / deleted lines, and commit-level statistics in committed code.

[0177] CVE identification module: Used to quickly identify and directly archive known vulnerability submissions based on the mapping relationship between submission hash and vulnerability knowledge base.

[0178] Reverse static filtering module: It is used to perform pre-screening on submissions that do not hit the knowledge base by combining deduplication, empty submission removal, non-core file identification and security signal judgment.

[0179] Function-level semantic compression module: used to identify function context and extract added, deleted, and modified lines, and generate function-level differential context.

[0180] Lightweight graph construction module: used to extract call names from function-level difference context and construct a representation of local call relationships.

[0181] Structured Analysis Module: Used to take a compact semantic context as input to a large, constrained model and output structured security analysis results.

[0182] The result verification and database storage module is used to perform integrity verification on structured results and write them into the secure result database and the non-secure result database according to the model identifier.

[0183] Failure control module: Used to record the number of retries for failed analysis tasks and control whether to re-analyze or permanently mark a failed task based on a threshold.

[0184] The modules mentioned above work together to achieve an end-to-end processing flow from AOSP submission extraction, submission code structure parsing, rapid identification of known vulnerabilities, in-depth analysis of unknown submissions to the distribution of structured results into the database.

[0185] This invention employs a pre-matching mechanism based on the mapping relationship between submission hashes and vulnerability knowledge bases. Before entering deep semantic analysis, it quickly determines known security patches and directly includes matching submissions in the security result database, thus avoiding the repeated consumption of model analysis resources by known vulnerability submissions. Through a reverse static filtering mechanism, it no longer relies solely on security keyword matching to select analysis objects. Instead, it comprehensively considers deduplication of already analyzed data, removal of empty changes, identification of non-core files, and joint determination of security signals, sending only submissions with further security analysis value into the deep analysis chain. Furthermore, through a function-level differential semantic compression mechanism, it parses the diff structure, identifies function context from the code block header, and retains only newly added and deleted lines with security semantic value, removing ordinary contextual interference information. This compresses the original code into a compact semantic expression oriented towards function modifications.

[0186] This invention proposes a lightweight call relationship enhancement mechanism. It extracts call names from function-level differential contexts in a rule-based manner, constructing a local call relationship representation. This enables the model to analyze patches not only by focusing on isolated modification lines but also by combining related call relationships to identify security semantics such as permission checks, enhanced boundary verification, resource release repair, and security policy adjustments. Through a constrained large-model structured code analysis mechanism, using preset code analysis prompt templates for Android AOSP, Linux, and system security scenarios, the model is constrained to reason around vulnerability repair, permission boundaries, verification logic, memory safety, process boundaries, and security policy changes, and is forced to output structured results, improving the consistency, parsingability, and verifiability of the analysis results. Furthermore, through a model-isolated result storage and failure retry control mechanism, independent analysis states, retry counts, and result storage paths are established for different models. For failed calls, retry thresholds control whether to re-analyze or permanently mark them as failed, preventing the same failed task from continuously blocking the batch analysis process.

[0187] To address the technical challenges of existing technologies in real-world engineering environments, such as node explosion, context overflow, and noise interference, this application provides an intelligent analysis method and system for security patches in scenarios involving multiple repositories and high-frequency submissions, such as AOSP. This application aims to construct an intelligent analysis framework adapted to real-world engineering needs. By introducing precise extraction and noise reduction compression mechanisms based on patch semantics, it effectively filters irrelevant code and files, overcomes the limitations of large models in handling long texts, and avoids the analysis crash problems of traditional graph methods. This significantly reduces the cost of manual auditing while substantially improving the efficiency and accuracy of automated security patch identification in open-source systems. It provides downstream vendors and equipment manufacturers with security patch information for upstream patches, shortening the latency from patch appearance to downstream security response.

[0188] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An AOSP security patch intelligent analysis method based on function level difference semantic compression and multi-level shunting, characterized in that, Includes the following steps: S1. Obtain AOSP code commit data: Perform incremental updates on the AOSP source code repository and extract the committed code; S2. Perform differential structure parsing on the submitted code to obtain the set of changed files, the set of code blocks, and addition / deletion statistics; S3. Pre-processing of known vulnerability submissions: Based on the vulnerability knowledge base, perform submission hash matching and directly write submissions that match known CVE mapping relationships into the security result database. S4. Perform reverse static filtering on submissions that do not hit known CVEs, and only send submissions that meet the security analysis conditions into the deep analysis link. S5. Execution function level differential semantic compression: Accurately extracts and compresses the call relationship representation of the submitted execution function level differential context entering the deep analysis link to generate a compact semantic context; S6. Generate structured code input and perform large model analysis: Input the compact semantic context into the constrained large model structured analysis engine and output the security issue type, severity, issue description, cause, availability and test hints. S7. Execution result verification, distributed entry into database and failure retry control: Perform field integrity verification on the structured analysis results, and write submissions with security issues and those without security issues into mutually isolated result databases according to the model identifier.

2. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting according to claim 1, characterized in that, In S1, the specific implementation details are as follows: Perform repo-level incremental updates on the AOSP repository and identify multiple Git sub-repositories in the corresponding directory; perform git log retrieval for each sub-repository by time window to obtain the commit hash, author, commit date, and commit message; then perform git show code extraction for each commit, and only retain the code body starting with diff --git as input for subsequent analysis.

3. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting as described in claim 1, characterized in that, In S2, the specific implementation details are as follows: The system uses differential file matching rules to identify the original and new file paths of the commits. It uses code block header parsing rules to extract the original starting line number, new starting line number, modification range, and context header information of each code block. Based on the statistics of added and deleted lines within the code block, it generates the number of commit-level files, the number of code blocks, the number of added lines, and the number of deleted lines.

4. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting according to claim 1, characterized in that, In S3, the specific implementation details are as follows: The vulnerability knowledge base loads the announcement date range, CVE number, severity, announcement date, and commit hash mapping relationship; case-insensitive matching is performed on the commit hash of the submission to be analyzed; when one or more CVE numbers are matched, the severity levels are merged to generate a set of CVE numbers, severity levels, and announcement dates corresponding to the submission, and this is written directly into the security results database as a known secure submission, without entering the subsequent deep analysis chain.

5. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting according to claim 1, characterized in that, In S4, the specific implementation details are as follows: For submissions that do not match known vulnerability mappings, first check whether there are already analysis records in the security result library and non-security result library corresponding to the current model. If they already exist, skip them directly. If it does not exist, then check if the file to be changed is empty; if the file to be changed is not empty, then further check if all the files involved belong to the preset non-core file type. When all the changed files are non-core files, a joint judgment is made by combining the commit message and the security information in the code text. If the submission is determined to be unrelated to security, it does not need to enter the deep analysis process.

6. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting according to claim 1, characterized in that, In S5, the specific implementation details are as follows: The function name is identified from the header information of each code block; when the function name cannot be directly identified, the valid context identifier in the code block header is identified back; only the modified lines in the code block that start with an add or delete marker are retained to form a function-level differential context; at the same time, the file to which it belongs, the function name, the code block header and the set of modified lines are recorded, and a compact semantic carrier is constructed by combining the commit-level statistics.

7. The AOSP security patch intelligent analysis method based on function-level differential semantic compression and multi-level traffic splitting according to claim 1, characterized in that, In S6, the specific implementation details are as follows: The constrained large-model structured analysis engine includes: pre-built system prompts for Android AOSP, Linux, and system security analysis; requiring the model to reason about vulnerability remediation, permission boundaries, verification logic, memory safety issues, process boundaries, and security policy changes, and forcing the output of JSON structured results; inputting the large model with submission hashes, dates, and compact semantic context as user prompts; and marking the analysis as a failure when the model's returned content cannot be parsed into a JSON object.

8. An intelligent analysis system for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting, implementing the intelligent analysis method for AOSP security patches based on function-level differential semantic compression and multi-level traffic splitting as described in any one of claims 1 to 7, characterized in that, include: Data update module: Used to perform incremental updates to the AOSP source code repository and identify Git sub-repositories within the scope of analysis; The commit data extraction module is used to extract commit hash, author, date, commit message, and code difference body by time window. Differential parsing module: used to parse changed files, code block headers, added / deleted lines, and commit-level statistics in committed code; CVE identification module: used to quickly identify and directly archive known vulnerability submissions based on the mapping relationship between submission hash and vulnerability knowledge base; Reverse static filtering module: It combines deduplication, empty submission removal, non-core file identification and security signal judgment to perform pre-screening on submissions that do not hit the knowledge base; Function-level semantic compression module: used to identify function context and extract added, deleted, and modified lines, and generate function-level differential context; Lightweight graph construction module: used to extract call names from function-level difference context and construct a representation of local call relationships; The structured analysis module is used to take a compact semantic context as input to a large, constrained model and output structured security analysis results. The result verification and database storage module is used to perform integrity verification on structured results and write them into the secure result database and the non-secure result database according to the model identifier. Failure control module: Used to record the number of retries for failed analysis tasks and control whether to re-analyze or permanently mark a failed task based on a threshold.

Images