Privacy risk discovery and compliance auditing method and system for platform-oriented applicationlet ecology

Abstract

The application discloses a privacy risk discovery and compliance audit method for a platform type application program ecological system, which organizes cross-platform source code processing, risk path discovery and path level compliance audit into a continuous pipeline, realizes automatic discovery and verifiable disposal of the privacy risk of the application program, can be compatible with various platform type application program ecological systems under a unified link, and reduces the adaptation and fragmentation problems between different platforms. In addition, the limited code repair mechanism driven by the joint driving of syntax checking and graph parsing checking can improve the analyzability of real engineering dirty code and reduce the missed detection caused by compressed, obfuscated and incomplete code.

Description

Technical Field

[0001] This invention belongs to the field of mobile application privacy governance technology, and involves program analysis, privacy risk detection and intelligent security auditing technology, particularly a method and system for privacy risk discovery and compliance auditing for platform-based application mini-program ecosystem. Background Technology

[0002] Platform-based applications extend their service capabilities by introducing third-party mini-programs, enabling the host application to support multiple business services under a unified entry point. While this operating model can improve service aggregation capabilities, it also increases the difficulty of privacy governance by having the collection, processing, storage, and transmission of sensitive user data span across the boundaries of the host application, the mini-program's operating framework, and the third-party services.

[0003] Compared to traditional standalone mobile applications, the mini-program ecosystem has at least the following characteristics: First, there are significant differences between different platforms in terms of code package format, unpacking method, runtime interface, permission constraints, and platform documentation. Second, in real-world engineering projects, mini-program code often suffers from inconsistent quality issues such as compression, obfuscation, incomplete fragments, and non-standard syntax, which can easily lead to parsing failures, broken dependencies, and lost line number mappings. Third, the propagation of privacy data in mini-programs typically traverses page logic, utility functions, asynchronous callbacks, and object wrapper interfaces, making the data propagation path complex. It is difficult to determine whether a cross-boundary propagation link has truly been formed based solely on the hit result of a single sensitive interface.

[0004] To address the aforementioned issues, one type of solution in existing technologies primarily employs rule-based source-sink detection. This type of solution typically relies on static rules, platform-specific adaptation logic, and limited propagation heuristics. While it can provide some candidate clues, its ability to recover data streams across functions, callbacks, and object wrappers is limited. When dealing with heterogeneous code across multiple platforms, it requires repeated customization and adaptation, and it is prone to missed detections in scenarios with dirty code and incomplete graph structures.

[0005] Another approach in existing technologies attempts to directly submit candidate code snippets to a large language model to generate compliance judgments. While this approach can provide natural language explanations, it often fails to effectively separate code facts from value judgments. It is easily affected by the order of prompts, keyword anchoring, differences in surface interface names, and contextual noise, leading to unstable audit conclusions and making it difficult to form a replayable, verifiable, and rectifiable chain of evidence.

[0006] Furthermore, platform governance processes go beyond simply identifying a suspicious path. Governing bodies typically need to determine: whether sensitive fields have indeed been transmitted across boundaries, whether there is user-triggered or authorized evidence, whether it falls within the scope of business necessity, whether fields have been transmitted beyond their permitted scope, and whether anonymization, encryption, or minimization measures have been implemented. Existing solutions often separate risk discovery from compliance classification, making it difficult to directly translate preliminary detection outputs into subsequent remediation decisions.

[0007] Therefore, there is an urgent need to establish a complete technical solution that can link cross-platform code preprocessing, candidate privacy path discovery, structured fact generation, dual-perspective auditing, arbitration rating, and rectification generation to solve the aforementioned technical problems of privacy risk discovery and compliance auditing in the mini-program ecosystem. Summary of the Invention

[0008] Purpose of the invention: In view of the problems and shortcomings of the existing technology, the present invention provides a privacy risk discovery and compliance audit method for the platform application mini-program ecosystem, so as to realize cross-platform code processing, candidate path discovery, path-level structured fact generation, risk rating and rectification generation in a unified technical link.

[0009] Technical Solution: This invention discloses a method for privacy risk discovery and compliance auditing in the platform-based application mini-program ecosystem. By organizing cross-platform source code processing, risk path discovery, and path-level compliance auditing into a continuous pipeline, it achieves automated discovery and verifiable handling of mini-program privacy risks. The method specifically includes the following steps: Step 101: Obtain the mini-program code package for the target platform, and identify the package format, platform type, and interface naming rules corresponding to the target platform; Step 102: Perform platform adaptation unpacking, syntax standardization, and code repair on the mini-program code package to obtain a set of parseable source code; Step 103: Construct a system dependency graph based on the parsable source code set, determine sensitive source interfaces and sensitive sink interfaces, generate candidate propagation path evidence, and extract candidate privacy path slices around the sensitive source interfaces and sensitive sink interfaces in combination with the system dependency graph and the candidate propagation path evidence. Step 104: Perform node symbolization, local topological encoding, global semantic encoding and fusion discrimination on the candidate privacy path slices, output risk probability or risk label, and obtain risk candidate path set accordingly; Step 105: Perform interface normalization and evidence processing on each risk candidate path in the risk candidate path set to generate a structured fact report; Step 106: Generate business rationality assessment results and risk exposure assessment results based on the structured fact report; Step 107: Combining the rule-based rating signal and the domain knowledge obtained by platform-based filtering retrieval, arbitrate the business rationality assessment result and the risk exposure assessment result to obtain the target risk level and corresponding reasons; Step 108: Generate and output rectification suggestions based on the target risk level and corresponding reasons.

[0010] The technical solution further defined in this invention is as follows: Preferably, in step 101, the package format includes at least one of the WeChat Mini Program code package, the Baidu Mini Program code package, and the Douyin Mini Program code package; the interface naming rules include at least one of the host object naming rules, platform-specific naming rules, object method wrapper naming rules, and cross-mini program jump parameter naming rules; the platform type identification criteria include at least one of the following: code package suffix, directory structure characteristics, configuration file identifier, host object prefix, and platform-specific component syntax.

[0011] Preferably, step 102 specifically includes: Step 1021: Perform syntax verification and graph parsing verification on the standardized source code in sequence, identify the files that fail verification and need to be repaired, and extract the error line number, error type, error message, local context or parsing failure information; Step 1022: Input the error information and code to be repaired of the file to be repaired into the code repair module, and output the repaired code while maintaining the original business logic; Step 1023: Perform syntax verification and graph parsing verification on the repaired code again; Step 1024: If the repaired code still does not meet the preset parsing conditions and the current repair round has not reached the preset maximum number of times, continue to execute the next round of repair; when the current repair round reaches the preset maximum number of times, mark the corresponding file as a parsing failure file and exit the repair process.

[0012] As a further preferred embodiment, the syntax verification is preferably performed by ESLint or other JavaScript syntax verifiers, and the graph parsing verification is preferably performed by Joern or other code property graph parsers; the code repair module is preferably implemented using qwen3-coder or other large language models oriented towards source code generation and repair optimization.

[0013] As a further preferred embodiment, steps 102 and 103 collaboratively invoke Joern and CodeQL; Joern is used to generate a code attribute graph and extract control flow, data flow, and call relationships to construct a system dependency graph, while CodeQL is used to perform taint propagation style queries around cross-platform sensitive source interfaces and sensitive sink interfaces to generate candidate propagation path evidence; after the candidate propagation path evidence is aligned with the system dependency graph through anchor points, it serves as the input for candidate path discovery in step 103, and as the initial path labeling basis in the training sample construction or result verification process.

[0014] In a preferred embodiment, the evidence for the candidate propagation path can be formalized as follows:

[0015] in, Represents the source node. Represents the sink node. Indicates the sequence of intermediate propagation anchor points. This represents the set of corresponding code locations; the alignment relationship between the candidate propagation path evidence and the system dependency graph nodes is preferably represented as follows:

[0016] in, This represents the set of nodes in the system dependency graph.

[0017] Preferably, step 103 specifically includes: Step 1031: Construct a system dependency graph based on the resolvable source code set, including data dependency edges, control dependency edges, and call dependency edges; Step 1032: Establish one or more of the following interfaces as a sensitive source interface registry: location interface, device information interface, identity identifier interface, user content interface, and contact information interface; Step 1033: Establish one or more of the following as sensitive endpoint interface registry points: network request interface, log reporting interface, data persistence interface, file operation interface, and cross-application or cross-mini-program jump interface. Step 1034: Generate candidate propagation path evidence based on the sensitive source interface registry and the sensitive sink interface registry. The candidate propagation path evidence includes at least one of the following: source node, sink node, intermediate propagation anchor point, and corresponding code location. Step 1035: Combining the system dependency graph and the candidate propagation path evidence, with sensitive interface nodes as anchor points, trace the data source nodes and control predecessor nodes in reverse along the system dependency graph, and trace the data destination nodes and call successor nodes in forward along the system dependency graph to generate candidate privacy path slices. As a further optimization, when the number of nodes in a candidate privacy path slice exceeds a preset threshold... At that time, for the anchor point Surrounding nodes Calculate the retention score: ;in, To traverse the set of candidate nodes The nodes in the list are selected, and the set of nodes with the highest scores is retained: ;in, The shortest graph distance to the anchor point. Indicates the node connectivity. This indicates whether a node directly contains platform-sensitive interface semantic anchors. The aforementioned weights are example weights in the preferred implementation and can be adjusted according to the scenario. The above-mentioned reserved scoring formula is used to uniformly encode the three priority conditions—closer to the anchor, in a key propagation position, and directly containing sensitive interface semantics—into sortable scores; the weight coefficients can be adjusted according to implementation requirements, but the multi-factor joint pruning logic expressed remains unchanged.

[0018] Preferably, step 104 specifically includes: Step 1041: Perform symbolization processing on the nodes in the candidate privacy path slice, in which developer-defined variable names are mapped to ordered variable tags, developer-defined function names are mapped to ordered function tags, string literals and numeric literals are replaced with uniform constant tags, and platform sensitive interface names and host object prefixes are preserved. Step 1042: Encode the local topology in the candidate privacy path slice using a graph neural network encoder to extract dependency propagation features; Step 1043: Encode the node sequence arranged in code order using a self-attention sequence encoder to extract cross-distance contextual features; Step 1044: By integrating gating comprehensive local topological coding and global semantic coding, the risk probability or risk label is output.

[0019] As a further preferred embodiment, in step 104, the local topological coding result and the global semantic coding result are jointly discriminated through fusion gating to adaptively balance the graph structure features and cross-distance semantic features, and output the risk probability or risk label corresponding to the slice accordingly.

[0020] Preferably, step 105 specifically includes: Step 1051: Map semantically equivalent location interfaces, authorization interfaces, network request interfaces, log reporting interfaces, file system interfaces, and cross-mini-program jump interfaces across different platforms to a unified event type; Step 1052: Identify the request interface, reporting interface, upload interface, and cross-mini-program jump interface carrying additional data payload in the form of object packaging. Step 1053: Generate field-level data flow mapping relationships according to the field source node, intermediate propagation nodes, and target sink node; Step 1054: Generate a structured fact report. The structured fact report includes at least one of the following: privacy-related interfaces and their corresponding line numbers, sensitive data types, field sources, field destinations, cross-boundary sink types, slice start and end positions, number of nodes, number of edges, anchor positions, platform type, and candidate construction methods.

[0021] As a further optimization, the field-level propagation mapping relationship can be represented as:

[0022] The structured fact report is formalized as follows: .

[0023] Preferably, step 106 specifically includes: Step 1061: Receive the structured fact report, and have the business defender audit submodule generate a business rationality assessment result based on clues such as user triggering, authorization notification, business necessity, field minimization, and mitigation measures; Step 1062: The risk attacker audit submodule generates risk exposure assessment results around cross-boundary transmission, telemetry reporting, cross-mini-program collaboration, field expansion, and pseudo-mitigation risks. Step 1063: Both the Business Defender Audit Submodule and the Risk Attacker Audit Submodule output one or more of the following: line number references, key fact references, recommendation levels, and missing context lists; Step 1064: Link the business rationality assessment results and the risk exposure assessment results with the structured fact report for use in subsequent arbitration.

[0024] Preferably, step 107 specifically includes: Step 1071: Generate a rule-based rating signal based on the structured fact report. The rule-based rating signal is generated by at least one of the following: boundary evidence identification, data sensitivity mapping, necessity and consent detection, and mitigation and controllability detection. Step 1072: Construct a knowledge query corresponding to the platform to which the current candidate path belongs, and retrieve domain knowledge matching the current candidate path from platform rule documents, privacy compliance rules, historical audit cases and few-sample audit examples; Step 1073: Input the structured fact report, business rationality assessment results, risk exposure assessment results, rule-based rating signals, and domain knowledge filtered by the platform into the arbitration rating module to obtain the target risk level and corresponding reasons; Step 1074: Output the target risk level, reasons for acceptance, and anchor points of evidence.

[0025] As a further preferred embodiment, the regularized rating signal is obtained by constructing a gating vector and a proposal signal:

[0026] ;in, This indicates the results of boundary evidence identification. This indicates the result of the data sensitivity mapping. Expressing necessity and consent to the test results, This indicates the results of the mitigation and controllability tests. Indicates the recommended level. Indicates heuristic confidence level. This represents a collection of explanatory comments.

[0027] The preferred representation of the platform's filtered search results is as follows: ;in, Indicates based on candidate paths Constructed knowledge query, The vector representation of the knowledge query. Representing knowledge fragments The vector representation of , This represents the set of knowledge fragments filtered by the platform to which the candidate path belongs. This indicates the selection of the first [knowledge fragment] from the set of knowledge fragments. The most relevant knowledge fragments. The platform filtering retrieval formula is used to emphasize that the retrieval stage should first limit the platform scope and then perform similarity ranking.

[0028] Preferably, step 108 specifically includes: Step 1081: Generate rectification suggestions based on the target risk level and corresponding reasons. The rectification suggestions include at least one of the following: deleting unnecessary data collection paths, adding authorization or notification logic, performing desensitization or encryption processing on sensitive fields, limiting the range of fields transmitted across boundaries, limiting the range of data fields carried when jumping across mini-programs, adjusting log or telemetry reporting strategies, and supplementing field minimization control. Step 1082: Record the structured fact report, business rationality assessment results, risk exposure assessment results, rule-based rating signals, arbitration conclusions, and rectification recommendations; Step 1083: Organize the structured fact report, rule-based rating signals, arbitration conclusions, and rectification recommendations into audit outputs, and supplement the corresponding line number and settlement name when the evidence anchor point for the reason is missing.

[0029] This invention also discloses a privacy risk discovery and compliance audit system for platform-based application mini-program ecosystems, including a code package access module, a source code preprocessing module, a graph evidence construction module, a path extraction module, a risk identification module, a structured fact generation module, a dual-perspective audit module, a knowledge injection module, an arbitration and rating module, and a rectification generation module. The code package access module is used to obtain the mini-program code package of the target platform and identify the platform type, package format, and interface naming rules. The source code preprocessing module is used to perform platform adaptation unpacking, syntax standardization, and code repair. The graph evidence construction module is used to construct a system dependency graph based on Joern or other code attribute graph engines and establish a registry of sensitive source interface entries and a registry of sensitive sink interface entries, while simultaneously calling CodeQL. A query engine or other semantic program query engine performs a taint propagation query from source to sink to generate candidate propagation path evidence, which is used for candidate path screening, training sample construction, or result verification. The path extraction module is used to extract candidate privacy path slices around sensitive interface nodes by combining the system dependency graph and the candidate propagation path evidence. The risk identification module is used to perform node symbolization, local topological encoding, and global semantic encoding on the candidate privacy path slices. The structured fact generation module is used to perform interface normalization on risk candidate paths and generate structured fact reports. The dual-perspective audit module is used to generate business rationality assessment results and risk exposure assessment results based on the shared fact reports. The knowledge injection module is used to retrieve and inject domain knowledge that matches the platform to which the current candidate path belongs. The arbitration rating module is used to output the target risk level and corresponding reasons by combining rule-based rating signals and domain knowledge. The rectification generation module is used to generate rectification suggestions, supplement evidence anchors, and output them.

[0030] Beneficial effects: The technical solution provided by this invention has at least the following technical effects or advantages: 1. By identifying cross-platform code packages, unpacking for platform adaptation, and normalizing interfaces, it can be compatible with multiple platform-based application mini-program ecosystems under a unified link, reducing the problem of compatibility fragmentation between different platforms.

[0031] 2. A finite-time code repair mechanism driven by a combination of syntax verification and graph parsing verification can improve the parsability of dirty code in real-world projects and reduce missed detections caused by compression, obfuscation, and incomplete code.

[0032] 3. By constructing a system dependency graph and generating evidence of candidate propagation paths, bidirectional code slicing is performed around sensitive interfaces, which can restore data propagation relationships across functions, callbacks, and wrapper interfaces, improving the integrity and verifiability of privacy path discovery.

[0033] 4. The synergistic effect of structured fact reporting, dual-perspective independent auditing, rule-based rating signals, and platform-filtered knowledge injection can improve the interpretability, consistency, and verifiability of audit conclusions.

[0034] 5. By providing rectification suggestions and supplementing evidence anchors, audit results can directly serve subsequent rectification and governance implementation. Attached Figure Description

[0035] Figure 1 This is a flowchart of the overall processing flow of the present invention.

[0036] Figure 2 This is a flowchart of the cross-platform preprocessing, code repair, system dependency graph construction, candidate propagation path evidence generation, and candidate privacy path discovery processes in this invention.

[0037] Figure 3 This is a schematic diagram illustrating the risk candidate path normalization, field-level structured fact generation, and rule-based rating signal generation in this invention.

[0038] Figure 4 This is a flowchart of the shared fact-driven dual-perspective audit, knowledge injection, and arbitration process in this invention.

[0039] Figure 5 This is a flowchart of the rectification generation and result integrity verification process in this invention.

[0040] Figure 6 This is a schematic diagram of the system module structure of the present invention. Detailed Implementation

[0041] To better understand the above technical solutions, the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0042] This invention discloses a method for privacy risk discovery and compliance auditing in the ecosystem of platform-based application mini-programs. The method organizes cross-platform source code acquisition, candidate privacy path discovery, structured fact generation, dual-perspective auditing, arbitration and grading, and rectification generation into a single continuous processing chain, enabling the risk discovery results to directly connect with subsequent grading and rectification generation.

[0043] This embodiment uses the example of the system receiving mini-program code packages from WeChat, Baidu, Douyin, or other platform application ecosystems to illustrate the concept in detail.

[0044] like Figure 1As shown, the overall processing flow of this embodiment includes a cross-platform preprocessing stage, a risk path discovery stage, a structured fact generation and dual-perspective audit stage, an arbitration rating stage, and a rectification generation stage. The input and output objects for each stage are, in order: the mini-program code package, a set of parsable source code, candidate privacy path slices, a set of risk candidate paths, a structured fact report, dual-perspective audit results, arbitration conclusions, and rectification suggestions. The following sections will describe these in conjunction with... Figures 2 to 6 Explain the specific implementation process for each stage: Step 101: Obtain the mini-program code package for the target platform, and identify the package format, platform type, and interface naming rules corresponding to the target platform; Step 102: Perform platform adaptation unpacking, syntax standardization, and code repair on the mini-program code package to obtain a set of parseable source code; Step 103: Construct a system dependency graph based on the parsable source code set, determine sensitive source interfaces and sensitive sink interfaces, generate candidate propagation path evidence, and extract candidate privacy path slices around the sensitive source interfaces and sensitive sink interfaces in combination with the system dependency graph and the candidate propagation path evidence. Step 104: Perform node symbolization, local topological encoding, global semantic encoding and fusion discrimination on the candidate privacy path slices, output risk probability or risk label, and obtain risk candidate path set accordingly; Step 105: Perform interface normalization and evidence processing on each risk candidate path in the risk candidate path set to generate a structured fact report; Step 106: Generate business rationality assessment results and risk exposure assessment results based on the structured fact report; Step 107: Combining the rule-based rating signal and the domain knowledge obtained by platform-based filtering retrieval, arbitrate the business rationality assessment result and the risk exposure assessment result to obtain the target risk level and corresponding reasons; Step 108: Generate and output rectification suggestions based on the target risk level and corresponding reasons.

[0045] The cross-platform preprocessing and candidate privacy path discovery process in this embodiment is as follows: Figure 2 As shown.

[0046] In this embodiment, the code package access module preferably first performs platform identification on the mini-program code package based on the code package suffix, directory structure characteristics, configuration file identifier, host object prefix, and platform-specific component syntax. For example, the system can determine the platform to which the current code package belongs based on whether there are configuration files, interface prefixes, or proprietary directory structures within the code package that correspond to WeChat mini-programs, Baidu mini-programs, or Douyin mini-programs. After completing the platform identification, the system loads the unpacking strategy corresponding to the current platform and restores the code package to its source code directory.

[0047] After unpacking, the source code preprocessing module preferably performs syntax standardization on the source code collection. This syntax standardization includes at least standardizing line breaks, cleaning up irrelevant whitespace differences, filling in local statement boundaries, standardizing the way some object accesses are written, and correcting local non-semantic differences that are clearly incompatible with the parser. The purpose of performing this syntax standardization is to ensure that source code from different platforms and with different development styles meets the most consistent input requirements possible before entering the unified parsing process.

[0048] After syntax standardization, the system preferentially performs syntax validation and graph parsing validation sequentially for each file. Syntax validation identifies explicit JavaScript syntax errors and outputs the error line number, column number, error type, and local context. Graph parsing validation verifies the completeness of the generated code property graph, checking at least whether the output node file, output edge file, and preset key fields are complete. For files that pass syntax validation but fail graph parsing validation, the system further extracts parsing failure information, parser error output, or missing field information as feedback for subsequent repairs.

[0049] For files that still fail the above verification, the system enters a limited-attempt code repair process driven by verification feedback. This process preferably includes the following steps: Step 1021: Perform syntax verification and graph parsing verification on the standardized source code in sequence, identify the files that fail verification and need to be repaired, and extract the error line number, error type, error message, local context or parsing failure information; Step 1022: Input the error information of the file to be repaired and the code to be repaired into the code repair module, and require the code repair module to only repair fatal syntax errors, retain the original functions, variables, methods and statement structures, and not change the original business logic in the prompt constraints; Step 1023: Receive the repaired code returned by the code repair module, and perform syntax verification and graph parsing verification on the repaired code again; Step 1024: If the repaired code still does not meet the preset parsing conditions and the current repair round has not reached the preset maximum number of times, continue to extract new error context and execute the next round of repair; when the current repair round reaches the preset maximum number of times, mark the corresponding file as a parsing failure file and exit the repair.

[0050] In this embodiment, the syntax verification can be performed by a JavaScript verification script driven by ESLint, and the graph parsing verification can be performed by the Joern parsing result verification unit. If the syntax verification returns a clear error line number, the system preferably extracts a local code window containing a preset number of lines before and after the error line number, and requires the code repair model to only repair fatal syntax errors in the corresponding window, maintain the same number of lines in the window, and not change the business logic; if the syntax verification passes but the graph parsing verification still fails, or Joern outputs missing node files, edge files, or key fields such as lineNumber, the system preferably inputs the entire file code along with the parsing failure information into the code repair module to perform full file compatibility repair.

[0051] In this embodiment, the input to the code repair module includes one or more of the following: error type, error message, parser error output, missing field information, the full text of the original code, and error context fragments; its output is preferably the fully repaired target code, rather than fragmented patches, thus facilitating direct entry into the parsing and graph construction process. The code repair module can be implemented using qwen3-coder or other large language models optimized for source code repair. The preset maximum number of repair attempts can be set to 2 to 5; in a preferred implementation, the number of local code repair attempts is 2, and the number of graph parsing compatibility repair attempts is 3.

[0052] Step 1031: After obtaining the set of parsable source code, the graph evidence construction module constructs a system dependency graph based on the call relationships, control relationships, and data usage relationships in the source code. The system dependency graph preferably includes three types of edges: 1. Data dependency edges are used to represent the propagation relationship of variables, object properties, or function return values ​​between different nodes.

[0053] 2. Control dependency edges are used to represent the constraints that conditional statements, loops, or callbacks impose on the execution of subsequent statements.

[0054] 3. Call dependency edges are used to connect the calling point, the called function, and the return point across function boundaries.

[0055] Step 1032: To map privacy events from different platforms to a unified analysis space, the system preferably maintains both a sensitive source interface registry and a sensitive sink interface registry simultaneously. The sensitive source interface registry may include location-based interfaces, device information-based interfaces, identity-based interfaces, user content-based interfaces, and contact information-based interfaces. Step 1033: Establish one or more of the following as sensitive endpoint interface registry points: network request interface, log reporting interface, data persistence interface, file operation interface, and cross-application or cross-mini-program jump interface. Step 1034: In this embodiment, the graph construction and evidence generation processes collaboratively invoke Joern and CodeQL. Joern, as the code attribute graph generation backend, first generates a code attribute graph from the platform-adapted source code, and then extracts control flow, data flow, and call relationships from the code attribute graph to construct a system dependency graph. CodeQL, as the semantic program query backend, encodes cross-platform sensitive source interfaces and sensitive sink interfaces into query predicates, performs taint propagation style queries, and generates candidate propagation paths and corresponding evidence tuples. For any CodeQL return evidence... Its preferred form is: ;in, Represents the source node. Represents the sink node. Indicates the sequence of intermediate propagation anchor points. This represents the set of corresponding code locations. The system further aligns the evidence tuples with the system dependency graph nodes according to file path and line number: ;in, This represents the system's dependency graph node set. The aligned candidate propagation path evidence serves as both an anchor constraint and selection criterion in the candidate path discovery phase, and as initial path labeling candidates in risk identification model training or result verification scenarios. The purpose of employing the Joern-CodeQL collaboration mechanism described above is to simultaneously transform privacy propagation relationships in cross-platform source code into graph structure representations and query evidence representations, thereby improving the completeness, locatability, and verifiability of candidate discovery.

[0056] In this embodiment, the graph evidence construction module not only identifies sensitive interface names directly provided by the platform, but also sensitive calls in object wrapping and alias forms. For example, developers may report behavioral events through a log manager object, write to local files through a file system manager object, wrap request interfaces through object methods, or carry additional data payload fields in cross-mini-program jump interfaces. The system preferably maps the above wrapping patterns uniformly to standardized sensitive sink types.

[0057] Step 1035: In the path discovery phase, the path extraction module combines the system dependency graph and candidate propagation path evidence to perform bidirectional code slicing, using sensitive interface nodes as anchor points. The bidirectional code slice includes at least: 1. Reverse tracing is used to identify the source of sensitive data, such as location calls, login return values, user input fields, and device attribute readings.

[0058] 2. Forward tracing is used to identify the destination of sensitive data, such as network transmission, log reporting, local disk storage, or cross-mini-program data transfer.

[0059] In this embodiment, when the number of candidate slice nodes exceeds a preset threshold At that time, the system sets the anchor point The corresponding set of candidate nodes Each node Calculate the topology retention score: ;in, To traverse the set of candidate nodes The nodes in For nodes to anchor point The shortest graph distance, This represents the sum of the in-degree and out-degree of a node. This means that a value of 1 is assigned when the platform-sensitive interface flag appears directly in the node code, and 0 otherwise. The selection is then based on the stated score. and with The system induces the generation of candidate slice subgraphs. Through the above scoring mechanism, when a slice is too large, the system prioritizes retaining nodes that are closer to the anchor point, have higher structural centrality, and directly carry the platform's semantic anchor point.

[0060] Step 1041: For candidate privacy path slices, this embodiment preferably performs unified node symbolization processing first. In this embodiment, the node symbolization processing includes at least the following rules: 1. Map developer-defined variable names to ordered variable tags, such as VAR1, VAR2.

[0061] 2. Map developer-defined function names to ordered function tags, such as FUN1 and FUN2.

[0062] 3. Replace string literals and numeric literals with uniform constant tokens, such as STR and NUM.

[0063] 4. Retain platform-sensitive interface names and host object prefixes, such as wx, swan, and tt, to maintain the semantic anchors for cross-platform sensitive actions.

[0064] The purpose of adopting the above symbolization rules is to reduce the interference of differences in developer naming styles, string content, and local literals on model judgments, while preserving the platform interface semantics necessary for privacy risk identification. Furthermore, if the symbol... Belongs to the platform sensitive interface token set If it is a symbol, then retain its original name or normalized name; if it is a symbol Belongs to the set of developer-defined function notations If the symbol is , then replace it with the ordered function marker FUN_i; if the marker is , then replace it with the ordered function marker FUN_i. Belongs to the set of developer-defined variable notations If the symbol is , then replace it with the ordered variable marker VAR_j; if the marker is , then replace it with the ordered variable marker VAR_j. They belong to the string literal set or set of numerical literals If , then replace them with STR and NUM respectively; other reserved notations remain unchanged.

[0065] Step 1042: In the risk identification stage, the system preferably adopts a joint modeling approach combining local topological coding and global semantic coding. Let the candidate slice image be... Each node Corresponding initial statement vector The local topology coding unit and the global semantic coding unit can be implemented using existing graph neural networks and self-attention coding structures. A set of preferred representations is given below. The local topology coding unit uses a graph neural network encoder to encode the local graph structure in the candidate slice to capture the dependencies between sensitive source nodes, propagation nodes, and sink nodes; in the first... In layered graph convolution, the node representation can be updated as follows: ;in, Represents a node In the Hidden representation of layers, Indicates the first Layer self-node transformation weight matrix, Indicates the first Layer neighbor message transformation weight matrix, Represents a node The neighborhood group, and These represent the degree of the corresponding node. This represents a non-linear activation function.

[0066] Step 1043: The global semantic coding unit uses a self-attention sequence encoder to encode the node sequence arranged in code order. The preferred method for basic attention calculation is: ;in, Represents the query matrix. Represents the key matrix. Represents a value matrix, This represents the dimension of the key vector.

[0067] Step 1044: In order to combine the two types of features, the system first calculates the fusion gating: ; The fusion representation is then obtained: ;in, This represents the fusion gate weight matrix. This represents the fusion gate bias vector. This represents the gating coefficient vector for the two types of features. This represents the result of local topological coding. This represents the global semantic encoding result. To transform the node-level fused representation into a slice-level representation, the system preferably performs further global attention pooling:

[0068] ;in, Represents a node Normalized weights in global attention pooling This represents the pooling attention weight vector. Represents a node The fusion representation, This represents the set of nodes in the candidate slice graph. This represents the slice-level representation obtained after weighted aggregation. The risk probability is then output based on this slice-level representation. ;in, This represents the output layer weight matrix. This represents the output layer bias vector. This represents the probability distribution corresponding to each risk category. Based on the risk probability, risk label, or candidate ranking score, the system retains samples that meet a preset risk threshold as a set of risk candidate paths.

[0069] Based on the structured fact generation and rule-based signal construction process of the aforementioned risk candidate paths, such as Figure 3 As shown, after receiving the set of risk candidate paths, the structured fact generation module preferentially performs normalization processing on the platform-specific interface names first.

[0070] Step 1051 can map semantically equivalent positioning interfaces on different platforms to a unified positioning event type, map request, upload, log reporting, file system and cross-mini-program jump interfaces on different platforms to a unified hub event type, and identify object wrapper calls or alias calls.

[0071] Step 1052: Identify the request interface, reporting interface, upload interface, and cross-mini-program jump interface carrying additional data payload in the form of object packaging. Step 1053: Generate field-level data flow mapping relationships according to the field source node, intermediate propagation nodes, and target sink node; Step 1054: After completing interface normalization, the system performs evidence processing for each risk candidate path, generating a structured fact report. The structured fact report preferably does not directly output the final risk level, but only outputs an unbiased factual baseline. It includes one or more of the following fields: 1. Privacy-related interfaces and their corresponding line numbers.

[0072] 2. Sensitive data types.

[0073] 3. Field source and field destination.

[0074] 4. Field-level data flow mapping relationships.

[0075] 5. Cross-boundary sink type.

[0076] 6. Start and end positions of the slice.

[0077] 7. Number of nodes, number of edges, and anchor point locations.

[0078] 8. Platform type and candidate construction methods.

[0079] 9. Summary of evidence.

[0080] In this embodiment, the structured fact generation module also records field-level propagation chains, which characterize how a sensitive field propagates from the source node to the target sink node via intermediate variables, object attributes, function return values, or callback parameters. If multiple sensitive fields exist on the same candidate path, the system can provide field-level mapping results separately, facilitating subsequent identification of whether field transmission exceeds the allowed range. For any sensitive field... Its field-level propagation mapping relationship can be represented as: ;in, Represents a node The corresponding sensitive field type marker, Indicates in candidate paths From the source node To the target node There exists a propagation chain through variables, object properties, function return values, or callback parameters. Indicate candidate path The target sink node set in the [database name]. Based on the mapping relationships of each field, the preferred formalization of the structured fact report is: ;in, This indicates the set of privacy-related interfaces and their line numbers. Represents a collection of sensitive data types. Indicates the slice boundary and anchor point position. This represents the metadata of the platform and candidate construction methods. This represents a summary of evidence. This formal representation ensures that subsequent dual-perspective audits always revolve around the same factual baseline, rather than freely expanding directly from the original source code.

[0081] This embodiment further incorporates a rule signal unit within the arbitration grading module to provide stable and verifiable auxiliary judgment criteria for subsequent arbitration stages. For any candidate path... The system first constructs a four-dimensional gating vector: ;in, For the boundary evidence identification results, For the data sensitivity mapping results, For necessity and to agree to the test results, To mitigate and controllable test results.

[0082] For the boundary evidence identification results Discretization is preferably performed according to the following rules: 1. When and When there is an intersection, it is denoted as A2; 2. When and There is an intersection, and and When there is no intersection, it is denoted as ; 3. Other situations are recorded as follows: .

[0083] For data sensitivity mapping results Discretization is preferably performed according to the following rules: 1. When and When there is an intersection, it is denoted as high; 2. When and There is an intersection, and and When there is no intersection, it is denoted as medium; 3. When Non-empty and all its elements belong to When, it is denoted as low; 4. Other cases are recorded as unknown.

[0084] in Indicate candidate path The set of boundary sink types identified in the data. This indicates that strong boundary propagation has been identified. This indicates that weak boundary propagation has been identified. This indicates that no clear cross-border outflow was identified; Preferably, it includes at least a network request interface, an analysis and reporting interface, a real-time log manager, and cross-mini-program navigation carrying extraData; Ideally, it should include at least clipboard writing, sharing, and logging; Preferably, it includes at least location, identity information, contact information, biometrics, and financial information; Preferably, it includes at least device, media, clipboard, and network environment information; Preferably, at least behavioral context information should be included. For the necessity and consent detection dimension, signals such as authorize, authSetting, privacy, user consent, authorization pop-ups, and permission queries should be detected at least. For the mitigation and controllability detection dimension, processing traces such as sanitized, hash, encrypted, and desensitized should be detected at least.

[0085] Step 1071: After obtaining the gating vector, the system generates a regularized proposal signal: ;in, Indicates the recommended level. Indicates heuristic confidence level. This represents the set of explanatory annotations. In this embodiment, the heuristic confidence level can be represented as: ;in, An indicator of the existence of boundary evidence. An indicator quantity that indicates whether sensitivity can be determined. An indicator quantity that indicates whether a consent or mitigation signal has been detected. This indicates whether the cross-mini-program high-sensitivity data transfer mode carrying extraData has been hit. Rule recommendation level. The preferred method is determined according to the following rules: 1. When , When a clear necessity or support for consent is detected, it is recorded as FUNCTIONAL_ESSENTIAL; 2. When If the aforementioned conditions are not met, it is recorded as LOW; 3. When , When no necessity or consent support is detected, no mitigation measures are detected, and there is a cross-mini-program boundary event carrying extraData, it is marked as HIGH; 4. When and When it is high or medium, it is written as MEDIUM; 5. Other cases are marked as LOW.

[0086] in, This indicates that a relatively clear necessity or support for consent has been detected. This indicates that no such support was detected. This indicates that mitigation measures such as desensitization, encryption, or minimization have been detected. This indicates that no such measures were detected. This indicates the existence of a cross-mini-program boundary event carrying extraData. The rule-based grading signal does not directly overwrite the final conclusion, but instead enters the arbitration stage as an independent bypass input after the shared fact audit.

[0087] This embodiment shares a fact-driven, dual-perspective auditing, domain knowledge injection, and arbitration process, such as Figure 4 As shown.

[0088] To avoid inconsistent evidentiary baselines arising from different assessment perspectives starting from the original code, this embodiment requires that business rationale assessment and risk exposure assessment be jointly performed based on the same structured fact report. That is, the system first generates a structured fact report, and then initiates two independent audit modules on that report: a business defender audit submodule and a risk attacker audit submodule, rather than having two roles directly process slices of the original code.

[0089] In this embodiment, the shared fact-gathering process outputs at least one of the following objects: a set of investigated interfaces, a field-level data flow map, a fact summary, slice boundaries, and a set of evidence line numbers. This process does not directly output the final risk level to avoid imposing undue prior constraints on subsequent arbitration in the first round of output.

[0090] Based on shared fact reports, the business rationale assessment role and the risk exposure assessment role conduct reviews from two opposing perspectives. The former focuses on identifying clues such as business necessity, user triggers, authorization pop-ups, authorization status queries, field minimization design, local processing rather than external transmission, and desensitization or encryption measures; the latter focuses on identifying risk points such as cross-boundary external transmission, silent collection, field scope expansion, telemetry reporting, cross-mini-program collaboration, pseudo-mitigation, and the transmission of highly sensitive fields without sufficient control. Both types of roles preferably output specific line numbers, key fact references, recommendation levels, and lists of missing contexts to ensure that disputes always revolve around verifiable code evidence.

[0091] Step 1072: The knowledge injection module employs a dual-channel knowledge injection mechanism. The first channel is a few-sample example channel, used to retrieve audit examples similar to the current candidate slice pattern; the second channel is a domain rule channel, used to retrieve platform rule documents, privacy compliance rules, historical audit cases, and empirical rules. During the retrieval, the system forms a query based on the platform to which the current candidate path belongs, the structured fact summary, the type of sensitive source, the type of sensitive sink, and the point of contention. For candidate paths... The query vector is preferably represented as: ; And perform similarity ranking:

[0092] ;in, Represents the query vector. Represents a knowledge fragment vector. This represents the set of knowledge fragments after platform filtering. The system preferably performs platform filtering before similarity ranking to avoid incorrectly applying the rules of one platform to candidate paths of other platforms.

[0093] The rectification output and result integrity verification process in this embodiment of the invention is as follows: Figure 5 As shown.

[0094] Step 1073: The arbitration rating module simultaneously receives the structured fact report, business rationale assessment results, risk exposure assessment results, rule-based rating signals, and domain knowledge filtered by the platform, and outputs the target risk level and corresponding reasons. In this embodiment, the system first obtains the initial severity based on the shared fact report, business rationale assessment results, and risk exposure assessment results. Then, based on the gating results, construct a feasible severity set and output the final severity using ordinal projection. ;in, , , , When a strong boundary event exists, but verifiable consent signals or mitigation measures are present and not triggered. Under certain conditions, the arbitration rating module can... Remove from the feasible severity set to limit unfounded amplification of high risk.

[0095] Step 1074: The arbitration rating module outputs the final risk level and corresponding reasons, and further outputs the acceptance or rebuttal results of the rule-based rating signals. If the final ruling reasons do not include the minimum traceable evidence anchor point, the system can automatically add start and end line numbers or key remittance point names to ensure that the final report retains at least verifiable coded evidence.

[0096] Step 1081: The rectification generation module generates rectification suggestions based on the target risk level and corresponding reasons. Rectification suggestions should include at least one of the following: deleting unnecessary data collection paths, adding authorization or notification logic, performing anonymization or encryption on sensitive fields, limiting the range of fields transmitted across boundaries, limiting the range of data fields carried when jumping between mini-programs, adjusting log or telemetry reporting strategies, and supplementing field minimization controls.

[0097] Step 1082: Record the structured fact report, business reasonableness assessment results, risk exposure assessment results, rule-based rating signals, arbitration conclusions, and rectification recommendations. Step 1083: The system packages the structured fact report, business reasonableness assessment results, risk exposure assessment results, rule-based rating signals, arbitration conclusions, rectification recommendations, and result integrity verification results into an audit output package. The verification results are used to check for at least one of the following integrity deficiencies: 1. Empty fact summary; 2. Empty ruling reasons; 3. Output content echoing prompts; 4. Ruling reasons lacking line number references; 5. Ruling reasons omitting key endpoint names.

[0098] For arbitration results, the system preferentially performs one evidence supplement: if the final reason does not explicitly mention the code location or boundary point, the start and end line numbers and the detected point are automatically added to the reason to ensure that the final output meets the minimum traceability requirement.

[0099] like Figure 6 As shown, this embodiment also provides a privacy risk discovery and compliance audit system for platform-based application mini-program ecosystems. This system includes at least a code package access module, a source code preprocessing module, a graph evidence construction module, a path extraction module, a risk identification module, a structured fact generation module, a dual-perspective audit module, a knowledge injection module, an arbitration and rating module, and a rectification generation module.

[0100] The code package access module is used to obtain the mini-program code package of the target platform and identify the platform type, package format, and interface naming rules; the source code preprocessing module is used to perform platform adaptation unpacking, syntax standardization, syntax verification, graph parsing verification, and limited code repair; the graph evidence construction module is used to build a system dependency graph based on Joern or other code attribute graph backends and establish a registry of sensitive source point interfaces and a registry of sensitive sink point interfaces, while calling CodeQL. The system queries the backend or other semantic programs to generate candidate propagation paths and their evidence locations. These candidate propagation paths and evidence locations are used for candidate path screening, training sample construction, or result verification. A path extraction module combines the system dependency graph and the candidate propagation path evidence to extract candidate privacy path slices around sensitive interface nodes. A risk identification module performs node symbolization, local topological encoding, and global semantic encoding on the candidate inputs output by the path extraction module, outputting a set of risk candidate paths. A structured fact generation module performs interface normalization on the risk candidate paths and generates a structured fact report. A dual-perspective audit module generates business rationality assessment results and risk exposure assessment results based on the shared fact report. A knowledge injection module retrieves and injects domain knowledge matching the platform to which the current candidate path belongs. An arbitration rating module combines rule-based rating signals and domain knowledge to output the target risk level and corresponding reasons. A rectification generation module generates rectification suggestions, supplements evidence anchors, and outputs them.

[0101] In summary, the technical solution of this embodiment organizes cross-platform code preprocessing, candidate privacy path discovery, structured fact generation, dual-perspective auditing, arbitration and rating, and rectification generation into a complete processing chain, which is applicable to privacy risk discovery and compliance auditing scenarios in the platform-based application mini-program ecosystem. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A method for privacy risk discovery and compliance auditing in the platform-based application mini-program ecosystem, characterized in that, It includes the following steps: Step 101: Obtain the mini-program code package for the target platform, and identify the package format, platform type, and interface naming rules corresponding to the target platform; Step 102: Perform platform adaptation unpacking, syntax standardization, and code repair on the mini-program code package to obtain a set of parseable source code; Step 103: Construct a system dependency graph based on the parsable source code set, determine sensitive source interfaces and sensitive sink interfaces, generate candidate propagation path evidence, and extract candidate privacy path slices around the sensitive source interfaces and sensitive sink interfaces in combination with the system dependency graph and the candidate propagation path evidence. Step 104: Perform node symbolization, local topological encoding, global semantic encoding and fusion discrimination on the candidate privacy path slices, output risk probability or risk label, and obtain risk candidate path set accordingly; Step 105: Perform interface normalization and evidence processing on each risk candidate path in the risk candidate path set to generate a structured fact report; Step 106: Generate business rationality assessment results and risk exposure assessment results based on the structured fact report; Step 107: Combining the rule-based rating signal and the domain knowledge obtained by platform-based filtering retrieval, arbitrate the business rationality assessment result and the risk exposure assessment result to obtain the target risk level and corresponding reasons; Step 108: Generate and output rectification suggestions based on the target risk level and corresponding reasons.

2. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that, In step 102, the cyclic code repair step includes: Step 1021: Perform syntax verification and graph parsing verification on the standardized source code in sequence, identify the files that fail verification and need to be repaired, and extract the error line number, error type, error message, local context or parsing failure information; Step 1022: Input the error information and code to be repaired of the file to be repaired into the code repair module, and output the repaired code while maintaining the original business logic; Step 1023: Perform syntax verification and graph parsing verification on the repaired code again; Step 1024: If the repaired code still does not meet the preset parsing conditions and the current repair round has not reached the preset maximum number of times, continue to execute the next round of repair; if the current repair round reaches the preset maximum number of times, mark the corresponding file as a parsing failure file and exit the repair process.

3. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that, Step 103 specifically includes: Step 1031: Construct a system dependency graph based on the resolvable source code set, including data dependency edges, control dependency edges, and call dependency edges; Step 1032: Establish one or more of the following interfaces as a sensitive source interface registry: location interface, device information interface, identity identifier interface, user content interface, and contact information interface; Step 1033: Establish one or more of the following as sensitive endpoint interface registry points: network request interface, log reporting interface, data persistence interface, file operation interface, and cross-application or cross-mini-program jump interface. Step 1034: Generate candidate propagation path evidence based on the sensitive source interface registry and the sensitive sink interface registry. The candidate propagation path evidence includes at least one of the following: source node, sink node, intermediate propagation anchor point, and corresponding code location. Step 1035: Combining the system dependency graph and the candidate propagation path evidence, using sensitive interface nodes as anchor points, trace the data source nodes and control predecessor nodes in reverse along the system dependency graph, and trace the data destination nodes and call successor nodes in forward, to generate candidate privacy path slices.

4. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that: The system dependency graph is constructed using Joern: a code attribute graph is generated from the platform-adapted source code, and control flow relationships, data flow relationships, and call relationships are extracted from the code attribute graph; The candidate propagation path evidence is generated using CodeQL: the cross-platform sensitive source interface and sensitive sink interface are encoded as query predicates, and a path-type taint propagation query is executed to obtain the source node, sink node, intermediate propagation anchor point and corresponding code position; The candidate propagation path evidence is aligned with the system dependency graph through file paths and line number anchors.

5. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that: In the node symbolization process of step 104, developer-defined variable names are mapped to ordered variable tags, developer-defined function names are mapped to ordered function tags, string literals and numeric literals are replaced with unified constant tags, and platform-sensitive interface names and host object prefixes are retained; the graph neural network encoder is used to encode the local topology in the candidate privacy path slice, the self-attention sequence encoder is used to encode the node sequence arranged in code order, and the risk probability or risk label is output through fusion gating.

6. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that, Step 105 includes: Step 1051: Map semantically equivalent location interfaces, authorization interfaces, network request interfaces, log reporting interfaces, file system interfaces, and cross-mini-program jump interfaces across different platforms to a unified event type; Step 1052: Identify the request interface, reporting interface, upload interface, and cross-mini-program jump interface carrying additional data payload in the form of object packaging. Step 1053: Generate field-level data flow mapping relationships according to the field source node, intermediate propagation nodes, and target sink node; Step 1054: Generate a structured fact report. The structured fact report includes at least one of the following: privacy-related interfaces and their corresponding line numbers, sensitive data types, field sources, field destinations, cross-boundary sink types, slice start and end positions, number of nodes, number of edges, anchor positions, platform type, and candidate construction methods.

7. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem as described in claim 1, characterized in that: In step 106, the business rationality assessment result and the risk exposure assessment result are generated by the business defender audit submodule and the risk attacker audit submodule, respectively, which work around the same structured fact reporting. The business rationality assessment result is used to identify clues such as user triggers, authorization notifications, business necessity, field minimization, and mitigation measures. The risk exposure assessment results are used to identify risks such as cross-border transmission, telemetry reporting, cross-mini-program collaboration, field expansion, and pseudo-mitigation. Both the Business Defender Audit Submodule and the Risk Attacker Audit Submodule output one or more of the following: line number references, key fact references, recommendation levels, and a list of missing contexts.

8. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem according to claim 1, characterized in that: In step 107, the rule-based rating signal is generated by at least one of boundary evidence identification, data sensitivity mapping, necessity and consent detection, and mitigation and controllability detection. The boundary evidence identification is used to identify at least one of network requests, log reporting, real-time log managers, and cross-mini-program jumps carrying additional data payloads. The domain knowledge includes at least one of platform rule documents, privacy compliance rules, historical audit cases, and few-sample audit examples. Its retrieval adopts similarity ranking combined with platform filtering constraints to match the retrieval results with the platform to which the current candidate path belongs.

9. The privacy risk discovery and compliance auditing method for platform-based application mini-program ecosystem according to claim 1, characterized in that: The rectification recommendations include at least one of the following: deleting unnecessary data collection paths, adding authorization or notification logic, performing desensitization or encryption processing on sensitive fields, limiting the range of fields transmitted across boundaries, limiting the range of data fields carried when jumping across mini-programs, adjusting log or telemetry reporting strategies, and supplementing field minimization control.

10. A privacy risk discovery and compliance auditing system for platform-based application mini-program ecosystems, characterized in that, include: The code package access module is used to obtain the mini-program code package of the target platform and identify the platform type, package format and interface naming rules; The source code preprocessing module is connected to the code package access module. It is used to perform platform adaptation unpacking, syntax standardization and code repair. When parsing fails, it calls the code repair module to output the repaired code and obtains a set of parsable source code. The graph evidence construction module, connected to the source code preprocessing module, is used to construct a system dependency graph, establish a sensitive source point interface registry and a sensitive sink point interface registry, and generate candidate propagation path evidence. The path extraction module, connected to the graph evidence construction module, is used to extract candidate privacy path slices around sensitive interface nodes by combining the system dependency graph and the candidate propagation path evidence. The risk identification module, connected to the path extraction module, is used to perform node symbolization, local topological encoding, and global semantic encoding on candidate privacy path slices, and output a set of risk candidate paths; A structured fact generation module, connected to the risk identification module, is used to perform interface normalization on risk candidate paths and generate a structured fact report; The structured fact generation module, connected to the risk identification module, is used to perform interface normalization on risk candidate paths and generate a structured fact report; The dual-perspective audit module, connected to the structured fact generation module, is used to generate business rationality assessment results and risk exposure assessment results based on shared fact reports; The knowledge injection module is used to retrieve and inject domain knowledge that matches the platform to which the current candidate path belongs; The arbitration rating module connects the dual-perspective audit module and the knowledge injection module, and is used to combine rule-based rating signals and domain knowledge to output the target risk level and corresponding reasons. The rectification generation module, connected to the arbitration rating module, is used to generate rectification suggestions, supplement evidence anchors, and output audit results.

Images