Harmony application static taint analysis method and system based on controlled large language model

Abstract

The application discloses a kind of based on controlled large language model's static taint analysis method and system of Hongmeng application, belong to software safety analysis technical field.The method is pre-analyzed to the Hongmeng application engineering to be analyzed, obtains program fact set and identifies the analysis gap that existing model cannot explain;Modeling candidate is filtered from the analysis gap and constructs context evidence package;Evidence package is input into large language model, and output is generated model, supplementary evidence or refuses generation by three-state decision framework limit;The model candidate of generation is executed check, and the model candidate that passes through check is issued as model package, and is loaded to static taint analysis engine and executes taint analysis and outputs taint analysis result and risk report.The application limits the ability of large language model in semantic completion link, avoids uncontrollable risk of directly judging vulnerability.

Description

Technical Field

[0001] This invention relates to the field of computer software security analysis technology, specifically to a method and system for static taint analysis of HarmonyOS applications based on a controlled large language model. Background Technology

[0002] Static taint analysis is one of the core technologies in application security detection. Its basic idea is to trace the propagation process of sensitive data in the program representation: first, identify the sensitive data source, then propagate along relationships such as assignment, parameter passing, return value passing, field reading and writing, function call returns, and framework scheduling, and finally report the risk when it propagates to a dangerous operation. This process depends not only on the propagation algorithm itself, but also on the direct constraints of the entry point identification capability and the semantic model coverage capability. The lack of an entry point will prevent the relevant code from entering the main analysis thread, and the lack of a semantic model will prevent the call point from being assigned the correct security meaning.

[0003] HarmonyOS applications rely on framework scheduling for execution, with actual entry points distributed across application capability lifecycles, scenario lifecycles, page lifecycles, declarative component events, callback functions, decorator bindings, and asynchronous tasks. Meanwhile, real-world projects typically include internal encapsulation, business middleware, and third-party software development kits. While these program relationships objectively exist, determining which relationships should be triggered at the entry point and which calls should generate source or sink points cannot be directly derived from the syntax. Existing solutions often employ a combination of a static taint analysis engine, a manual rule base, and a fixed entry point model. However, as project scale increases and third-party dependencies grow, the fixed entry point model has limited coverage of page declarations, component bindings, decorator associations, asynchronous tasks, and third-party framework registrations. Unfamiliar interfaces can only be processed after analysts discover gaps and supplement the rules.

[0004] The core technical problems of the above solutions are as follows: First, entry point identification relies on limited, manually pre-built models, making it impossible to proactively expose and handle unknown entry point gaps in a single analysis. Second, semantic judgment relies on manual review of individual call points, lacking a structured evidence organization mechanism oriented towards semantic modeling tasks, making it difficult to comprehensively analyze the receiver, parameters, return values, import sources, adjacent data flows, and framework meta-information. Third, even with the help of large language models, directly allowing them to judge vulnerabilities often results in uncontrollable natural language conclusions, which cannot replace a deterministic taint propagation engine. Furthermore, existing modeling results are difficult to retain and reuse without standardized model packages and loading mechanisms. Therefore, a method is needed that can continuously discover semantic gaps, organize program context evidence, generate verifiable structured semantic models, and import verified models into a deterministic taint analysis process. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a method and system for static taint analysis of HarmonyOS applications based on a controlled large language model. The method discovers semantic gaps through pre-analysis, organizes contextual evidence packages around the gaps, and constrains the large language model to output only verifiable structured semantic models. The verified models are then published as reusable model packages and loaded into the deterministic taint analysis process. This improves the coverage of real-world engineering applications by static taint analysis of HarmonyOS applications while avoiding the uncontrollable risks caused by the large language model directly judging vulnerabilities.

[0006] This invention is achieved through the following technical solution: A static taint analysis method for HarmonyOS applications based on a controlled large language model includes the following steps: Step 1: Perform a pre-analysis on the HarmonyOS application project to be analyzed to obtain a program fact set containing the facts of each call point and program context. Identify analysis gaps that cannot be explained by existing models from the program fact set. Step 2: Select modeling candidates from the analysis gaps and use them as modeling objects. Construct a contextual evidence package centered on the modeling objects and in combination with the corresponding program context facts. Step 3: Input the contextual evidence package into the large language model, and use the three-state decision framework to limit the output of the large language model to one of three results: generating the model, providing supplementary evidence, or refusing to generate the model. When the output is a generative model, the large language model outputs a rule model candidate, a module model candidate, or an entry recovery model candidate. The model candidate carries the applicable interface, parameter position, return position, triggering condition, evidence source, and confidence field. Step 4: Perform a pre-defined verification rule on the candidate models, publish the verified candidate models as a model package, load the model package into the static taint analysis engine for taint analysis, and obtain taint analysis results and risk reports.

[0007] Preferably, the pre-analysis in step 1 includes: parsing the source code, configuration files and module dependencies of the HarmonyOS application project to be analyzed, generating a basic program representation; loading an existing model on the basic program representation to perform pre-analysis, and obtaining the program fact set.

[0008] Preferably, the construction of the context evidence package in step 2 includes: deduplicating and unifying the selected modeling candidates to form the modeling object; and extracting program context facts from the program fact set using a template-based generation method with the modeling object as the center.

[0009] Preferably, in step 3, when the decision result of the three-state decision framework is supplementary evidence, the large language model outputs the supplementary focus, supplementary scope, and budget level; based on the supplementary focus, supplementary scope, and budget level, step 3 is re-executed after returning to the directional supplementary procedural context facts of step 2.

[0010] Preferably, in step 4, if the model candidate fails the verification, and the failure is due to a formatting error or a local structural defect, the model candidate is structurally corrected and resubmitted for verification within a limited number of rounds; if the failure is due to insufficient evidence, the process returns to step 2 to supplement the program context facts and then steps 3 and 4 are executed again.

[0011] Preferably, the verification of the model candidates in step 4 includes: Check whether the evidence references of the model candidates point back to the corresponding modeling objects, and check whether the model candidates can be directly parsed and loaded by the static taint analysis engine.

[0012] Preferably, the model package in step 4 is organized into three categories: rule model, module model, and entry recovery model, and supports independent activation by category.

[0013] Preferably, the static taint analysis engine outputting taint analysis results and risk reports in step 4 includes: The system outputs structured reports and auditable operational artifacts, which include process log files, model files, and operational lists, forming an audit chain that traces back from analysis results to modeling candidates, evidence packages, and model candidates.

[0014] A static taint analysis system for HarmonyOS applications based on a controlled large language model includes: The pre-analysis module is used to perform pre-analysis on the HarmonyOS application project to be analyzed, obtain a program fact set containing the facts of each call point and program context, and identify analysis gaps that cannot be explained by existing models from the program fact set. The evidence package construction module is used to screen modeling candidates from the analysis gaps and use them as modeling objects, and construct a contextual evidence package with the modeling objects as the center and in combination with the corresponding program context facts; The controlled modeling module is used to input the contextual evidence package into the large language model and limit the output of the large language model to one of three types of results: generating model, supplementing evidence, or refusing to generate, through a three-state decision framework. When the output is a generating model, the large language model outputs a rule model candidate, a module model candidate, or an entry recovery model candidate. The model candidate carries the applicable interface, parameter position, return position, triggering condition, evidence source, and confidence field. The verification and publishing module is used to perform verification on the model candidates according to preset verification rules, and publish the model candidates that pass the verification as a model package; The taint analysis module is used to load the model package into the static taint analysis engine to perform taint analysis and obtain taint analysis results and risk reports.

[0015] An electronic device is characterized by comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the HarmonyOS application static taint analysis method based on a controlled large language model as described above.

[0016] Compared with the prior art, the present invention has the following beneficial technical effects: This application proposes a static taint analysis method for HarmonyOS applications based on a controlled large language model. First, by parsing the HarmonyOS application project and performing a basic scan based on an existing model, a program fact set containing all call points and program context facts is generated, identifying analysis gaps that existing models cannot explain. Second, modeling candidates are selected from these gaps and unified as modeling objects. Corresponding program context facts are extracted from the program fact set around these modeling objects to construct a contextual evidence package, ensuring the large language model deals with structured semantic context rather than isolated code fragments. Then, a three-state decision framework limits the output of the large language model to three types of results: "generate model," "supplementary evidence," and "reject." When the output is a generated model, the model candidate must carry structured fields such as applicable interface, parameter location, return location, triggering condition, evidence source, and confidence level, thus preventing the large language model from directly outputting vulnerability conclusions. Finally, the model candidates are validated according to preset verification rules. Models that pass the validation are published as model packages, loaded into a deterministic static taint analysis engine to perform taint analysis, and output taint analysis results and a risk report. This method limits the semantic understanding capabilities of the large language model to the semantic completion stage, while the final taint propagation and risk reporting are still completed by the deterministic engine, thus balancing semantic coverage and security audit verifiability.

[0017] This application also proposes a HarmonyOS application static taint analysis system based on a controlled large language model, an electronic device, and a computer storage medium, which possess all the advantages of the aforementioned HarmonyOS application static taint analysis method based on a controlled large language model. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This is a flowchart of the static taint analysis method for HarmonyOS applications based on a controlled large language model, as described in this invention. Figure 2 This is a structural block diagram of the HarmonyOS application static taint analysis system based on a controlled large language model, as described in this invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] See Figure 1 A static taint analysis method for HarmonyOS applications based on a controlled large language model includes the following steps: Step 1: Parse the source code, configuration files, and module dependencies of the HarmonyOS application project to be analyzed to generate a basic program representation; on the basis of the basic program representation, perform pre-analysis based on the existing model to obtain a program fact set, which contains all call points and the program context facts corresponding to each call point.

[0023] The specific implementation method of step 1 will be described in detail below.

[0024] S11: Read the HarmonyOS application project to be analyzed, parse its source code, configuration files and module dependencies, and generate a basic program representation.

[0025] The basic program representation includes an abstract syntax tree, intermediate representation, call graph, and pointer assignment graph.

[0026] S12: On the basis of the basic program representation, load the existing rule model, module model and entry recovery model to perform pre-analysis.

[0027] During the pre-analysis process, the system performs taint propagation on the call graph, control flow graph, and pointer assignment graph based on the existing model. It tracks the process of sensitive data continuously propagating from the taint source through relationships such as assignment, parameter passing, return value passing, field reading and writing, and function call return, and obtains the program fact set.

[0028] The program fact set contains all call points and the program context facts corresponding to each call point. The program context facts include the parameters, return values, receivers, import sources, type signatures, field read / write relationships, string constants, key names, and similar interface usage samples corresponding to each call point.

[0029] In some embodiments, the basic program representation may further include a control flow graph and a function summary graph.

[0030] In some embodiments, the existing models can also be loaded separately from the model package by category.

[0031] A basic scan is performed on a real-world project through pre-analysis, generating a program fact set containing all call points and their corresponding program context facts. Existing models cover known interfaces, while call points that cannot be explained by existing models are also output as analysis gaps.

[0032] Step 2: Select the call points that need to be modeled from the program fact set as modeling candidates, and unify the modeling candidates into modeling objects; take the modeling object as the center, extract the program context facts corresponding to the modeling object from the program fact set, and construct a context evidence package.

[0033] The specific implementation method of step 2 will be described in detail below.

[0034] S21: Perform candidate filtering in the program fact set to identify call points that can be used as modeling candidates; The method for identifying the call point is as follows:

[0035] in, For candidate recognition functions, For the set of facts of the procedure, This is a candidate call point for modeling.

[0036] The candidate identification function is used to determine whether modeling is needed based on existing model coverage, call context, return value usage, callback or asynchronous features, shared state access, and entry recovery state; the program fact set is the set of call points and context facts obtained in the pre-analysis phase; the call points for modeling candidates are the call points that need to enter the semantic modeling process.

[0037] The call points include: third-party library calls that the existing model cannot interpret, calls with unknown return semantics but which are still used, calls with callback or asynchronous features, calls that access shared state objects, calls that carry page jump parameter passing, calls whose call methods and type signatures do not match, and structures that are suspected to be framework entry points but are not covered by the current entry point restoration model.

[0038] S22: The selected modeling candidates are deduplicated and standardized to form modeling objects.

[0039] For shallow forwarding encapsulation, it is folded down to the downstream real interface; For encapsulations that change parameter order, return value reception relationships, or callback relationships, these should be retained as separate modeling objects. This unified approach avoids the same interface being repeatedly modeled at multiple call points.

[0040] S23: Taking the modeling object as the center, extract the program context facts corresponding to the modeling object from the program fact set, and construct a context evidence package; Using abstract syntactic facts, variable propagation facts, and call relationship facts as input, construct a contextual evidence package within the context budget.

[0041]

[0042] Among them, abstract syntactic facts are used to describe syntactic structure and declaration relationships, variable propagation facts are used to describe definition, usage, assignment and field access relationships, invocation relationship facts are used to describe the relationship between invocation point, called interface, receiver, parameters and return value, and context budget is used to limit the slice range of the evidence package.

[0043] The program context facts include: call point, parameters, return value, receiver, import source, type signature, field read / write relationship, string constants, key name, and similar interface usage samples.

[0044] The construction of the context evidence package adopts a template-based generation method. The template covers five types of relationships: object ownership, call input and output, callback passing, cross-interface collaboration, and declarative association, forming minimal yet complete structured evidence.

[0045] In some embodiments, the modeling candidates may further include: calls that reach a dangerous usage location only after multiple layers of assignment following parameter reception, and calls that present different security semantics under different branches at the same call point.

[0046] In some embodiments, the context evidence package may also be stored in the form of a key-value record file, an objectified record file, a database record, or a memory object.

[0047] Candidate screening identifies the call points that truly need modeling from the analytical gaps, and standardization of modeling objects avoids redundant modeling. Contextual evidence packages extract corresponding program contextual facts from the program fact set for each modeling object, ensuring that the subsequent large language model deals with a structured semantic context rather than isolated code fragments. A templated context slicing mechanism ensures that different unfamiliar interfaces fall into a unified process, guaranteeing the consistency and integrity of the evidence package.

[0048] Step 3: Input the contextual evidence package into the large language model, and limit the output of the large language model to a three-state decision through preset prompt words, output mode and decision framework: generate model, supplement evidence or refuse to generate; When the decision is a generative model, the large language model must output a rule model, module model, or entry recovery model candidate that conforms to the preset field structure; When the decision is to supplement evidence, the large language model must provide the supplementary focus, scope, and budget level, and the system returns to step 2 to perform targeted supplementary context slicing.

[0049] When the decision is to refuse to generate, retain the reason for the rejection but do not generate a model.

[0050] The specific implementation method of step 3 will be described in detail below.

[0051] S31: For each modeling object, construct a modeling request based on the contextual evidence package.

[0052] The modeling request includes scenario type, evidence package reference, three-state decision space, set of required fields, and confidence lower bound.

[0053] The three-state decision space restricts the large language model to only be able to choose from three types of results: "generative model", "supplementary evidence", and "reject generation".

[0054]

[0055] Among them, the three-state decision function represents the output of the controlled modeler after semantic analysis of the contextual evidence package of the modeling object. Its value is limited to one of three results: "Generate" means outputting a rule model, module model or entry recovery model candidate; "Supplement" means outputting a supplementary evidence request, including supplementary focus, supplementary scope and budget level; "Reject" means retaining the rejection reason but not generating a loadable model.

[0056] S32: The modeling request is input into the large language model. The large language model performs semantic analysis based on the procedural facts in the contextual evidence package and outputs a three-state decision result. Specifically, after the controlled modeler analyzes the contextual evidence package of the modeling object, its decision result is limited to the following three types: When the decision result is "Generate", that is, when the contextual evidence is sufficient, the large language model outputs a model candidate. The model candidate is one of the rule model, module model or entry recovery model, and must include the applicable interface, parameter position, return position, receiver constraint, triggering condition, evidence source and confidence field. When the decision result is "supplementary", that is, when the contextual evidence is insufficient, the large language model outputs a supplementary evidence request. The supplementary evidence request must specify the focus, scope and budget level of the supplementation. When the decision result is "reject", the large language model outputs the rejection result, retains the reason for rejection, but does not generate a loadable model.

[0057] S33: When the decision result is "supplementary", based on the supplementary focus, scope, and budget level specified in the supplementary evidence request, return to step 2 to execute targeted supplementary context slicing, and resubmit the modeling request with the supplemented evidence package. The number of rounds of supplementary evidence and remodeling shall not exceed a preset limit.

[0058] Furthermore, the maximum number of rounds for supplementary evidence and remodeling can be configured based on project size, candidate type, and contextual budget.

[0059] In some embodiments, the large language model can be accessed through a cloud-compatible interface, a local private deployment interface, or a domain-specific model service interface.

[0060] By employing a three-state decision framework, the output of the large language model is limited to three controllable outcomes: "generate model, supplementary evidence, and rejection," thus fundamentally preventing the large language model from directly outputting vulnerability conclusions. When the output is a generated model, the model candidate must carry structured fields such as the applicable interface, parameter location, return location, triggering condition, evidence source, and confidence level, clearly defining the security semantics of the interface in taint propagation. When evidence is insufficient, the supplementary evidence mechanism guides the system to complete the context in a targeted manner, rather than directly guessing. This step restricts the semantic understanding capability of the large language model to the semantic completion stage, preventing uncontrollable natural language conclusions from entering the main analysis process.

[0061] Step 4: Perform multiple preset verification rules on the model candidate. The multiple preset verification rules include format verification, reference verification, type verification, classification consistency verification, conflict verification, loading verification, and confidence verification.

[0062] Model candidates that pass all validation items are determined to be publishable models and enter the model package release process. If a candidate model fails the validation, and the failure is due to a formatting error or a local structural defect, the structure should be corrected and the model re-validated within a limited number of rounds. If the failure is due to insufficient evidence, the model should be re-modeled after returning to step 2 to add contextual evidence. If the conflict cannot be resolved or the model fails the validation after multiple rounds of correction, the candidate model should be marked as rejected.

[0063] The specific implementation method of step 4 will be described in detail below.

[0064] S41: Perform the following seven checks on the model candidates generated in step 3 in sequence: Format check: Check whether the field structure of the model candidate conforms to the preset format of the rule model, module model, or entry recovery model; Reference check: Check whether the evidence references in the model candidate point back to the correct modeling object; Type check: Check whether the type of each field in the model candidate is consistent with the preset type; Classification consistency check: Check whether the scene type of the model candidate is compatible with the model category; Conflict check: Check whether there is a semantic conflict between the model candidate and the existing model; Loading check: Check whether the model candidate can be directly parsed and loaded by the static analysis engine; Confidence check: Check whether the confidence of the model candidate is not lower than the preset threshold.

[0065] S42: When a model candidate passes all seven checks, it is determined to be a publishable model. When a model candidate fails the checks, different actions are taken depending on the type of failure: If the failure is a formatting error or a local structural defect, the structure is corrected within a limited number of rounds and the model is resubmitted for verification; if the evidence for the failure is insufficient, return to step 2 to add contextual evidence, and re-execute step 3 (modeling) and step 4 (verification); if the conflict cannot be resolved or the model still fails to pass the checks after multiple rounds of correction, the model candidate is marked as rejected, the reason for rejection is retained, but no loadable model is generated.

[0066] In some embodiments, the seven checks can be performed serially or in groups.

[0067] Through an independent model validation process, seven structured checks are performed on the candidate models output by the large language model to ensure that all models entering the analysis process have a unified structure that is referential, loadable, and verifiable. Format and type validation ensure the standardization of the model's field structure; reference and conflict validation ensure the logical consistency between the model and existing knowledge; and confidence validation ensures that the model has sufficient evidence to support it. A limited-round correction and retry mechanism for validation failures allows correctable structural errors to be automatically repaired, while uncorrectable errors are excluded from the analysis process.

[0068] Step 5: Organize the verified published models into model packages according to preset categories. After the model packages are published, perform a full analysis, load the existing models and the models in the model packages, and perform a complete taint analysis on the basic program representation.

[0069] The specific implementation method of step 5 will be described in detail below.

[0070] S51: Organize the validated publishable models into three categories: rule models, module models, and entry recovery models. Register the package name, version, source project, generation time, evidence source, validation status, and activation scope for each model package. The model package can be activated as a whole, or separately as a rule model, module model, or entry recovery model.

[0071] S52: Perform a full analysis after the model package is released.

[0072] The static analysis engine loads existing models as well as models from the automatically generated model package.

[0073] Perform complete taint analysis on the basic program representation: the rule model supplements taint sources, hazard sinks, propagation rules, and cleanup rules; the module model supplements propagation summaries of complex interfaces; and the entry recovery model supplements framework-hosted entry points, lifecycle recovery relationships, and project-specific entry points.

[0074] The taint propagation and risk reporting are performed deterministically by the static analysis engine.

[0075] In some embodiments, the model package can be version-managed and reused across projects through a project-level model directory, a software development kit-level model directory, or a centralized model repository.

[0076] The model package mechanism consolidates the results of a single automated modeling session into reusable models. Model packages are organized into three categories: rule-based models, module models, and entry point recovery models. They support independent activation by category, allowing different models generated in the same round of automated modeling to be published uniformly and loaded on demand. The second phase, full analysis, loads the automatically generated models, enabling semantic supplementation results to directly participate in deterministic taint propagation. The final taint analysis results and risk reports are still provided by the static analysis engine, avoiding the limitation of model output remaining only at the natural language interpretation layer. Model packages support cross-project reuse; subsequent projects using the same interface can directly load the model package to complete the analysis without repeated modeling.

[0077] Step 6: Obtain a structured report and auditable operational deliverables based on the full analysis results; The structured report includes a risk summary, hit taint sources and hazard sinks, relevant call points, rules or models used, model package loading status, automatic modeling process log, generated model list, and unresolved candidate list; The operational outputs include process log files, rule model files, module model files, entry recovery model files, pre-analysis results, full analysis results, and operation lists.

[0078] The specific implementation method of step 6 will be described in detail below.

[0079] S61: Generate a structured report based on the full analysis results.

[0080] The structured report includes the following: a risk summary, listing the types and number of risks identified in this analysis; identified taint sources and hazard sinks, listing the taint sources and hazard sinks corresponding to each risk; relevant call points, listing the key call points involved in the propagation; rules or models used, listing the rule models, module models, and entry recovery models loaded and used in this analysis; model package loading status, listing the enabled model packages and their versions; automatic modeling process record, listing the model candidates, supplementary verification rounds, and verification results generated during this automatic modeling process; a list of generated models, listing the models that have passed verification and have been published; and a list of unresolved candidates, listing the candidates that failed verification or were rejected.

[0081] S62: Output the following runtime artifacts: process log file, recording gap discovery, evidence organization, supplementary evidence rounds and verification status; rule model file, module model file and entry recovery model file, respectively saving the three types of models generated this time; pre-analysis results, saving the pre-analysis output of step 1; full analysis results, saving the full taint analysis output of step 5; run list, recording the model package and analysis scope used this time.

[0082] In some embodiments, the structured report may also include clues for manual review and recommended directions for supplementary evidence.

[0083] By outputting structured reports and complete operational deliverables, a complete audit chain is maintained, tracing back from the final risk outcome to modeling candidates, evidence packages, and model generation rounds. Security analysts can track the generation process of each model through process log files, reuse published models through model files, and locate gaps requiring manual intervention through the unresolved candidate list. This audit mechanism makes the automated modeling process traceable and verifiable, meeting the compliance requirements of security audits.

[0084] Compared with the prior art, the present invention has the following advantages: First, it transforms unknown interfaces from uncontrollable black boxes into processable objects. Existing technologies mainly rely on manual investigation when discovering semantic gaps. This invention automatically generates a program fact set containing all call points and program context facts through pre-analysis. After candidate screening and modeling object standardization, unknown interfaces enter a standardized modeling process, eliminating the need for manual discovery and judgment.

[0085] Secondly, it reduces the modeling costs for HarmonyOS applications and third-party software development kits. Existing technologies require analysts to repeatedly read source code and manually write rules. This invention automatically generates contextual evidence packages and calls a controlled large language model to generate a structured semantic model, constraining the model output with a three-state decision framework, thus reducing the workload of manually adding rules one by one.

[0086] Third, it avoids direct interference from large language models in vulnerability conclusions. Existing technologies, when directly querying large language models, often produce natural language answers that are difficult to integrate into engineering processes, resulting in unstable fields, unclear evidence boundaries, and difficulty in auditing. This invention limits the output of the large language model to a verifiable structured model, while the final taint propagation and risk reporting are still completed by a deterministic static analysis engine, thus resulting in more stable and auditable results.

[0087] Fourth, it enhances the coverage of HarmonyOS application entry points. Existing technologies typically only cover a few fixed lifecycle entry points. This invention, through entry point candidate identification and entry point recovery modeling mechanisms, can include framework-hosted entry points, component event entry points, lifecycle recovery relationships, and project-specific entry points in the analysis scope, reducing false negatives caused by missing entry points.

[0088] Fifth, a model reuse mechanism has been established. In existing technologies, manual rule completion is often a one-time process, making it difficult to reliably reuse in subsequent projects. This invention publishes validated models as model packages, organized into three categories: rule models, module models, and entry point recovery models. This supports independent activation by category and cross-project reuse, avoiding redundant modeling and making it suitable for long-term maintenance of the HarmonyOS application security knowledge base.

[0089] Sixth, it improves the balance between coverage and false positives. Existing technologies, in pursuit of coverage, often crudely connect to unknown interfaces, easily introducing a large number of unfounded propagations and increasing false positives. This invention, through contextual evidence packet slicing, structured semantic modeling, and seven model verifications, only injects the semantics of interfaces with sufficient evidence support into the analysis thread, thereby improving coverage while controlling the false positive rate.

[0090] Example 1 This embodiment is deployed on a Node.js 18 or later environment. The static analysis foundation is responsible for generating the abstract syntax tree, intermediate representation, call graph, and pointer assignment graph. The controlled modeler calls the large language model through a cloud-compatible interface. During operation, the system writes process log files, module model files, analysis result files, and run lists in stages. The automatic modeling results and the full analysis results are both kept traceable in the above file system.

[0091] This embodiment selects the cross-page parameter propagation gap as the implementation scenario. When a page jumps, the parameter object carries the target key K into the routing process; after the page switch is completed, the target page reads the same key at the lifecycle entry point, and the reading result continues to flow to the dangerous usage location. The target page lifecycle entry point has been recovered by the existing entry point model identification, the upper limit of the supplementary evidence round is set to 2, the model deployment confidence threshold is set to 0.70, and the upper limit of automatic format correction is set to 1.

[0092] Step 1: Perform pre-analysis and generate a program fact set.

[0093] The system performs abstract syntax tree extraction, intermediate representation construction, call relationship resolution, and pointer assignment relationship construction on the project to be analyzed, generating a basic program representation. Based on the existing rule model, module model, and entry point recovery model, pre-analysis is performed to obtain the program fact set. Pre-analysis results show that sensitive data has propagated from existing sensitive source points to the target key K in the page jump parameter object, and the dangerous usage location has been identified by existing dangerous sink point rules.

[0094] Once the taint propagation reaches the route writing location, the existing analysis thread can only confirm that the parameter object was written into the page navigation process. It cannot directly determine the reading location and reception method of the parameter in the target page based solely on the current program facts. Therefore, the system registers a cross-page parameter propagation gap in the process log file. This gap serves as an analysis gap in the program fact set and is sent to subsequent candidate identification and automatic modeling processes.

[0095] Step 2: Filter modeling candidates and construct a contextual evidence package.

[0096] After identifying the aforementioned semantic gap, the system creates a single modeling object for the gap, using route.transfer.candidate.001 as the overall association number. This modeling object is simultaneously bound to the scene type, target page identifier, write interface role, read interface role, parameter key, and dangerous usage location, ensuring that the breakpoints identified in the pre-analysis phase always point to the same propagation scene in subsequent slicing, supplementary evidence, and modeling.

[0097] The system matches routing parameter slice templates around the modeling object, extracting the routing target, parameter carrying object, contaminated field path, and write call location from the write side; and extracting the parameter read interface, the role of the read location, the access method of the return value field, and the subsequent use location of the read result from the read side. It then adds two types of constraints: target page consistency and parameter key consistency, merging the above information into a structured evidence package. The above slice results converge into a single structured evidence record in the process log file, where the candidate number, write context, read context, dangerous use context, and constraints are uniformly organized in the same object.

[0098] Step 3: Controlled modeling generates a structured semantic model.

[0099] The system assembles the first round of modeling requests, which always include the scenario type, evidence package reference, three-state decision space, set of required fields, and confidence lower limit. The output can only be selected from three types of results: "Generate Model", "Supplement Evidence", and "Reject Generation".

[0100] In this embodiment, the first round of modeling did not directly generate a publishable model. Instead, it returned a supplementary verification request, with the verification objective limited to the local reception relationship of "how the parameter read return value continues to flow to the dangerous use location." The system expanded the local propagation facts between the read return fields and the dangerous use parameters according to the request, while maintaining the original candidate number and original evidence citations. After the supplementary verification was completed, a modeling request was submitted again. The second round of results was converted into a module model, converging the cross-page parameter propagation scenario into a structured propagation summary. Its core fields include propagation rules, triggering conditions, and confidence levels. At this point, the candidate has progressed from "under supplementary verification" to "model awaiting verification."

[0101] Step 4: Verify the model and execute supplementary procedures.

[0102] After the module model returned from the second round of modeling entered the verification phase, the system sequentially performed format verification, reference verification, type verification, classification consistency verification, conflict verification, loading verification, and confidence verification. Reference verification checked whether the candidate number and the evidence reference referred back to the same candidate; classification consistency verification checked whether the scene type and model category were compatible; and loading verification verified whether the propagation field could be directly parsed by the static analysis engine. Since this embodiment had already supplemented the partial reception facts before the second round, the model entering the verification phase had complete evidence references and explicit propagation fields, and all seven verifications passed without triggering any new supplementary evidence loops.

[0103] After successful verification, the system writes the model into the module model file and synchronously registers the model number, scene type, verification status, release status, and confidence level in the process log file, thus transforming the model from a modeling candidate into a formal model entry that can be released, loaded, and audited.

[0104] Step 5: Publish the model package and load it into the full analysis.

[0105] After the model validation is successful, the system will include route.transfer.module.001 in the module model package generated during this run, and register the package name, version, source project, and scope of use for this model package. The automatic modeling results will then be transferred to a model package system that can be directly loaded for full analysis.

[0106] After entering full analysis, the static analysis engine first reads the model package registration information, then loads route.transfer.module.001 into the module model set, and adds a cross-page propagation connection to the existing propagation framework according to the propagation rules therein. A deterministic connection is thus established between the target key K in the page jump parameter object and the corresponding key in the target page parameter reading result. The formal taint propagation continues along this connection, eventually reaching the dangerous usage location. The restored main propagation sequence is: sensitive source point, key K in the page jump parameter object, corresponding key in the target page parameter reading result, dangerous usage location.

[0107] Step 6: Output a structured report and auditable runtime artifacts.

[0108] Upon completion of the full analysis, the system simultaneously archives the analysis results file, process log file, module model file, and run list. The analysis results file provides the risk type, candidate number, associated model, and critical propagation path identified in this analysis; the process log file retains the gap discovery, evidence organization, supplementary evidence rounds, and verification status; the module model file retains reusable formal models; and the run list records the model packages used and the scope of the analysis. These deliverables form a complete audit chain from top to bottom, tracing back from risk findings to candidates, evidence packages, and published models.

[0109] This invention proposes a controlled large language model method and system for static taint analysis of HarmonyOS applications. Addressing the semantic gaps in traditional static analysis caused by unfamiliar interfaces, framework entry points, and third-party encapsulations in HarmonyOS applications, and the uncontrollable nature of directly using large language models to identify vulnerabilities, this invention establishes an automatic modeling control framework. This framework organizes gap discovery, evidence organization, controlled modeling, model validation, model package release, and full analysis into a closed-loop process. Using this technical solution, the capabilities of the large language model are limited to the semantic completion stage. Its output is transformed into three types of loadable models: rule models, module models, and entry point recovery models. Finally, a deterministic static analysis engine completes taint propagation and generates a risk report. This approach improves the coverage of static taint analysis for HarmonyOS applications to real-world engineering scenarios, reduces the cost of manual rule maintenance, and avoids the uncontrollable risks associated with directly identifying vulnerabilities using large language models.

[0110] Example 2 A static taint analysis system for HarmonyOS applications based on a controlled large language model includes: The pre-analysis module is used to perform pre-analysis on the HarmonyOS application project to be analyzed, obtain a program fact set containing the facts of each call point and program context, and identify analysis gaps that cannot be explained by existing models from the program fact set. The evidence package construction module is used to screen modeling candidates from the analysis gaps and use them as modeling objects, and construct a contextual evidence package with the modeling objects as the center and in combination with the corresponding program context facts; The controlled modeling module is used to input the contextual evidence package into the large language model and limit the output of the large language model to one of three types of results: generating model, supplementing evidence, or refusing to generate, through a three-state decision framework. When the output is a generating model, the large language model outputs a rule model candidate, a module model candidate, or an entry recovery model candidate. The model candidate carries the applicable interface, parameter position, return position, triggering condition, evidence source, and confidence field. The verification and publishing module is used to perform verification on the model candidates according to preset verification rules, and publish the model candidates that pass the verification as a model package; The taint analysis module is used to load the model package into the static taint analysis engine to perform taint analysis and obtain taint analysis results and risk reports.

[0111] See Figure 2 The specific functions of each of the above modules will be further explained below.

[0112] The pre-analysis module includes an engineering parsing unit, used to read the HarmonyOS application source code, project configuration files, page configuration files, module dependencies, and third-party library references to generate the basic program representation required for static analysis. Based on the existing rule model and module model, the pre-analysis module performs an initial scan to identify covered interfaces, uncovered interfaces, initial taint sources, initial dangerous sinks, and candidate vulnerabilities.

[0113] The evidence package construction module includes a candidate discovery unit and a context slicing unit. The candidate discovery unit identifies modeling candidates from unknown calls, callback parameters, asynchronous returns, shared state access, page jump parameter passing, suspicious entry points, and abnormal call methods, and unifies them into stable modeling objects. The context slicing unit extracts call points, defines usage relationships, import sources, type signatures, string constants, framework metadata, and adjacent usage samples around the modeling object to form an evidence package.

[0114] The controlled modeling module is used to call a large language model with a compatible interface according to preset prompts, output structure and round strategy, so as to generate structured semantic modeling results.

[0115] The verification and publishing module includes a model verification unit and a model package management unit. The model verification unit checks whether the output of the large language model conforms to the field structure of the rule model, module model, or entry recovery model, whether it meets classification consistency constraints, whether it can be loaded by the static analysis engine, and whether it conflicts with existing models. The model package management unit is used to save, publish, load, enable, disable, and reuse models. Model packages can be enabled separately according to three categories: rule models, module models, and entry recovery models.

[0116] The taint analysis module is used to load the model package and perform static taint propagation, output risk results from taint sources to hazard sinks, and generate structured reports, automatic modeling process records, candidate lists, model files, run lists, and manual review clues.

[0117] It should be noted that, in the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another device, or some features may be ignored or not executed. The modules described as separate components may or may not be physically separated. The components shown as modules may be one or more physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs.

[0118] Furthermore, in the various embodiments of the present invention, the modules can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The integrated unit described above can be implemented in hardware or as a software functional unit.

[0119] An electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the HarmonyOS application static taint analysis method based on a controlled large language model as described in any of the above embodiments.

[0120] Another electronic device provided in this application embodiment may further include: an input port connected to a processor for transmitting multimodal data collected by an external acquisition device to the processor; a display unit connected to the processor for displaying the processor's processing results to the outside world; and a communication module connected to the processor for enabling communication between the electronic device and the outside world. The display unit may be a display panel, a laser scanning display, etc.; the communication method adopted by the communication module includes, but is not limited to, Mobile High Definition Link (HML), Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), and wireless connection (including Wi-Fi, Bluetooth, Bluetooth Low Energy, and IEEE 802.11s-based communication technology).

[0121] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the HarmonyOS application static taint analysis method based on a controlled large language model as described in any of the above embodiments.

[0122] For descriptions of relevant parts of the HarmonyOS application static taint analysis system, electronic device, and computer-readable storage medium based on a controlled large language model provided in this application, please refer to the detailed description of the corresponding parts in the HarmonyOS application static taint analysis method based on a controlled large language model provided in this application, which will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0123] The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solution based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A static taint analysis method for HarmonyOS applications based on a controlled large language model, characterized in that, Includes the following steps: Step 1: Perform a pre-analysis on the HarmonyOS application project to be analyzed to obtain a program fact set containing the facts of each call point and program context. Identify analysis gaps that cannot be explained by existing models from the program fact set. Step 2: Select modeling candidates from the analysis gaps and use them as modeling objects. Construct a contextual evidence package centered on the modeling objects and in combination with the corresponding program context facts. Step 3: Input the contextual evidence package into the large language model, and use the three-state decision framework to limit the output of the large language model to one of three types of results: generating model, supplementing evidence, or refusing to generate. When the output is a generative model, the large language model outputs a rule model candidate, a module model candidate, or an entry recovery model candidate. The model candidate carries the applicable interface, parameter position, return position, triggering condition, evidence source, and confidence field. Step 4: Perform a pre-defined verification rule on the candidate models, publish the verified candidate models as a model package, load the model package into the static taint analysis engine for taint analysis, and obtain taint analysis results and risk reports.

2. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, The pre-analysis in step 1 includes: parsing the source code, configuration files, and module dependencies of the HarmonyOS application project to be analyzed, generating a basic program representation; loading an existing model onto the basic program representation to perform pre-analysis, and obtaining the program fact set.

3. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, The construction of the context evidence package in step 2 includes: deduplicating and unifying the selected modeling candidates to form the modeling object; and extracting program context facts from the program fact set using a template-based generation method with the modeling object as the center.

4. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, In step 3, when the decision result of the three-state decision framework is supplementary evidence, the large language model outputs the supplementary focus, supplementary scope, and budget level; based on the supplementary focus, supplementary scope, and budget level, it returns to the context facts of the targeted supplementation procedure in step 2 and then re-executes step 3.

5. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, In step 4, if the model candidate fails the verification, if the failure is due to a formatting error or a local structural defect, the model candidate is structurally corrected and resubmitted for verification within a limited number of rounds; if the failure is due to insufficient evidence, the process returns to step 2 to supplement the program context facts and then steps 3 and 4 are executed again.

6. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, The verification of model candidates in step 4 includes: Check whether the evidence references of the model candidates point back to the corresponding modeling objects, and check whether the model candidates can be directly parsed and loaded by the static taint analysis engine.

7. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, The model package mentioned in step 4 is organized into three categories: rule model, module model, and entry recovery model, and supports independent activation by category.

8. The method for static taint analysis of HarmonyOS applications based on a controlled large language model according to claim 1, characterized in that, The static taint analysis engine outputs taint analysis results and risk reports in step 4, including: The system outputs structured reports and auditable operational artifacts, which include process log files, model files, and operational lists, forming an audit chain that traces back from analysis results to modeling candidates, evidence packages, and model candidates.

9. A static taint analysis system for HarmonyOS applications based on a controlled large language model, characterized in that, include: The pre-analysis module is used to perform pre-analysis on the HarmonyOS application project to be analyzed, obtain a program fact set containing the facts of each call point and program context, and identify analysis gaps that cannot be explained by existing models from the program fact set. The evidence package construction module is used to screen modeling candidates from the analysis gaps and use them as modeling objects, and construct a contextual evidence package with the modeling objects as the center and in combination with the corresponding program context facts; The controlled modeling module is used to input the contextual evidence package into the large language model and limit the output of the large language model to one of three types of results: generating model, supplementing evidence, or refusing to generate, through a three-state decision framework. When the output is a generating model, the large language model outputs a rule model candidate, a module model candidate, or an entry recovery model candidate. The model candidate carries the applicable interface, parameter position, return position, triggering condition, evidence source, and confidence field. The verification and publishing module is used to perform verification on the model candidates according to preset verification rules, and publish the model candidates that pass the verification as a model package; The taint analysis module is used to load the model package into the static taint analysis engine to perform taint analysis and obtain taint analysis results and risk reports.

10. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the HarmonyOS application static taint analysis method based on a controlled large language model as described in any one of claims 1 to 8.

Images