A low-code platform custom component security detection method and system

Abstract

The application discloses a low-code platform self-defined component security detection method and system, and belongs to the technical field of software security. The application aims at the problems of single detection dimension, incomplete coverage, and disconnection of static and dynamic risks of existing components, extracts metadata by analyzing component packages, and constructs a pollution rule library to complete static risk full-path tracking; a simulated running sandbox is built to trigger the full execution path of the component, and dynamic risk detection is realized by collecting running behavior data; the static and dynamic detection results are fused, and permission boundary, compliance rules and recursive dependency detection are executed to finally generate a risk detection report and control instruction. The application covers both static code and dynamic running risks of components, has comprehensive detection dimension and high precision, and can effectively improve the safety control level of low-code platforms for self-defined components, and adapt to the safety detection needs of components in multiple scenarios.

Description

Technical Field

[0001] This invention relates to the field of software security technology, and in particular to a method and system for security detection of custom components on a low-code platform. Background Technology

[0002] Low-code development platforms are core tools in the next generation of information technology that simplify application development processes and improve the efficiency of digital construction. With their visual configuration and modular reusable development model, they significantly lower the technical threshold for application development and are widely used in business system construction and functional expansion scenarios across various industries. Custom components, as an important carrier for functional expansion on low-code platforms, cover various types, including front-end interactive components and back-end service components. Users can enrich platform functionality by uploading custom component packages, and the application scope and frequency of use of these components continue to increase with the popularization of low-code platforms. Current software testing technologies have formed mature technical directions such as static code analysis and dynamic behavior monitoring. Code parsing, data flow tracing, and runtime environment simulation are widely used in the field of software security testing, providing basic technical support for the security testing of low-code platform components. The industry is also gradually forming standardized management and operation specifications for low-code components.

[0003] Existing security detection solutions for custom components on low-code platforms suffer from fragmented processes and limited detection dimensions. They fail to build a comprehensive detection system covering component parsing, code analysis, runtime monitoring, and permission verification, and struggle to leverage component metadata for data integration and collaborative processing across different detection stages. Some solutions only perform static scanning of component code, failing to simulate the dynamic behavior collection in the actual low-code platform environment, thus overlooking hidden security risks during component operation. Other solutions do not combine component permission declarations with actual runtime behavior for compliance verification, failing to identify issues of permission overreach and abuse. Furthermore, existing solutions cannot integrate multi-dimensional detection results to form a unified risk assessment basis and control instructions, making it difficult to achieve full-process security control over the uploading, publishing, and operation of custom components, and ultimately failing to provide comprehensive security assurance for the stable operation of low-code platforms. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and system for security detection of custom components on a low-code platform.

[0005] The objective of this invention is achieved through the following technical solution: A method for security detection of custom components on a low-code platform is provided, which includes the following steps: S1. Receive custom component packages. Custom component packages are function extension code packages uploaded by users to the low-code platform. Perform format validation and parsing on the custom component packages, and extract the metadata of the custom component packages. The metadata includes component type, permission declaration list, dependency package list, entry file information and front-end and back-end component mapping relationship. S2. Perform syntax parsing on the code content of the custom component package, use the extracted metadata of the custom component package to build a taint rule base, the taint rule base is a set of rules that mark the sensitive data flow path, perform full path taint tracking processing, identify static risk content, and generate static detection results; S3. Use the extracted metadata of the custom component package to build a low-code platform to simulate the runtime context, build an isolation sandbox, trigger the full execution path of the custom component package in the isolation sandbox, collect runtime behavior data, and combine the generated static detection results to generate dynamic detection results; S4. Using the extracted metadata of the custom component package, the generated static detection results, and the generated dynamic detection results, perform permission boundary verification and compliance rule verification, integrate risk content, and generate risk detection reports and control instructions.

[0006] Furthermore, the parsing process in step S1 includes the following sub-steps: S1.1. Identify the component types of the custom component package. Component types include front-end components, back-end service components, and front-end and back-end matching binding components. Front-end components include general module specification component packages, page framework building component packages, and low-code platform adaptation component packages. Back-end service components include bytecode format component packages, interpreted language packaging component packages, and web page assembly format component packages. S1.2. Decompress and verify the integrity of the custom component packages that have completed type identification, check the file structure and format, and remove custom component packages with incorrect format and corrupted data; S1.3. Retrieve the historical version storage data of the custom component package that has completed format verification, compare it file by file with the current component package, mark the changed areas of code and configuration, and generate an incremental detection list based on the changed areas. The incremental detection list is a list file that marks the version change content and limits the detection scope. The incremental detection list limits the processing scope of subsequent detections.

[0007] Furthermore, the full-path taint tracing process in step S2 includes the following sub-steps: S2.1. Perform syntax parsing on the code content of the custom component package, generate an abstract syntax tree for script code, generate a bytecode instruction set for the compiled code, and construct a code control flow graph using the abstract syntax tree or bytecode instruction set. The code control flow graph is a directed graph data that reflects the code execution order and branch jump relationship. S2.2. Use the extracted metadata of the custom component package to define taint sources and taint aggregation points, and build a taint rule base. The taint sources include the low-code platform global context object, user information fields, platform application programming interfaces and cross-component communication receiving ports. The taint aggregation points include network request interfaces, data storage interfaces, cross-component communication sending ports and dynamic code execution interfaces. S2.3. Use the constructed code control flow graph to traverse all execution branches, trace the flow path of tainted data from taint source to taint convergence point, record function call and data transfer relationship, identify static risk content, and integrate risk content and path information to form static detection results.

[0008] Furthermore, step S3, which involves the full execution path triggering and runtime behavior data collection, includes the following sub-steps: S3.1. Inject the extracted metadata of the custom component package into the low-code platform simulation runtime context. The low-code platform simulation runtime context is a set of variables, interfaces and permissions that restore the platform's production environment, including platform global objects, platform application programming interfaces, user permission environment and business data sources, which are consistent with the actual platform runtime environment. S3.2. Build a front-end isolation sandbox and a back-end isolation sandbox. The front-end isolation sandbox intercepts global object access behavior through a proxy mechanism, and the back-end isolation sandbox intercepts resource call behavior through a class loading mechanism, so as to achieve mutual isolation between the component runtime environment and the detection environment that injects the simulated runtime context. S3.3. Parse the entry file information of the custom component package, identify lifecycle functions, event callback functions and externally callable methods, generate simulated input parameters according to the parameter format, and traverse and trigger all execution paths of the components in the isolation sandbox according to the execution logic; S3.4. Collect behavioral data during the operation of the isolation sandbox. The behavioral data includes interface calls, permission usage, network transmission, and data read / write behavior. Compare the generated static detection results to identify dynamic risk content and form dynamic detection results.

[0009] Furthermore, the permission boundary verification and compliance rule verification in step S4 include the following sub-steps: S4.1. Construct a formal permission model using the permission declaration list extracted from the metadata of the custom component package. The formal permission model is a first-order logical formal expression model for permission compliance verification, including three modules: permission definition module, logical constraint module, and rule mapping module. It is divided into three levels: basic attribute layer, constraint rule layer, and verification output layer. The basic attribute layer connects to the permission definition module, the permission definition module connects to the logical constraint module, the logical constraint module connects to the rule mapping module, and the rule mapping module connects to the verification output layer. During construction, basic parameters are entered in the basic attribute layer, first-order logical constraint rules are entered in the logical constraint module, and the rule mapping module binds the permission declaration list and constraint rules. S4.2. Extract the actual set of component usage permissions from the generated static detection results and the generated dynamic detection results, compare it with the permission declaration list, and perform permission boundary verification; S4.3. Call preset compliance rules to verify component operation behavior and data flow behavior, and identify non-compliant behavior content; S4.4. Integrate the identified static risk content, identified dynamic risk content, and identified non-compliant behavior content to generate risk detection reports and control instructions.

[0010] Furthermore, in step S2, the dependency package list in the extracted metadata of the custom component package is read, and recursive parsing is performed on each dependency package in the list. Using the same syntax parsing and control flow construction method as the custom component package, full-path taint tracing is performed on the dependency package code to track the location and transmission path of taint data, identify the risky content of the dependency package, and merge the identified risky content of the dependency package with the identified risky content of the component itself, and incorporate them into the static detection result. The merged static detection result reflects the risks introduced by the component body and the dependency package, providing risk basis data for subsequent dynamic detection and permission verification.

[0011] Furthermore, in step S3, the front-end and back-end component mapping relationship in the extracted metadata of the custom component package is used to associate the collection behavior data of the front-end and back-end components, establish the front-end and back-end data transmission link, and use the associated behavior data to construct a full-link data flow graph. The full-link data flow graph is a structured topology data that records the complete flow process of front-end and back-end data, and marks the corresponding interface calls and permission usage information for data transmission. The full-link data flow graph and the identified dynamic risk content are jointly incorporated into the dynamic detection results to reflect the risk behaviors generated by cross-terminal linkage.

[0012] Furthermore, in step S4, permission boundary verification is performed using the set satisfiability model theory solver. The verification includes determining whether the extracted actual set of usage permissions is included in the permission declaration list, whether the permission declaration list meets the minimum permission requirements of the component function, and whether there is any leakage in permission flow. The solver uses the constructed formal permission model to perform logical judgments and outputs permission overreach identifiers, permission redundancy identifiers, and permission leakage identifiers. The identifiers are bound to the behavioral data to form permission verification results, which serve as the basis for generating risk detection reports and control instructions.

[0013] Furthermore, in step S4, the severity level is divided according to the scope of impact and nature of the integrated risk content. The level is divided according to preset judgment conditions, and different levels correspond to different handling logics. Based on the level division results, corresponding control instructions are generated. The control instructions are divided into component release interception instructions, component operation scope restriction instructions, and component normal release instructions. The control instructions are written into the risk detection report and synchronized to the low-code platform control system.

[0014] A security detection system for custom components on a low-code platform is provided. This system includes a component preprocessing and parsing module, a static taint tracking and detection module, an isolation sandbox dynamic detection module, a formal permission verification module, and a risk control output module. The component preprocessing and parsing module performs component package format verification, decompression comparison, and metadata extraction. The static taint tracking and detection module uses the extracted metadata to perform code parsing, control flow graph construction, taint tracking, and dependency package risk detection. The isolation sandbox dynamic detection module uses the extracted metadata and static detection results to perform simulated context construction, sandbox setup, path triggering, and behavior collection. The formal permission verification module uses the detection results to perform formal permission model construction and permission boundary and compliance rule verification. The risk control output module uses the verification results to perform risk level classification, report generation, and control instruction output.

[0015] The beneficial effects of this invention are: (1) Through the coherent detection steps of component package parsing, static taint tracking, dynamic behavior collection and permission compliance verification, the whole process security detection of low-code custom components is carried out, covering the static code and runtime behavior of the components, improving the coherence of the detection process and the completeness of risk identification. (2) By combining component metadata to build a taint rule base and simulated running environment, the abnormal flow of sensitive data in components and the violation of permission usage issues can be accurately identified, reducing the environment dependence of detection and reducing the missed detection of hidden security risks; (3) By integrating risk rating and control instructions, a standardized basis for component security control is provided for low-code platforms, the detection and processing efficiency is optimized, and the platform’s security management capabilities and operational stability for custom components are improved. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a security detection method for custom components on a low-code platform. Figure 2 The flowchart illustrates the specific steps of a security detection method for custom components on a low-code platform, as provided in this embodiment. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1 See Figure 1 This embodiment provides a security detection method for custom components on a low-code platform, which includes the following steps: S1. Receive custom component packages. Custom component packages are function extension code packages uploaded by users to the low-code platform. Perform format validation and parsing on the custom component packages, and extract the metadata of the custom component packages. The metadata includes component type, permission declaration list, dependency package list, entry file information and front-end and back-end component mapping relationship. S2. Perform syntax parsing on the code content of the custom component package, use the extracted metadata of the custom component package to build a taint rule base, the taint rule base is a set of rules that mark the sensitive data flow path, perform full path taint tracking processing, identify static risk content, and generate static detection results; S3. Use the extracted metadata of the custom component package to build a low-code platform to simulate the runtime context, build an isolation sandbox, trigger the full execution path of the custom component package in the isolation sandbox, collect runtime behavior data, and combine the generated static detection results to generate dynamic detection results; S4. Using the extracted metadata of the custom component package, the generated static detection results, and the generated dynamic detection results, perform permission boundary verification and compliance rule verification, integrate risk content, and generate risk detection reports and control instructions.

[0019] In some embodiments, the parsing process in step S1 includes the following sub-steps: S1.1. Identify the component types of the custom component package. Component types include front-end components, back-end service components, and front-end and back-end matching binding components. Front-end components include general module specification component packages, page framework building component packages, and low-code platform adaptation component packages. Back-end service components include bytecode format component packages, interpreted language packaging component packages, and web page assembly format component packages. S1.2. Decompress and verify the integrity of the custom component packages that have completed type identification, check the file structure and format, and remove custom component packages with incorrect format and corrupted data; S1.3. Retrieve the historical version storage data of the custom component package that has completed format verification, compare it file by file with the current component package, mark the changed areas of code and configuration, and generate an incremental detection list based on the changed areas. The incremental detection list is a list file that marks the version change content and limits the detection scope. The incremental detection list limits the processing scope of subsequent detections.

[0020] In some embodiments, the full-path taint tracing process in step S2 includes the following sub-steps: S2.1. Perform syntax parsing on the code content of the custom component package, generate an abstract syntax tree for script code, generate a bytecode instruction set for the compiled code, and construct a code control flow graph using the abstract syntax tree or bytecode instruction set. The code control flow graph is a directed graph data that reflects the code execution order and branch jump relationship. S2.2. Use the extracted metadata of the custom component package to define taint sources and taint aggregation points, and build a taint rule base. The taint sources include the low-code platform global context object, user information fields, platform application programming interfaces and cross-component communication receiving ports. The taint aggregation points include network request interfaces, data storage interfaces, cross-component communication sending ports and dynamic code execution interfaces. S2.3. Use the constructed code control flow graph to traverse all execution branches, trace the flow path of tainted data from taint source to taint convergence point, record function call and data transfer relationship, identify static risk content, and integrate risk content and path information to form static detection results.

[0021] In some embodiments, the full execution path triggering and runtime behavior data collection in step S3 includes the following sub-steps: S3.1. Inject the extracted metadata of the custom component package into the low-code platform simulation runtime context. The low-code platform simulation runtime context is a set of variables, interfaces and permissions that restore the platform's production environment, including platform global objects, platform application programming interfaces, user permission environment and business data sources, which are consistent with the actual platform runtime environment. S3.2. Build a front-end isolation sandbox and a back-end isolation sandbox. The front-end isolation sandbox intercepts global object access behavior through a proxy mechanism, and the back-end isolation sandbox intercepts resource call behavior through a class loading mechanism, so as to achieve mutual isolation between the component runtime environment and the detection environment that injects the simulated runtime context. S3.3. Parse the entry file information of the custom component package, identify lifecycle functions, event callback functions and externally callable methods, generate simulated input parameters according to the parameter format, and traverse and trigger all execution paths of the components in the isolation sandbox according to the execution logic; S3.4. Collect behavioral data during the operation of the isolation sandbox. The behavioral data includes interface calls, permission usage, network transmission, and data read / write behavior. Compare the generated static detection results to identify dynamic risk content and form dynamic detection results.

[0022] In some embodiments, the permission boundary verification and compliance rule verification in step S4 include the following sub-steps: S4.1. Construct a formal permission model using the permission declaration list extracted from the metadata of the custom component package. The formal permission model is a first-order logical formal expression model for permission compliance verification, including three modules: permission definition module, logical constraint module, and rule mapping module. It is divided into three levels: basic attribute layer, constraint rule layer, and verification output layer. The basic attribute layer connects to the permission definition module, the permission definition module connects to the logical constraint module, the logical constraint module connects to the rule mapping module, and the rule mapping module connects to the verification output layer. During construction, basic parameters are entered in the basic attribute layer, first-order logical constraint rules are entered in the logical constraint module, and the rule mapping module binds the permission declaration list and constraint rules. S4.2. Extract the actual set of component usage permissions from the generated static detection results and the generated dynamic detection results, compare it with the permission declaration list, and perform permission boundary verification; S4.3. Call preset compliance rules to verify component operation behavior and data flow behavior, and identify non-compliant behavior content; S4.4. Integrate the identified static risk content, identified dynamic risk content, and identified non-compliant behavior content to generate risk detection reports and control instructions.

[0023] In some embodiments, in step S2, the dependency package list in the extracted metadata of the custom component package is read, and recursive parsing is performed on each dependency package in the list. Using the same syntax parsing and control flow construction method as the custom component package, full-path taint tracing is performed on the dependency package code to track the location and transmission path of taint data, identify the risky content of the dependency package, and merge the identified risky content of the dependency package with the identified risky content of the component itself, and incorporate them into the static detection result. The merged static detection result reflects the risks introduced by the component body and the dependency package, providing risk basis data for subsequent dynamic detection and permission verification.

[0024] In some embodiments, in step S3, the front-end and back-end component mapping relationship in the extracted metadata of the custom component package is used to associate the collection behavior data of the front-end and back-end components, establish the front-end and back-end data transmission link, and use the associated behavior data to construct a full-link data flow graph. The full-link data flow graph is a structured topology data that records the complete flow process of front-end and back-end data, and marks the interface calls and permission usage information corresponding to data transmission. The full-link data flow graph and the identified dynamic risk content are jointly incorporated into the dynamic detection results to reflect the risk behaviors generated by cross-terminal linkage.

[0025] In some embodiments, in step S4, permission boundary verification is performed by a set satisfiability model theory solver. The verification includes determining whether the extracted actual set of usage permissions is included in the permission declaration list, whether the permission declaration list meets the minimum permission requirements of the component function, and whether there is any leakage in permission flow. The solver uses the constructed permission formal model to perform logical judgment and outputs permission overreach identifier, permission redundancy identifier, and permission leakage identifier. The identifiers are bound to the behavior data to form the permission verification result, which serves as the basis for generating risk detection reports and control instructions.

[0026] In some embodiments, in step S4, the severity level is divided according to the scope of impact and nature of behavior of the integrated risk content. The level is divided according to preset judgment conditions. Different levels correspond to different handling logics. Based on the level division results, corresponding control instructions are generated. The control instructions are divided into component release interception instructions, component operation scope restriction instructions, and component normal release instructions. The control instructions are written into the risk detection report and synchronized to the low-code platform control system.

[0027] A security detection system for custom components on a low-code platform is provided. This system includes a component preprocessing and parsing module, a static taint tracking and detection module, an isolation sandbox dynamic detection module, a formal permission verification module, and a risk control output module. The component preprocessing and parsing module performs component package format verification, decompression comparison, and metadata extraction. The static taint tracking and detection module uses the extracted metadata to perform code parsing, control flow graph construction, taint tracking, and dependency package risk detection. The isolation sandbox dynamic detection module uses the extracted metadata and static detection results to perform simulated context construction, sandbox setup, path triggering, and behavior collection. The formal permission verification module uses the detection results to perform formal permission model construction and permission boundary and compliance rule verification. The risk control output module uses the verification results to perform risk level classification, report generation, and control instruction output.

[0028] Example 2 This embodiment provides a specific implementation process for a security detection method for custom components on a low-code platform. This process revolves around the full-process security detection of custom component packages, achieving security control over custom components on the low-code platform through component parsing, static risk detection, dynamic behavior monitoring, and permission and compliance verification. Figure 2 As shown, the specific implementation process is as follows: Step 1. Custom component package reception and metadata extraction: This embodiment first receives a custom component package, which is a packaged file of functional extension code uploaded by the user to the low-code platform. This file is the carrier of the custom component code, configuration information, and dependencies, and is the core file format for the low-code platform to implement functional extensions. The custom component package undergoes format validation and parsing. The parsing process includes three sub-steps: type identification, integrity verification, and incremental comparison. Through parsing, the basic attributes and operational rule data of the component are obtained, providing basic data support for subsequent detection steps and preventing the detection process from being interrupted due to abnormal component package format or missing data.

[0029] Step 1.1. Perform file header identifier parsing on the received custom component package, extract the format feature fields in the file header, complete type matching according to the preset component type classification standard, distinguish between front-end components, back-end service components, and front-end and back-end matching binding components. Front-end components adapt to the general module specification packaging format, page framework construction packaging format, and low-code platform-specific adaptation packaging format. Back-end service components adapt to the bytecode compilation format, interpreted language packaging format, and web page assembly compilation format, which will form the corresponding processing rules for subsequent decompression and verification matching.

[0030] Step 1.2. Perform layered decompression on the custom component packages that have completed type identification according to the corresponding format. Disassemble the file directories and code files inside the component package layer by layer. After decompression, verify the file directory structure against the low-code platform component standard. Verify the integrity of the file data through data verification and comparison. Filter out component packages that do not conform to the standard, have disordered directory structure, or have damaged data and perform automatic rejection. Only retain compliant component packages to enter the version comparison stage.

[0031] Step 1.3. Retrieve the historical version data corresponding to the current component package from the low-code platform version repository. Perform a file-by-file, code-by-code-segment, and configuration-by-configuration-item comparison between the current component package and the historical version data. Accurately mark the changed areas of code content, configuration parameters, dependencies, and permission declarations. Generate an incremental detection list based on the coverage of the changed areas and the modified content. The incremental detection list is a list file that marks the version changes and limits the detection scope. The incremental detection list directly limits the core processing scope of subsequent detection and reduces invalid detection operations.

[0032] After completing the above sub-steps, extract the metadata of the custom component package. The metadata is structured data that describes the basic attributes and operating rules of the custom component package. The metadata includes component type, permission declaration list, dependency package list, entry file information, and front-end and back-end component mapping relationship. The metadata serves as the core input data for all subsequent detection steps and directly determines the accuracy of taint rule construction, simulation environment setup, and permission verification. The metadata extraction process is automatically completed through software parsing logic without manual intervention, improving the efficiency and consistency of data extraction.

[0033] The component preprocessing and parsing module is the functional carrier for performing the above steps. The component preprocessing and parsing module includes four execution units: a file receiving unit, a format verification unit, a version comparison unit, and a metadata extraction unit. The file receiving unit is responsible for receiving custom component packages and caching them to a specified storage path. The format verification unit performs decompression and integrity checks according to preset file format standards. The version comparison unit retrieves historical version data and performs field-by-field comparison. The metadata extraction unit traverses the internal configuration files of the component package, extracts five types of data: component type, permission declaration list, dependency package list, entry file information, and front-end and back-end component mapping relationship, and organizes them into a structured data format. The four units perform operations in sequence, and the output data of the previous unit is directly used as the input data of the next unit, forming a coherent parsing and processing flow.

[0034] Table 1. Correspondence between Custom Component Package Types and Parsing Methods Component Type File format Parsing tools Core parsing object Front-end components General module specification package JS code parser Component rendering function Front-end components Page Frame Builder Framework syntax parser Component lifecycle functions Backend service components bytecode format package bytecode decompilation tools Class methods and interfaces Backend service components Interpreted language package Script parser Service execution function Front-end and back-end matching binding components Combined Packaging Format Dual-ended cooperative parser Front-end and back-end communication interfaces In some specific implementations, the parsing and processing of custom component packages are matched with the corresponding parsing methods according to the component type, as shown in Table 1. Different component types use dedicated parsing tools and core parsing objects, which can improve the adaptability of parsing and processing, reduce the occurrence of parsing errors, and control the parsing and processing time within the set range, thus ensuring the execution efficiency of the overall detection process.

[0035] In some specific implementations, the integrity verification of custom component packages adopts a hash verification method. The MD5 hash algorithm is selected to perform the verification calculation. First, the hash value of the custom component package to be tested is calculated, and then compared with the hash benchmark value of the legal component package preset by the low-code platform. If the hash values ​​are the same, the component package is determined to be complete. If the hash values ​​are inconsistent, the component package is determined to be tampered with or damaged. This verification process can identify abnormal component packages with a data missing ratio exceeding a set threshold. At the same time, it performs an automatic rejection operation on component packages with incorrect formats. The rejection process does not require manual intervention and directly blocks abnormal component packages from entering the subsequent detection stage, reducing the interference of abnormal data on the detection results.

[0036] Step 2. Static code analysis and taint detection: This embodiment performs syntax parsing on the code content of the custom component package. Syntax parsing is a software processing process that converts code text into analyzable structured data. The extracted metadata of the custom component package is used to construct a taint rule base. The taint rule base is a set of rules that mark the flow path of sensitive data and is used to define the generation and outflow nodes of sensitive data. Full-path taint tracing is performed. Full-path taint tracing is an analysis process that traverses all branches of the code and traces the complete flow path of sensitive data to identify static risk content and generate static detection results. The static detection results are a set of risk content and path information output based on the static analysis of the code. This step completes risk identification without running the component code, reducing the environment dependency caused by code execution.

[0037] Step 2.1. Call a multi-language-compatible syntax parsing tool to process the component code file line by line. For script-type code, perform lexical analysis, syntax analysis, and semantic analysis in sequence to generate an abstract syntax tree that represents the logical structure of the code. The abstract syntax tree stores core structures such as variable definitions, function calls, and conditional judgments in the form of nodes. Perform decompilation and extraction operations on the compiled code to generate a complete bytecode instruction set, record the underlying execution instructions and call relationships of the code, and sort out the code execution jump and branch judgment logic based on the abstract syntax tree or bytecode instruction set to build a complete code control flow graph that covers all execution paths.

[0038] Step 2.2. Based on the configuration parameters of the component runtime environment in the metadata, define the entry points for sensitive data generation and the exit points for risk outflow, and complete the definition of taint sources and taint aggregation points. The taint sources cover four types of sensitive data entry points: low-code platform global context object, user information fields, platform application programming interfaces, and cross-component communication receiving ports. The taint aggregation points cover four types of risky data exit points: network request interfaces, data storage interfaces, cross-component communication sending ports, and dynamic code execution interfaces. Based on the definition results, a standardized taint rule base is built to provide a unified rule basis for subsequent taint tracking.

[0039] Step 2.3. Based on the constructed code control flow graph, traverse all execution branches of the code, track the complete flow path of tainted data according to the judgment criteria of the tainted rule base, record function calls, data processing, and interface call relationships in real time during the tainted data transmission process, identify static risk content such as unmasked sensitive data, unauthorized calls, and malicious code execution, and integrate the risk content, risk code location, and data flow path into structured data to form a complete static detection result.

[0040] This embodiment reads the dependency package list from the extracted metadata of the custom component package, performs recursive parsing on each dependency package in the list, adopts the same syntax parsing and control flow construction method as the custom component package, performs full-path taint tracing on the dependency package code, tracks the location and transmission path of taint data, identifies risky content in the dependency package, merges the identified risky content in the dependency package with the identified risky content in the component itself, and incorporates them into the static detection result. The merged static detection result reflects the risks introduced by the component body and dependency packages, providing risk basis data for subsequent dynamic detection and permission verification. This processing method can cover risks at the component supply chain level and improve the comprehensiveness of static detection.

[0041] The static taint tracking and detection module comprises four execution units: a syntax parsing unit, a taint rule construction unit, a control flow analysis unit, and a recursive detection unit. The syntax parsing unit adapts to the parsing logic of script-type code and compiled code, generating an abstract syntax tree and bytecode instruction set, respectively. The taint rule construction unit defines taint sources and taint convergence points based on metadata, completing the construction of the taint rule library. The control flow analysis unit generates a code control flow graph based on structured data, performing full branch traversal and taint flow tracing. The recursive detection unit performs loop parsing on the dependency package list, performing risk detection on each dependency package one by one. The four units work together to achieve full-dimensional static risk identification of the component body and dependency packages.

[0042] Table 2 Classification of Pollution Sources and Pollution Convergence Points Data types Pollution source classification Stain aggregation point classification Risk assessment criteria User data User information fields Network request interface Undesensitized hair Platform data Global Context Object Data storage interface Unauthorized storage Interface data Platform Application Programming Interface Cross-component communication sending port Passing privilege overflow Communication data Cross-component communication receiving port Dynamic code execution interface Malicious code call In some specific implementations, the taint rule base is constructed based on data type to divide taint sources and taint aggregation points, as shown in Table 2. Each type of data corresponds to exclusive risk judgment conditions. By matching the flow path and judgment conditions, static risk content can be quickly identified, and the location of risk points can be accurately located at the line level of code, thereby improving the reference value of static detection results.

[0043] In some specific implementations, the code control flow graph is constructed using a depth-first traversal algorithm. First, three types of logical nodes are extracted from the code: conditional statements, loop jumps, and function calls. Then, the nodes are connected according to the code execution order to form a directed graph. During the traversal, all branch paths are covered, and no execution path is missed. This algorithm can handle component files with a set number of lines of code while maintaining the structural integrity of the control flow graph. It ensures that taint tracing can cover all code execution paths and avoids the inability to identify static risks due to path omissions.

[0044] In some specific implementations, for the recursive detection process of dependency packages in custom component packages, the number of dependent packages associated with a single component package is set to no more than 8, and the recursive detection depth is set to 3 levels. This is to solve the problem of missed supply chain risks caused by excessively deep dependency package levels. During the recursive detection process, the first-level direct dependency packages in the dependency package list are read first, and syntax parsing and taint tracking are performed. Then, the sub-dependencies of the first-level dependency packages are included in the detection scope, and so on down to the third-level dependency packages. Each layer of dependency packages adopts the same code control flow graph construction method and taint rule judgment standard as the custom component package. After the detection is completed, the risk data of each layer of dependency packages is classified by level and merged into the static detection results of the component body. At the same time, the name and version number of the dependency package to which the risk belongs are marked, which is convenient for subsequent risk location. This value setting can balance the comprehensiveness and efficiency of detection, avoid the detection process bottleneck caused by infinite recursion, and cover the dependency level range of most low-code components.

[0045] Step 3. Simulate environment operation and collect dynamic behavior data: This embodiment uses the extracted metadata of the custom component package to construct a low-code platform simulation runtime context. The low-code platform simulation runtime context is a set of variables, interfaces, and permissions that restore the platform's production environment. It is used to simulate the actual running environment of the component on the low-code platform and build an isolation sandbox. The isolation sandbox is an independent running container used to isolate the custom component package's runtime environment from the detection host environment. The full execution path of the custom component package is triggered in the isolation sandbox, and runtime behavior data is collected. Combined with the generated static detection results, dynamic detection results are generated. The dynamic detection results are a set of risk content and behavior data collected and output based on the code runtime behavior. This step identifies hidden risks that cannot be detected by static detection through runtime behavior monitoring.

[0046] Step 3.1. Based on the parameter configuration of the component runtime environment in the metadata, inject four core environment elements into the simulation environment: platform global object, platform application programming interface, user permission environment, and business data source. Construct a simulation runtime context that is completely consistent with the parameters of the low-code platform production environment, replicate the permission level, interface configuration, and data format of the actual environment, and ensure that the component's running behavior in the simulation environment is consistent with that in the actual production environment.

[0047] Step 3.2. Build a front-end isolation sandbox adapted for front-end components and a back-end isolation sandbox adapted for back-end components. The front-end isolation sandbox intercepts the component's access requests to global variables and platform objects through proxy objects, limiting the scope of the component's global resource calls. The back-end isolation sandbox loads the component bytecode through a custom class loader and controls the component's access permissions to system resources and local files. The two types of sandboxes run independently, completely isolating the component's runtime environment from the detection host environment, and preventing the component's runtime behavior from interfering with the stability of the detection environment.

[0048] Step 3.3. Analyze the execution logic and calling relationships of the component entry file, identify the lifecycle functions of the entire process of component initialization, running, and destruction, the event callback functions that respond to user operations, and the callable methods that provide services to the outside world. Generate standardized simulated input parameters according to the parameter type, format, and length requirements of various methods, trigger all executable methods in sequence according to the component execution logic, and completely traverse the entire execution path of the component without any path omissions.

[0049] Step 3.4. During the operation of the isolation sandbox, enable real-time behavior collection to capture four types of runtime behavior data: component interface calls, permission usage, network transmission, and data reading and writing. Compare and match the collected behavior data with the static detection results item by item to identify runtime hidden risks and dynamic tampering behaviors that cannot be covered by static detection. Integrate the dynamic risk content, behavior trigger data, and execution path to form a complete dynamic detection result.

[0050] This embodiment uses the front-end and back-end component mapping relationship in the extracted metadata of the custom component package to associate the collection behavior data of the front-end and back-end components, establish the front-end and back-end data transmission link, and use the associated behavior data to construct a full-link data flow graph. The full-link data flow graph is a structured topological data that records the complete flow process of front-end and back-end data, marking the corresponding interface calls and permission usage information for data transmission. The full-link data flow graph and the identified dynamic risk content are jointly incorporated into the dynamic detection results to reflect the risk behaviors generated by cross-terminal linkage. This processing method can break down the detection barriers between front-end and back-end components and realize risk monitoring of the entire data flow process.

[0051] The isolation sandbox dynamic detection module comprises four execution units: a context building unit, a sandbox building unit, a path triggering unit, and a behavior collection unit. The context building unit injects platform global objects, application programming interfaces, user permission environments, and business data sources based on metadata to recreate the production operating environment. The sandbox building unit builds a front-end proxy sandbox and a back-end class loading sandbox to achieve runtime environment isolation. The path triggering unit identifies callable methods of components and generates simulated input parameters, traversing and triggering all execution paths. The behavior collection unit collects runtime behavior data in real time, compares it with static detection results to identify dynamic risks, and the four units execute operations sequentially to form a complete dynamic detection process.

[0052] In some specific implementations, the front-end isolation sandbox adopts a two-layer isolation structure of proxy and iframe nesting. The proxy is responsible for intercepting the component's access requests to the window object and global variables, while the iframe nesting is responsible for dividing an independent rendering environment. The two-layer structure can intercept the component's illegal resource access requests, while controlling the sandbox's memory usage within a set range. The back-end isolation sandbox uses a custom class loader to load the component's bytecode files, restricts the component's access permissions to system classes and local files, and only exposes preset legal interfaces. This construction method can effectively isolate the component's running behavior and prevent malicious components from affecting the stability of the detection environment.

[0053] In some specific implementations, during the full execution path triggering process of a component, simulated input parameters in corresponding formats are generated for three types of methods: lifecycle functions, event callback functions, and externally callable methods. The simulated input parameters include three basic data types: character, numeric, and boolean. The length of the input parameters conforms to the parameter definition requirements of the component methods. The traversal triggering process proceeds sequentially according to the execution logic of component initialization, event response, function execution, and destruction and exit. This can trigger more than a set proportion of the execution path within the component, ensuring the comprehensiveness of the collected runtime behavior data and providing sufficient data support for dynamic risk identification.

[0054] In some specific implementations, when executing the full execution path trigger operation of a custom component, the number of simulated input parameters is set to five types: text, numeric, date, boolean, and object. This is to address the issue of insufficient component execution path coverage caused by a single simulated input parameter type. First, simulated input parameters of the corresponding type are matched according to the parameter definition of the component method. The character length of a single simulated input parameter is set between 10 and 100 characters. Numeric input parameters cover the positive and negative value range, date input parameters match the platform's standard time format, and object input parameters contain 3 to 5 basic attribute fields. Following the execution order of component initialization, event response, business execution, and resource release, lifecycle functions, event callback functions, and externally callable methods are triggered sequentially. The single trigger interval is set to 200 milliseconds to avoid behavior collection errors caused by continuous triggering. This numerical configuration can achieve a component execution path coverage rate of no less than 95%, fully collecting all behavioral data during component runtime and reducing the possibility of missed detections of dynamic risks.

[0055] Step 4. Permission compliance verification and risk report generation: This embodiment uses the extracted metadata of the custom component package, the generated static detection results, and the generated dynamic detection results to perform permission boundary verification and compliance rule verification. Permission boundary verification is a compliance verification process that compares the permission declaration of the custom component package with the actual permission usage behavior. Compliance rule verification is a verification process that matches the running behavior of the custom component package with the preset data security specifications. The risk content is integrated to generate a risk detection report and control instructions. The risk detection report is a structured explanatory document that integrates the risk content of the entire process. The control instructions are a set of instructions used to control the release and running status of the custom component package on the low-code platform. This step completes the final judgment and control output of the risk, forming a detection closed loop.

[0056] Step 4.1. Construct a formal permission model based on the permission declaration list in the metadata. The formal permission model is a first-order logical formal expression model for permission compliance verification. The formal permission model includes three functional modules: permission definition module, logical constraint module, and rule mapping module. It is divided into three levels: basic attribute layer, constraint rule layer, and verification output layer. The modules are connected in sequence according to the hierarchy. The basic attribute layer enters the basic parameters of permission type, operation type, and scope. The logical constraint module enters the first-order logical constraint rules. The rule mapping module binds the permission declaration list and constraint rules to form a complete formal permission model that can be directly used for verification.

[0057] Step 4.2. Extract the set of permissions called during the actual operation of the component from the static and dynamic detection results. Compare the actual set of permissions with the permission declaration list field by field. Perform permission boundary verification through the satisfiability modulus solver to determine whether the permission usage exceeds the declared scope, whether the permission declaration meets the minimum functional requirements, and whether there is a risk of leakage in the permission flow.

[0058] Step 4.3. Call the preset data security compliance rule library to match and verify the component running behavior, data flow behavior, and permission usage behavior item by item. Compare the prohibited behavior types and compliance requirements in the rule library to identify non-compliant behaviors in the component running, and record the triggering scenarios, specific manifestations, and related data of non-compliant behaviors.

[0059] Step 4.4. Integrate and classify the risk content identified by static detection, the risk content identified by dynamic detection, and the non-compliant behavior content identified by compliance verification. Organize the data according to risk type, risk location, and risk impact scope. Generate a standardized risk detection report based on the integrated risk data. At the same time, generate corresponding control instructions based on the risk level determination results to complete the output of the entire detection process.

[0060] This embodiment performs permission boundary verification through a set satisfiability modular theory solver. The satisfiability modular theory solver is a formal verification tool for performing logical judgment and rule verification. The verification content includes determining whether the extracted actual set of usage permissions is included in the permission declaration list, whether the permission declaration list meets the minimum permission requirements of the component function, and whether there is any leakage in permission flow. The solver uses the constructed formal permission model to perform logical judgment and outputs permission overreach identifier, permission redundancy identifier, and permission leakage identifier. The identifier is bound to the behavior data to form the permission verification result, which serves as the basis for generating risk detection reports and control instructions.

[0061] The formal permission verification module comprises three execution units: a model building unit, a solution and computation unit, and a compliance verification unit. The model building unit completes the hierarchical construction and module connection of the formal permission model, and inputs basic parameters and constraint rules. The solution and computation unit calls the satisfiability modular theory solver to perform permission boundary logic judgment and generate permission verification identifiers. The compliance verification unit matches component behavior with preset compliance rules and identifies non-compliant content. The three units work together to complete the dual verification of permissions and compliance.

[0062] Table 3. Correspondence between the hierarchical structure and modules of the formal permission model. Model hierarchy Belonging Module Enter data Execution function Basic attribute layer Permission definition module Permission type, operation type Define basic permission attributes Constraint rule layer Logical constraint module First-order logic constraint rules Configure permission verification logic Verify output layer Rule mapping module Permission declaration list Output permission verification results In some specific implementations, the formal permission model is built according to the correspondence between levels and modules, as shown in Table 3. Each model level corresponds to a dedicated module and input data. The permission verification logic is built through the sequential connection between modules. The satisfaction model theory solver performs judgments based on this model, thereby improving the accuracy of permission boundary verification.

[0063] The risk management output module comprises four execution units: a risk integration unit, a risk classification unit, a report generation unit, and an instruction push unit. The risk integration unit merges static risks, dynamic risks, and non-compliant behaviors. The risk classification unit classifies risks into levels based on their impact scope and the nature of the behavior. The report generation unit organizes risk data to generate structured detection reports. The instruction push unit synchronizes management instructions to the low-code platform management system. These four units complete the final processing and output of risks.

[0064] In some specific implementations, during the permission boundary verification process, the operational parameters of the satisfiability modulus solver are set to a fixed number of iterations. Each iteration completes one permission verification item, sequentially performing permission inclusion relationship determination, minimum permission matching determination, and permission leakage determination. During the operation, the permission data is processed to ensure uniform format to avoid judgment errors caused by differences in data format. The identification information output by the solver is bound one-to-one with the behavior data, which can accurately locate the behavior nodes with abnormal permissions, providing a clear basis for subsequent risk rating and control.

[0065] In some specific implementations, risk levels are divided into three levels based on the scope of risk impact and the nature of the behavior. Level 1 risk corresponds to behaviors that affect the core data and functions of the platform, Level 2 risk corresponds to behaviors that affect local data and functions, and Level 3 risk corresponds to behaviors with minor compliance deviations. Different levels correspond to different control logics. Level 1 risk triggers the component to issue an interception instruction, Level 2 risk triggers the component to issue an operation scope restriction instruction, and Level 3 risk triggers the component to issue a normal release instruction. The level division process is automatically executed according to preset judgment conditions without manual adjustment. Control instructions are simultaneously pushed to the low-code platform control system to achieve real-time security control of components.

[0066] In some specific implementations, during the construction and verification of the formal permission model, the number of constraint rules in the formal permission model is set to 6, and the number of iterations of the satisfyability model solver is 4. This is to address the problems of insufficient judgment accuracy due to too few permission verification rules and reduced verification efficiency due to too many iterations. The 6 constraint rules correspond to permission type matching, operation scope limitation, scope boundary, permission minimization, permission isolation, and permission flow control, respectively. When constructing the formal permission model, the 6 rules are entered into the logical constraint module in sequence, and the rule mapping module binds the 4 basic permission items in the permission declaration list. The solver performs 4 iterations to complete permission inclusion judgment, permission redundancy judgment, permission leakage judgment, and compliance matching judgment, respectively. The result of each iteration is written to the verification log in real time. Finally, the results of the 4 iterations are integrated to generate the permission verification conclusion. This numerical setting can ensure the comprehensiveness of permission verification while controlling the time consumption of a single verification within a reasonable range, adapting to the efficiency requirements of batch component detection on low-code platforms.

[0067] This embodiment constructs a full-process software security testing system for custom components on low-code platforms through four core steps: receiving custom component packages and extracting metadata, static code analysis and taint tracking detection, simulated environment operation and dynamic behavior collection, and permission compliance verification and risk report generation. All steps rely on software processing logic and structured data operations, have no specific hardware dependencies, and can adapt to the component testing needs of different types of low-code platforms. During the testing process, metadata is continuously transferred between each step, static and dynamic detection complement each other, a formal permission model completes accurate compliance verification, and modules work collaboratively according to the process to ensure the accuracy and comprehensiveness of the test results.

[0068] The low-code platform custom component security detection method provided in this embodiment can provide standardized basic data for subsequent detection stages through component package parsing and metadata extraction, reducing detection errors caused by data bias and improving the consistency and stability of the detection process; through static code analysis and taint tracking, it can identify static risks in the component body and dependent packages in a non-running state, reducing the environment configuration requirements of the detection process and expanding the coverage of risk identification; by simulating the runtime context and building an isolation sandbox, it can restore the actual runtime environment of the component and achieve runtime isolation, collect complete runtime behavior data, identify dynamic risks and cross-platform linkage risks that static detection cannot cover, and improve the depth of risk identification; through the combination of a formal permission model and a satisfiability model solver, it can accurately verify permission boundaries and compliance rules, clarify the compliance of component permission usage, and reduce security risks caused by permission anomalies; through risk level classification and control instruction generation, it can achieve differentiated security control of custom components and adapt to the component processing needs of different risk levels. This method can optimize the processing efficiency of custom component detection in low-code platforms, improve the comprehensiveness and accuracy of security detection, reduce the security risks brought by custom components to low-code platforms, provide stable software detection support for the functional expansion and data security of low-code platforms, and adapt to detection scenarios of multiple types of components, thereby improving the overall security management capabilities of low-code platforms.

[0069] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for security detection of custom components on a low-code platform, characterized in that, Includes the following steps: S1. Receive custom component packages. Custom component packages are function extension code packages uploaded by users to the low-code platform. Perform format validation and parsing on the custom component packages, and extract the metadata of the custom component packages. The metadata includes component type, permission declaration list, dependency package list, entry file information and front-end and back-end component mapping relationship. S2. Perform syntax parsing on the code content of the custom component package, use the extracted metadata of the custom component package to build a taint rule base, the taint rule base is a set of rules that mark the sensitive data flow path, perform full path taint tracking processing, identify static risk content, and generate static detection results; S3. Use the extracted metadata of the custom component package to build a low-code platform to simulate the runtime context, build an isolation sandbox, trigger the full execution path of the custom component package in the isolation sandbox, collect runtime behavior data, and combine the generated static detection results to generate dynamic detection results; S4. Using the extracted metadata of the custom component package, the generated static detection results, and the generated dynamic detection results, perform permission boundary verification and compliance rule verification, integrate risk content, and generate risk detection reports and control instructions.

2. The method according to claim 1, characterized in that, The parsing process in step S1 includes the following sub-steps: S1.

1. Identify the component types of the custom component package. Component types include front-end components, back-end service components, and front-end and back-end matching binding components. Front-end components include general module specification component packages, page framework building component packages, and low-code platform adaptation component packages. Back-end service components include bytecode format component packages, interpreted language packaging component packages, and web page assembly format component packages. S1.

2. Decompress and verify the integrity of the custom component packages that have completed type identification, check the file structure and format, and remove custom component packages with incorrect format and corrupted data; S1.

3. Retrieve the historical version storage data of the custom component package that has completed format verification, compare it file by file with the current component package, mark the changed areas of code and configuration, and generate an incremental detection list based on the changed areas. The incremental detection list is a list file that marks the version change content and limits the detection scope. The incremental detection list limits the processing scope of subsequent detections.

3. The method according to claim 1, characterized in that, The full-path taint tracing process in step S2 includes the following sub-steps: S2.

1. Perform syntax parsing on the code content of the custom component package, generate an abstract syntax tree for script code, generate a bytecode instruction set for the compiled code, and construct a code control flow graph using the abstract syntax tree or bytecode instruction set. The code control flow graph is a directed graph data that reflects the code execution order and branch jump relationship. S2.

2. Use the extracted metadata of the custom component package to define taint sources and taint aggregation points, and build a taint rule base. The taint sources include the low-code platform global context object, user information fields, platform application programming interfaces and cross-component communication receiving ports. The taint aggregation points include network request interfaces, data storage interfaces, cross-component communication sending ports and dynamic code execution interfaces. S2.

3. Use the constructed code control flow graph to traverse all execution branches, trace the flow path of tainted data from taint source to taint convergence point, record function call and data transfer relationship, identify static risk content, and integrate risk content and path information to form static detection results.

4. The method according to claim 1, characterized in that, Step S3, which involves triggering the entire execution path and collecting runtime behavior data, includes the following sub-steps: S3.

1. Inject the extracted metadata of the custom component package into the low-code platform simulation runtime context. The low-code platform simulation runtime context is a set of variables, interfaces and permissions that restore the platform's production environment, including platform global objects, platform application programming interfaces, user permission environment and business data sources, which are consistent with the actual platform runtime environment. S3.

2. Build a front-end isolation sandbox and a back-end isolation sandbox. The front-end isolation sandbox intercepts global object access behavior through a proxy mechanism, and the back-end isolation sandbox intercepts resource call behavior through a class loading mechanism, so as to achieve mutual isolation between the component runtime environment and the detection environment that injects the simulated runtime context. S3.

3. Parse the entry file information of the custom component package, identify lifecycle functions, event callback functions and externally callable methods, generate simulated input parameters according to the parameter format, and traverse and trigger all execution paths of the components in the isolation sandbox according to the execution logic; S3.

4. Collect behavioral data during the operation of the isolation sandbox. The behavioral data includes interface calls, permission usage, network transmission, and data read / write behavior. Compare the generated static detection results to identify dynamic risk content and form dynamic detection results.

5. The method according to claim 1, characterized in that, Step S4, permission boundary verification and compliance rule verification, includes the following sub-steps: S4.

1. Construct a formal permission model using the permission declaration list extracted from the metadata of the custom component package. The formal permission model is a first-order logical formal expression model for permission compliance verification, including three modules: permission definition module, logical constraint module, and rule mapping module. It is divided into three levels: basic attribute layer, constraint rule layer, and verification output layer. The basic attribute layer connects to the permission definition module, the permission definition module connects to the logical constraint module, the logical constraint module connects to the rule mapping module, and the rule mapping module connects to the verification output layer. During construction, basic parameters are entered in the basic attribute layer, first-order logical constraint rules are entered in the logical constraint module, and the permission declaration list and constraint rules are bound in the rule mapping module. S4.

2. Extract the actual set of component usage permissions from the generated static detection results and the generated dynamic detection results, compare it with the permission declaration list, and perform permission boundary verification; S4.

3. Call preset compliance rules to verify component operation behavior and data flow behavior, and identify non-compliant behavior content; S4.

4. Integrate the identified static risk content, identified dynamic risk content, and identified non-compliant behavior content to generate risk detection reports and control instructions.

6. The method according to claim 3, characterized in that, In step S2, the dependency package list in the extracted metadata of the custom component package is read. Recursive parsing is performed on each dependency package in the list. Using the same syntax parsing and control flow construction method as the custom component package, full-path taint tracing is performed on the dependency package code to track the location and transmission path of taint data, identify the risky content of the dependency package, and merge the identified risky content of the dependency package with the identified risky content of the component itself. The merged static detection result reflects the risks introduced by the component body and the dependency package, providing risk basis data for subsequent dynamic detection and permission verification.

7. The method according to claim 4, characterized in that, In step S3, the front-end and back-end component mapping relationship in the extracted metadata of the custom component package is used to associate the collection behavior data of the front-end and back-end components, establish the front-end and back-end data transmission link, and use the associated behavior data to construct a full-link data flow graph. The full-link data flow graph is a structured topology data that records the complete flow process of front-end and back-end data, and marks the corresponding interface calls and permission usage information for data transmission. The full-link data flow graph and the identified dynamic risk content are jointly incorporated into the dynamic detection results to reflect the risk behaviors generated by cross-terminal linkage.

8. The method according to claim 5, characterized in that, In step S4, permission boundary verification is performed using the set satisfiability model theory solver. The verification includes determining whether the extracted actual set of usage permissions is included in the permission declaration list, whether the permission declaration list meets the minimum permission requirements of the component function, and whether there is any leakage in permission flow. The solver uses the constructed formal permission model to perform logical judgment and outputs permission overreach identifier, permission redundancy identifier, and permission leakage identifier. The identifiers are bound to the behavior data to form the permission verification result, which serves as the basis for generating risk detection reports and control instructions.

9. The method according to claim 5, characterized in that, In step S4, the severity level is divided according to the scope of impact and nature of behavior of the integrated risk content. The level is divided according to preset judgment conditions, and different levels correspond to different handling logics. Based on the level division results, corresponding control instructions are generated. The control instructions are divided into component release interception instructions, component operation scope restriction instructions, and component normal release instructions. The control instructions are written into the risk detection report and synchronized to the low-code platform control system.

10. A security detection system for custom components on a low-code platform, used to perform the method as described in any one of claims 1-9, characterized in that, It includes a component preprocessing and parsing module, a static taint tracking and detection module, an isolation sandbox dynamic detection module, a permission formal verification module, and a risk management output module; The component preprocessing and parsing module performs component package format verification, decompression and comparison, and metadata extraction. The static taint tracking and detection module uses the extracted metadata to perform code parsing, control flow graph construction, taint tracking, and dependency package risk detection. The isolation sandbox dynamic detection module uses the extracted metadata and static detection results to perform simulated context construction, sandbox setup, path triggering, and behavior collection. The permission formal verification module uses the detection results to perform permission formal model construction, permission boundary and compliance rule verification. The risk management output module uses the verification results to perform risk level classification, report generation, and management instruction output.

Images