A training data generation method and system based on static application security testing

Abstract

The application relates to the technical field of static application security detection, and discloses a training data generation method and system based on static application security detection, which obtains key condition variables and usage positions by analyzing the source code of a target application program, introduces condition logic on the basis, creates an unsafe execution path triggered under specific runtime conditions, generates runtime environment simulation information according to the condition logic, verifies the source code sample after the introduction of the condition logic, confirms whether defects exist in combination with the environment simulation information, and finally generates a defect label. The method effectively solves the problem that existing SAST tools are difficult to effectively capture hidden security defects triggered under specific runtime conditions when facing modern complex software systems, especially microservice or distributed architecture applications.

Description

Technical Field

[0001] This invention relates to the field of static application security detection technology, and in particular to a method and system for generating training data based on static application security detection. Background Technology

[0002] In software development, Static Application Security Testing (SAST) tools are widely used to discover potential security vulnerabilities before code deployment. These tools identify security risks by analyzing source code and generate reports. At the core of a SAST tool is typically a heavily trained model that requires massive amounts of accurately labeled learning material to distinguish between secure code structures and potential security flaw patterns.

[0003] However, existing training data generation methods fall short when faced with modern, complex software systems, especially those employing microservices or distributed architectures. For example, an input string might first undergo preliminary processing by a front-end service, then be passed to a middleware component. This component applies further transformations or filtering based on dynamic runtime configuration flags or the specific roles and permissions of an authenticated user, ultimately reaching the back-end service for use in sensitive operations. A critical vulnerability might only manifest under very specific combinations of conditions, such as only when a particular system configuration flag is enabled, or only when a request is made by a user with a specific administrative role. This precise combination of factors could trigger an alternative execution path in the middleware or back-end, where the initial sanitization by the front-end proves insufficient, and subsequent transformations inadvertently construct an exploitable malicious payload.

[0004] Static analysis tools, by their very nature unable to access the dynamic runtime context, struggle to accurately infer these conditional data flows, the precise state of data at each step under different configurations, and the exact impact of runtime-dependent logic. Existing training data generation methods, even with advancements in simulating flawed processing, cannot systematically generate samples of this "conditional taint propagation." The exploitability of these vulnerabilities depends entirely on specific combinations of data values, system configurations, and execution paths—combinations not immediately apparent from the static code structure itself. This fundamental limitation in generating highly context-dependent, runtime-dependent vulnerability samples constitutes a significant and persistent gap in training data, severely hindering the SAST model's ability to learn and identify these deeply hidden yet pervasive flaws in modern complex systems.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] This invention provides a training data generation method and system based on static application security testing, aiming to solve the problem that existing static application security testing (SAST) tools are unable to effectively capture hidden security defects triggered under specific runtime conditions when facing modern complex software systems, especially microservice or distributed architecture applications, resulting in a lack of highly context-dependent and runtime-dependent vulnerability samples in the training data.

[0007] In a first aspect, to address the aforementioned technical problems, this invention provides a method for generating training data based on static application security detection, comprising:

[0008] Analyze the source code of the target application to obtain key condition variables and their usage locations;

[0009] Based on the key condition variables and the usage location, conditional logic is introduced into the source code to create unsafe execution paths that are triggered under specific runtime conditions;

[0010] Based on the aforementioned conditional logic, runtime environment simulation information is generated;

[0011] The source code sample after introducing the conditional logic is verified, and the presence of defects is confirmed based on the environmental simulation information.

[0012] If so, a defect label is generated.

[0013] Preferably, the step of introducing conditional logic into the source code based on the key condition variable and the usage location to create an unsafe execution path triggered under specific runtime conditions includes:

[0014] Static analysis is performed on the source code to identify the security processing logic called through the service interface, and the method signature, parameter type and return value of the security processing logic are analyzed.

[0015] Read the location of the external configuration, establish the mapping relationship between the external configuration and the dynamic component, and obtain the dynamic security service interface and external configuration dependencies;

[0016] A behavior proxy class is generated based on the dynamic security service interface and the external configuration dependency. The behavior proxy class implements the dynamic security service interface. The internal logic of the behavior proxy class is to simulate defective behavior under specific conditions. The behavior proxy class contains a flag to control the defective behavior, which is used to activate or deactivate the defective behavior to obtain the defective behavior proxy. The specific conditions include skipping security checks, returning error data, or performing unauthorized operations.

[0017] Preferably, the method further includes:

[0018] In the source code after injecting the behavior agent replacement logic, add a structured comment block. The structured comment block lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, thus obtaining a static analysis context description.

[0019] Preferably, obtaining the static analysis context description includes:

[0020] Identify and analyze the remote configuration services or inter-component communication protocols that the original components depend on in the distributed environment;

[0021] Generate a context mapping table for distributed conditions, wherein the context mapping table associates the internal defect activation state with a specific configuration item in the remote configuration service or a specific data field in the inter-component communication protocol;

[0022] The structured annotation block contains a reference to the context mapping table;

[0023] The reference is parsed to obtain the complete conditional context across components.

[0024] Preferably, in the source code after the injected behavior agent replacement logic, a structured comment block is added. This structured comment block explicitly lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, including:

[0025] In the source code after the injection behavior proxy replacement logic, add a structured comment block. The structured comment block contains metadata identifiers, version information, and references to external metadata storage. The structured comment block includes cross-file or cross-module association identifiers. The association identifiers are used to logically associate the context information of the current injection point with the context information of other related components in the distributed system.

[0026] The system stores the original component, the activated defect type, the simulated external configuration conditions, and the internal defect activation status of the behavior agent.

[0027] In the source code following the injection behavior proxy replacement logic, a structured comment block is added. This structured comment block includes a metadata identifier, version information, and a reference to an external metadata store. It also includes:

[0028] Generate a timestamp for the reference;

[0029] In the external metadata store, a version history is maintained for each metadata entry, and the version history is updated with the timestamp of each change to the metadata entry;

[0030] When resolving the reference, the timestamp in the reference is compared with the latest timestamp of the corresponding metadata in the external metadata storage;

[0031] Based on the comparison results, if the timestamp in the reference is inconsistent with the latest timestamp of the corresponding metadata in the external metadata storage, a metadata version mismatch warning is triggered, and metadata corresponding to the timestamp in the reference is retrieved from the version history according to the preset version compatibility strategy.

[0032] Preferably, maintaining a version history for each metadata entry in the external metadata storage, wherein the version history updates the timestamp of each change to the metadata entry, includes:

[0033] The external metadata storage adopts a content-addressable distributed version control system;

[0034] Each time the metadata entry is modified, a new content hash value is generated as a version identifier;

[0035] The version history of the metadata entries is stored in a chain structure using a distributed hash table index. Each version node in the chain structure contains a timestamp, a content hash value, and a pointer to the previous version.

[0036] Preferably, when parsing the reference, comparing the timestamp in the reference with the latest timestamp of the corresponding metadata in the external metadata storage includes:

[0037] When resolving the reference, the timestamp is extracted from the reference;

[0038] Send a query request to obtain the latest timestamp of the corresponding metadata in the external metadata storage;

[0039] Perform integrity verification and validation on the latest timestamp obtained;

[0040] The obtained timestamp is compared with the latest timestamp after integrity verification to determine whether the two are consistent.

[0041] Preferably, the integrity verification of the latest timestamp includes:

[0042] Identify the sharding method and storage location of the metadata corresponding to the latest timestamp in the heterogeneous storage system;

[0043] Based on the sharding method and the storage location, obtain the corresponding metadata fragments from each heterogeneous storage system;

[0044] For each acquired metadata fragment, the fragment verification value is calculated independently according to the verification mechanism of the corresponding storage system;

[0045] Merge all metadata fragments into complete metadata and calculate the overall checksum of the complete metadata;

[0046] The overall verification value is compared with the preset complete metadata verification value to determine the overall integrity of the complete metadata.

[0047] Secondly, the present invention provides a training data generation system based on static application security detection, comprising:

[0048] The detection end is used to analyze the source code of the target application to obtain key condition variables and their usage locations; based on the key condition variables and their usage locations, conditional logic is introduced into the source code to create an unsafe execution path triggered under specific runtime conditions;

[0049] The processing end is used to generate runtime environment simulation information based on the conditional logic; to verify the source code sample after the conditional logic is introduced, and to output the environment simulation information to confirm whether a defect exists; if so, a defect label is generated.

[0050] This application discloses a method and system for generating training data based on static application security detection. By analyzing the source code of the target application, key condition variables and their usage locations are obtained. Based on this, conditional logic is introduced to create insecure execution paths triggered under specific runtime conditions. Subsequently, runtime environment simulation information is generated according to this conditional logic, and the source code sample with the introduced conditional logic is verified. The presence of defects is confirmed by combining the environment simulation information, and finally, defect labels are generated. This method effectively solves the problem that existing SAST tools struggle to effectively capture hidden security defects triggered under specific runtime conditions in modern complex software systems, especially microservice or distributed architecture applications. By systematically generating security defect samples with specific runtime condition triggering mechanisms, this application overcomes the shortcomings of existing training data in handling complex, context-dependent vulnerabilities, thereby significantly improving the ability of the SAST model to identify deeply hidden but prevalent defects in modern complex systems, providing high-quality, high-coverage training data for SAST tool training. Attached Figure Description

[0051] Figure 1 This is a flowchart of a training data generation method based on static application security detection provided by an embodiment of the present invention;

[0052] Figure 2This is a flowchart of another training data generation method based on static application security detection provided by an embodiment of the present invention;

[0053] Figure 3 This is a schematic diagram of a training data generation system based on static application security detection provided in an embodiment of the present invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0055] Reference Figure 1 The present invention provides a flowchart of a training data generation method based on static application security detection, comprising the following steps:

[0056] S1, Analyze the source code of the target application to obtain key condition variables and their usage locations;

[0057] S2, Based on the key condition variables and the usage location, introduce conditional logic into the source code to create an unsafe execution path triggered under specific runtime conditions;

[0058] S3, Generate runtime environment simulation information based on the conditional logic;

[0059] S4. Verify the source code sample after introducing the conditional logic, and confirm whether there is a defect based on the environment simulation information.

[0060] S5, if so, then generate a defect label.

[0061] This application introduces conditional logic to create insecure execution paths and verifies them using runtime environment simulation information, thereby systematically generating highly context-dependent, runtime-dependent vulnerability samples. Thus, this application effectively solves the problem of existing training data generation methods struggling to capture hidden security flaws in complex software systems, significantly improving the ability of static application security detection models to identify deeply hidden defects in modern complex systems.

[0062] The method proposed in this application involves several key terms and concepts. Among them, "Static Application Security Detection (SAST)" refers to the process of discovering potential security vulnerabilities in an application by analyzing source code, bytecode, or binary files without running the code. "Target application source code" refers to the original code of the software program used to generate training data. "Key condition variables" refer to variables whose values ​​or state changes during program execution can affect program control flow or data flow and may trigger security flaws. "Usage location" refers to the specific line or block of code in the source code where key condition variables are read, written, or participate in logical judgments. "Conditional logic" refers to code structures artificially added to the source code to simulate specific runtime conditions, with the purpose of guiding the program into a preset unsafe execution path when specific conditions are met. "Unsafe execution path" refers to the code sequence that will trigger security vulnerabilities during program execution under specific conditions. "Runtime environment simulation information" refers to the external environment parameters, configurations, input data, etc., that simulate the program during actual runtime, in order to reproduce the defect triggering conditions during the verification phase. "Defect labels" refer to information that classifies, describes, and marks confirmed security defects, and is used to train the SAST model.

[0063] The training data generation method based on static application security detection proposed in this application is based on the systematic creation and verification of security defect samples with specific runtime dependencies through refined source code analysis and the introduction of purposeful conditional logic.

[0064] First, the target application's source code needs to be analyzed to identify key condition variables and their usage locations. This step aims to identify variables that have a potential impact on program behavior, especially security-related behavior. For example, Abstract Syntax Tree (AST) traversal techniques can be used to perform structured analysis of the source code, identifying all variable declarations and their scopes. Simultaneously, data flow analysis is used to trace the assignment, passing, and usage of these variables within the program, paying particular attention to variables involved in conditional statements (such as `if` and `switch` statements), loop control, or passed as function parameters. For instance, in a user authentication module, a boolean variable named `isAuthenticated` or a string variable representing a user role named `userRole`, and their usage locations within the permission check logic, could be identified as key condition variables and their usage locations. Another approach is to leverage symbolic execution techniques to explore the source code paths and identify variables that may influence security decisions at different execution paths. By constructing the program's Control Flow Graph (CFG) and Data Flow Graph (DFG), the definitions and usage chains of key variables can be precisely located, thus determining their "usage locations."

[0065] Secondly, based on the acquired key condition variables and their usage locations, conditional logic is introduced into the source code to create an insecure execution path triggered under specific runtime conditions. This step is crucial for generating defect samples. For example, a new `if` statement can be inserted into an otherwise secure input validation function, targeting a key condition variable (such as the `isAdmin` flag). When `isAdmin` is `true`, the logic inside this `if` statement bypasses the normal input cleansing process, directly passing unprocessed user input to a sensitive database query operation, thus creating an insecure execution path for SQL injection. Another implementation approach is to modify the reading logic of an external configuration item (such as `featureToggle`) in the source code. For example, the code that directly reads the configuration value can be replaced with a proxy function. Under specific conditions (e.g., when `featureToggle` is set to `debug` mode), this proxy function returns a preset value that may lead to a defect, instead of the actual configuration value. Thus, when the program relies on this configuration item for security decisions, an insecure execution path is triggered. Next, based on the introduced conditional logic, runtime environment simulation information is generated. This step aims to provide the necessary runtime context for subsequent verification. For example, if the conditional logic depends on a specific system environment variable (such as `ENV_MODE=production`), the environment simulation information will contain instructions for setting that environment variable. If the conditional logic depends on a specific database connection state or external service response, the environment simulation information will include configurations simulating a successful database connection or a specific error code returned by an external service. Specifically, a configuration file (such as `application.properties` or `config.json`) can be generated, containing specific configuration items and their values ​​required to activate the unsafe execution path. For example, if the defect path is triggered when `debugMode=true`, the configuration file will contain an entry for `debugMode=true`. Furthermore, specific network request or response data can be generated to simulate, for example, constructing an HTTP request with specific request headers or bodies to simulate the external input required to trigger the defect. Generating configuration files is a static, declarative environment setting that triggers a defect by changing the application's startup state. Generating network requests / responses is a dynamic, interactive environment simulation that triggers a defect by generating specific network events. These two methods together constitute a powerful and automated "environment simulation information" generation capability, which can cover a variety of defect triggering scenarios from configuration-driven to inter-service interaction, making the entire defect discovery system more comprehensive and effective.

[0066] In addition, the specific technical means for generating runtime environment simulation information may include the following methods:

[0067] Technical description: Instead of assigning specific values to program variables, they are represented as "symbols" (for example, a variable x is represented as symbol X). During program execution, all conditional branches based on these symbols (such as if(x>100)) will be recorded and converted into corresponding path constraint conditions (such as X>100).

[0068] Application: The system will identify the key conditional variables upon which the introduced "conditional logic" depends. Then, use a symbolic execution engine to execute along the program path. When encountering this conditional logic, collect its triggering conditions (for example, the condition for triggering an unsafe path is critical Var==true&&buffer Size<threshold). Finally, use a constraint solver (such as Z3, CVC5) to solve this condition and obtain a set of specific variable assignments that can cause the program execution flow to enter the "unsafe execution path" (for example, critical Var=true, threshold=1024, buffer Size=500).

[0069] Output: This set of specific assignments obtained through solving is the most core "environment simulation information".

[0070] Subsequently, verify the source code sample after introducing the conditional logic, and confirm whether there are defects based on the environment simulation information. This step is crucial for ensuring the validity of the generated sample. For example, a dynamic application security testing (DAST) tool or a custom test script can be used to run the modified source code sample in a simulated environment. During the running process, load the previously generated environment simulation information to ensure that the program is executed under preset conditions. By monitoring the behavior of the program, such as observing log outputs, system calls, memory accesses, or network communications, to determine whether the unsafe execution path is successfully triggered and whether the expected security defects appear. For example, if SQL injection is expected, the verification process will check whether there are abnormal SQL query statements in the database log. Another implementation method is to adopt fuzz testing (Fuzzing) technology, combined with environment simulation information, to provide a large number of mutated inputs to the modified source code sample. By observing the crashes, abnormal behaviors, or unexpected outputs of the program under these inputs, to confirm the existence of defects. Among them, the "custom test script" is a highly automated test coordination and diagnosis engine. It makes an objective and automated judgment on "whether there are defects" by running the program in a strongly monitored environment and comprehensively analyzing multi-level data from compiler tools, operating system signals, application logs, and system calls.

[0071] Finally, if so, defect labels are generated. This step involves labeling confirmed defects for use in training the SAST model. For example, if an SQL injection defect is confirmed, a defect label is generated containing information such as the defect type (e.g., "SQL injection"), defect location (source code file and line number), triggering conditions (key parameters in the environment simulation information), and the severity of the defect. These labels can be stored in structured JSON, XML, or CSV formats and associated with corresponding source code samples.

[0072] Compared to existing technologies, the advantage of this application lies in its ability to systematically generate highly context-dependent, runtime-dependent vulnerability samples. Traditional methods often struggle to capture hidden security flaws that only manifest under dynamic conditions such as specific configurations, user permissions, or external service responses. This application, by introducing conditional logic into the source code and combining it with precise runtime environment simulation, enables the effective simulation and verification of these "conditional taint propagation" vulnerabilities. For example, in a microservice architecture, an input string may be passed between multiple services and processed in a certain service based on specific configuration flags or user roles. This application can simulate these cross-service conditional data flows and trigger insecure execution paths under specific conditions, thereby generating training data that more closely resembles the vulnerability patterns of real-world complex systems. This capability significantly enhances the ability of static application security detection models to learn and identify deeply hidden defects in modern complex systems, filling the gap in existing training data generation methods for handling security defects in complex, dynamic, and distributed systems. Specifically, refer to... Figure 2 S2 can be further implemented in the following ways.

[0073] S21, Perform static analysis on the source code to identify the security processing logic called through the service interface, and analyze the method signature, parameter type and return value of the security processing logic;

[0074] S22, Read the location of the external configuration, establish the mapping relationship between the external configuration and the dynamic component, and obtain the dynamic security service interface and the external configuration dependency;

[0075] S23. Generate a behavior proxy class based on the dynamic security service interface and the external configuration dependency. The behavior proxy class implements the dynamic security service interface. The internal logic of the behavior proxy class is to simulate defective behavior under specific conditions. The behavior proxy class contains a flag to control defective behavior, which is used to activate or deactivate defective behavior, thus obtaining a defective behavior proxy.

[0076] Static source code analysis refers to identifying potential security processing logic within an application by analyzing its structure, syntax, and semantics without executing the program. Specifically, techniques such as Abstract Syntax Tree (AST) analysis, Control Flow Graph (CFG), and Data Flow Graph (DFG) construction can be used to locate security-related functions or methods called through service interfaces (e.g., API interfaces, RPC interfaces, etc.). Analyzing the method signatures, parameter types, and return values ​​of these security processing logics aims to understand their expected inputs, outputs, and the types of security checks that may be performed, such as input validation, permission checks, and encryption operations. Furthermore, identifying the location of external configurations involves recognizing files, databases, or remote configuration services used to store configuration information within the application. These external configurations typically control the application's behavior, including security-related behaviors. Establishing a mapping between external configurations and dynamic components aims to understand which configuration items affect the behavior of which dynamic components (e.g., plugins, modules, services), particularly those related to security processing logic. This yields dynamic security service interfaces and external configuration dependencies, which helps determine the configuration conditions that need to be modified or simulated when simulating flawed behavior. Dynamic components refer to components that are loaded, created, replaced, or removed at runtime, not compile time. Based on this, a behavior proxy class is generated according to the dynamic security service interface and external configuration dependencies. This behavior proxy class is designed to implement the dynamic security service interface, and its internal logic is configured to simulate defective behaviors under specific conditions, such as skipping security checks, returning error data, or performing unauthorized operations. The behavior proxy class also includes a flag that controls the defective behavior, which can be activated or deactivated at runtime, thus flexibly controlling the triggering of defective behaviors. In this way, a defective behavior proxy can be obtained, which can simulate various security defect scenarios without modifying the original security processing logic. By simulating successful illegal states and dependency interface contracts, the behavior proxy can ensure that the program flow does not crash. However, its successful implementation strongly depends on the program's loosely coupled architecture (IoC / DI). The defect implementation logic of specific methods is highly patternizable and can be generated in batches based on templates. Uncertainty mainly lies in target selection and the construction of complex context data. By establishing a rich "defect pattern library" and combining it with static analysis to intelligently select target interfaces, the reliance on manual creative labor can be greatly reduced, making this solution a powerful and scalable automated security testing tool.

[0077] This application's solution, through static analysis of the source code, can accurately identify the key security processing logic and its calling interfaces in the application, providing clear targets for subsequent defect injection. By analyzing the dependencies between external configurations and dynamic components, this application can understand which runtime conditions affect the execution of security logic, thus providing a basis for the conditional triggering mechanism of defect behavior proxies. It is precisely because a behavior proxy class is generated and implements the dynamic security service interface that defective behavior can be simulated in a controlled manner without directly modifying the original code. The conditional logic and flags controlling defective behavior within the behavior proxy class ensure that defective behavior is activated only in specific runtime environments, thereby creating an unsafe execution path triggered under specific conditions, effectively achieving the goal of introducing conditional logic into the source code.

[0078] Through the above technical solutions, this application enables fine-grained control and simulation of insecure execution paths. Static analysis identifies security processing logic, ensuring the targeting and accuracy of defect injection and avoiding blind injection. Establishing a mapping relationship between external configurations and dynamic components allows for more realistic simulation of security flaws caused by configuration errors or changes in environmental conditions. Furthermore, the introduction of behavior proxy classes makes the injection and control of defective behaviors more flexible and reversible, reducing invasiveness to the original code. By controlling the flags of defective behaviors, the application can precisely activate or deactivate these behaviors during training data generation, thereby generating high-quality, high-coverage defect training data and significantly improving the training effect and detection capability of the static application security detection model.

[0079] In some embodiments described above, this application proposes creating unsafe execution paths by introducing behavior proxy classes. However, in its implementation, simply injecting behavior proxies may make it difficult for subsequent static analysis tools to fully understand the contextual information of the simulated defect, such as the defect type, activation conditions, and the original component it replaces, thereby affecting the accuracy and efficiency of training data generation. To address this, this application further proposes a method of adding structured comment blocks to the source code after injecting behavior proxy replacement logic to obtain a static analysis context description.

[0080] Furthermore, the implementation techniques for "simulated defects" are specified. The system determines which defects to inject into the Auth Service interface based on a rule base (such as "simulated authentication bypass"). Dynamically: A Vulnerable Auth Proxy class is generated, and conditional bypass logic is injected. Statically: Structured comment blocks containing complete metadata are automatically inserted around the proxy class file and key methods. When the static analysis tool scans the code, it parses these comment blocks. It can now clearly know that Vulnerable Auth Proxy is a replacement for Default Auth Service, and that under certain conditions, the `return true;` statement within the `if(bypassAuth)` branch is a high-severity authentication bypass vulnerability. The dynamic testing tool sets up the environment based on the activation conditions mentioned in the comments (such as `vulnerability.auth.bypass=true`) and runs tests to confirm that the defect can be triggered. The results of static and dynamic analysis (code snippets, comment metadata, and trigger results) are packaged together to generate high-quality, context-rich training data for training a more intelligent vulnerability discovery model. By combining dynamic proxy simulation of defect behavior with static annotation to provide analysis context, this solution not only achieves the realism of runtime testing but also overcomes the shortcomings of purely dynamic methods in being unfriendly to static analysis, thus forming a complete, accurate, and efficient security defect data generation system.

[0081] In the source code after injecting the behavior agent replacement logic, add a structured comment block. The structured comment block lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, thus obtaining a static analysis context description.

[0082] Specifically, the structured comment block can be understood as a comment area with a specific format embedded in the source code, designed to provide metadata information about the injected behavioral agent. The original component simulated by the behavioral agent refers to the original functional modules or services in the application replaced or simulated by the behavioral agent. The activated defect type refers to the specific type of security defect simulated by the behavioral agent, such as SQL injection or cross-site scripting attacks. The simulated external configuration conditions refer to the external environment or configuration parameters required to trigger the defective behavior in the behavioral agent at runtime, such as specific database connection strings or environment variable settings. The internal defect activation state of the behavioral agent refers to the current state of the flags or variables used within the behavioral agent to control whether the defective behavior is activated. By embedding this information into the source code in a structured manner, a clear and parsable static analysis context can be formed, providing rich semantic information for subsequent static analysis tools.

[0083] The solution proposed in this application adds structured comment blocks to the source code after injecting the behavior agent to replace the logic, enabling static analysis tools to directly obtain comprehensive contextual information about the injected defects from the source code. Specifically, the structured comment blocks explicitly list the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation state of the behavior agent. Because of this structured information, when analyzing the modified source code, the static analysis tool no longer only faces the implementation of a behavior agent, but can understand the original function represented by the agent, the types of defects it simulates, and the specific conditions required to trigger the defect. Therefore, the static analysis tool can more accurately identify and understand unsafe execution paths and provide more precise defect labels and contextual information for training data generation.

[0084] Through the above technical solutions, this application significantly improves the quality and efficiency of static application security detection training data generation. Specifically, by introducing structured annotation blocks, static analysis tools can obtain rich semantic context about injected defects, thereby avoiding misjudgments or omissions due to missing information. This not only improves the accuracy of defect identification but also enables the generated training data to more comprehensively reflect real-world security defect scenarios, thereby improving the performance and generalization ability of the security detection model trained based on this data. In addition, the introduction of structured annotation blocks also enhances the readability and maintainability of the source code, making it easier for developers and security analysts to understand and manage injected defect samples.

[0085] In some embodiments described above in this application, static analysis context descriptions can be obtained by adding structured comment blocks to the source code after injecting behavioral proxy replacement logic. However, in complex distributed environments, original components may rely on remote configuration services or inter-component communication protocols, making it difficult for a single structured comment block to comprehensively capture the complete conditional context across components, thus affecting the accuracy and depth of static analysis. Therefore, this application further proposes an optimization of the method for obtaining the aforementioned static analysis context descriptions to more comprehensively capture conditional context information in a distributed environment.

[0086] Specifically, the static analysis context described above includes the following steps:

[0087] Identify and analyze the remote configuration services or inter-component communication protocols that the original components depend on in the distributed environment;

[0088] Generate a context mapping table for distributed conditions, wherein the context mapping table associates the internal defect activation state with a specific configuration item in the remote configuration service or a specific data field in the inter-component communication protocol;

[0089] The structured annotation block contains a reference to the context mapping table;

[0090] The reference is parsed to obtain the complete conditional context across components.

[0091] Identifying and analyzing the remote configuration services or inter-component communication protocols that the original component depends on in the distributed environment involves static analysis of the original component's source code, configuration files, deployment descriptors, and possible network topology information to determine which external services or components the component might interact with at runtime, and the protocols (e.g., HTTP / REST, gRPC, message queues, etc.) and data formats used in these interactions. The aim is to comprehensively understand the original component's external dependencies and communication patterns in the distributed system, providing a foundation for subsequent contextual analysis.

[0092] A context mapping table for distributed conditions is generated, which associates the internal defect activation state with specific configuration items in the remote configuration service or specific data fields in the inter-component communication protocol. Specifically, the context mapping table is a logical structure used to establish the correspondence between the internal defect activation state of the behavior agent and external distributed environmental conditions. For example, if the internal defect activation state of the behavior agent depends on a specific key-value pair in a remote configuration service (such as `feature.flag.vulnerability_enabled=true`), or on a specific data field transmitted through an inter-component communication protocol (such as `security_bypass_header=true` in a request message), then the mapping table will explicitly record these associations. The purpose is to decouple and associate the internal defect triggering logic of the behavior agent with externally controllable distributed environmental factors, enabling static analysis tools to understand how external conditions affect the activation of internal defects.

[0093] The structured comment block contains a reference to the context mapping table. As a preferred implementation, to maintain source code cleanliness and allow for independent management and updates of the context mapping table, the structured comment block does not directly embed the complete mapping table content; instead, it contains a reference to the mapping table. This reference can be a unique identifier, a file path, a URL, or a database query string. The aim is to provide a flexible and scalable way to manage and access complex distributed conditional context information, while avoiding redundant storage of large amounts of data in the source code.

[0094] The references are parsed to obtain the complete conditional context across components. When the static analysis tool processes the source code after injecting behavioral proxy replacement logic, it identifies and parses references in structured comment blocks. By parsing these references, the tool can retrieve the complete context mapping table of distributed conditions from external storage or services. Therefore, the static analysis tool can not only understand the local behavior of the behavioral proxy but also combine external distributed environment conditions to construct a more comprehensive set of defect triggering paths and conditions. The goal is to ensure that static analysis fully considers all relevant factors in the distributed system, thereby improving the accuracy and coverage of defect detection.

[0095] This application's solution overcomes the limitations of traditional static analysis in distributed systems by effectively associating the local static analysis context with dynamic conditions in the distributed environment. Specifically, by identifying the remote dependencies of original components and analyzing their interaction patterns, the system can construct a context mapping table reflecting the impact of external configuration and service communication on the activation of internal defects. Subsequently, references to this mapping table are embedded in structured comment blocks, enabling static analysis tools to dynamically obtain and integrate the complete conditional context in the distributed environment by parsing these references when processing source code. Due to this mechanism, static analysis is no longer limited to the local code logic of a single component but can take into account distributed conditions such as external configuration items and specific data fields in inter-component communication protocols, thereby more accurately simulating and verifying unsafe execution paths triggered under specific runtime conditions.

[0096] Through the above technical solution, this application can significantly improve the effectiveness of training data generation methods based on static application security detection in distributed systems. Specifically, by identifying and analyzing the remote dependencies of the original components and generating a context mapping table of distributed conditions, this application can more comprehensively capture the activation conditions of defects in the distributed environment, overcoming the difficulty of traditional static analysis in handling cross-service and cross-configuration dependencies. Therefore, the generated training data can more realistically reflect potential security defects in distributed applications, improving the generalization ability and detection accuracy of the training model. Furthermore, by including references to the context mapping table in structured comment blocks, not only is the cleanliness of the source code maintained, but the context information can also be flexibly managed and updated, further enhancing the maintainability and adaptability of the system.

[0097] In some embodiments described above, this application proposes adding structured comment blocks to the source code after injecting the behavior agent replacement logic. These comment blocks list the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation states of the behavior agent, thus obtaining a static analysis context description. However, in practical applications, especially in large, complex, or distributed applications, maintaining this context information solely through static comment blocks may have limitations. For example, manually updating comment blocks when application code, external configuration, or defect simulation logic changes can easily lead to inconsistencies or outdated information, and it is difficult to effectively manage the version evolution of context information and its cross-component relationships. Failure to address these issues may affect the accuracy and maintainability of the generated training data.

[0098] In response, this application further proposes an optimized method for adding the above-mentioned structured annotation blocks. By introducing metadata identifiers, version information, references to external metadata storage, and cross-file or cross-module association identifiers, it aims to improve the robustness, traceability, and association capabilities of static analysis context descriptions in a distributed environment.

[0099] Specifically, in the source code after injecting the behavior agent replacement logic, a structured comment block is added. This structured comment block explicitly lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, including:

[0100] In the source code after the injection behavior proxy replacement logic, add a structured comment block. The structured comment block contains metadata identifiers, version information, and references to external metadata storage. The structured comment block includes cross-file or cross-module association identifiers. The association identifiers are used to logically associate the context information of the current injection point with the context information of other related components in the distributed system.

[0101] The system stores the original component, the activated defect type, the simulated external configuration conditions, and the internal defect activation status of the behavior agent.

[0102] The metadata identifier can be understood as a tag or code that uniquely identifies the context information described by the structured comment block. Its purpose is to provide a unique handle for programmable access and management of the context information at each injection point. The version information is used to record the creation time, last modification time, or specific version number of the context information, ensuring that the corresponding version of the context information can be obtained when analyzing the source code at different points in time, thereby guaranteeing the accuracy and reproducibility of the training data. The reference to external metadata storage refers to including a link or identifier in the comment block that points to an independent, centralized metadata storage system, rather than directly embedding all detailed information into the source code comments. This approach allows the context information to be dynamically updated and managed without modifying the source code itself.

[0103] Furthermore, the cross-file or cross-module association identifier is designed to address scenarios in distributed systems or large monolithic applications where defective behavior may involve the collaborative action of multiple components or modules. This association identifier logically associates the context information of the current injection point (e.g., a function within a microservice) with the context information of other relevant components in the distributed system (e.g., another microservice or a shared library). For example, when triggering a defective behavior requires specific interactions between multiple services, this association identifier can be used to trace and integrate the context information of all relevant components, forming a complete defect triggering condition chain.

[0104] Thus, core information such as the original components, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent are stored in a structured manner. The original components refer to the original code modules or functional units replaced or simulated by the behavior agent. The activated defect types refer to the specific security defect categories that the behavior agent is designed to simulate, such as SQL injection and XSS. The simulated external configuration conditions refer to the external environment or configuration parameters required to trigger defective behavior, such as specific database connection strings and environment variable settings. The internal defect activation status of the behavior agent refers to the flags or parameters used within the behavior agent to control whether defective behavior is activated. The storage of this information provides a comprehensive and structured basis for subsequent static analysis and training data generation.

[0105] This application's solution introduces metadata identifiers, version information, and references to external metadata storage into structured comment blocks, transforming static analysis context descriptions from mere static text in the source code into manageable and traceable dynamic entities. When the source code or its dependent external configurations change, the information in the external metadata storage can be updated independently of the source code, ensuring context accuracy through version information. Furthermore, through cross-file or cross-module association identifiers, this application logically connects context information scattered across different code locations or services, thereby constructing more comprehensive and accurate defect triggering conditions and execution paths, particularly suitable for analyzing complex security flaws in distributed systems. This mechanism effectively addresses the shortcomings of traditional static comment blocks in terms of information consistency, maintainability, and cross-component correlation.

[0106] Through the above technical solutions, this application can significantly improve the quality and efficiency of static application security detection training data generation. Specifically, the introduction of metadata identifiers and version information makes the context information unique and traceable, avoiding training data bias caused by outdated or inconsistent information. References to external metadata storage enable centralized management and dynamic updates of context information, reducing maintenance costs and ensuring high synchronization between the context and the actual operating environment. Furthermore, cross-file or cross-module association identifiers enable more accurate capture and simulation of complex defect behaviors across components in distributed or microservice architectures, thereby generating more representative and practically valuable training data. These improvements collectively enhance the robustness and adaptability of static analysis context descriptions, providing a solid foundation for building high-precision, high-coverage static application security detection models.

[0107] In some embodiments described above in this application, a structured annotation block is added to the source code after injecting behavioral proxy replacement logic. This structured annotation block contains metadata identifiers, version information, and references to external metadata storage. However, during implementation, if the metadata in the external metadata storage changes, and the references in the source code are not updated in a timely manner, the context information relied upon for static analysis may not match the actual situation, thus affecting the accuracy of defect detection. If this problem is not addressed, the generated training data may contain inconsistent context information, reducing the effectiveness of the trained model.

[0108] To address this, this application further proposes a metadata version management mechanism to ensure the accuracy and consistency of the static analysis context. This mechanism effectively addresses the challenges posed by external metadata changes by generating timestamps for metadata references, maintaining a historical record of external metadata versions, comparing reference timestamps with the latest metadata timestamps, and triggering warnings and retrieving the corresponding historical versions when inconsistencies are found.

[0109] Specifically, in the source code after the injected behavior proxy replacement logic, a structured comment block is added. This structured comment block includes a metadata identifier, version information, and a reference to an external metadata store, followed by:

[0110] Generate a timestamp for the reference;

[0111] In the external metadata store, a version history is maintained for each metadata entry, and the version history records the timestamp of each change to the metadata entry;

[0112] When resolving the reference, the timestamp in the reference is compared with the latest timestamp of the corresponding metadata in the external metadata storage;

[0113] Based on the comparison results, if the timestamp in the reference is inconsistent with the latest timestamp of the corresponding metadata in the external metadata storage, a metadata version mismatch warning is triggered, and metadata corresponding to the timestamp in the reference is retrieved from the version history according to the preset version compatibility strategy.

[0114] "Generating a timestamp for the reference" means that when a reference pointing to external metadata storage is created or updated in the source code, the system automatically generates a timestamp and embeds it into the reference. This timestamp accurately records the state of the external metadata pointed to by the reference at a specific moment, serving as a unique identifier for that metadata version.

[0115] "Maintaining a version history for each metadata entry in the external metadata store, where the version history records the timestamp of each change to the metadata entry" means that the external metadata storage system is configured to perform version control on each metadata entry. Whenever a metadata entry is modified, the system creates a new version and records the timestamp of this change. These versions and their corresponding timestamps together constitute the complete version history of the metadata entry, ensuring the traceability of all historical versions.

[0116] "When parsing the reference, comparing the timestamp in the reference with the latest timestamp of the corresponding metadata in the external metadata storage" means that when the static analysis tool needs to parse metadata references in a structured annotation block, it first extracts the embedded timestamp from the reference. Simultaneously, the system queries the external metadata storage to obtain the latest version timestamp of the metadata entry pointed to by the reference. Subsequently, these two timestamps are precisely compared.

[0117] "Based on the comparison results, if the timestamp in the reference is inconsistent with the latest timestamp of the corresponding metadata in the external metadata storage, a metadata version mismatch warning is triggered, and metadata corresponding to the timestamp in the reference is retrieved from the version history according to a preset version compatibility strategy." This means that if the comparison results show that the timestamp in the reference is inconsistent with the latest timestamp in the external metadata storage, it indicates that the external metadata has changed since the reference was created. In this case, the system will immediately trigger a metadata version mismatch warning to alert the user or subsequent processing. Furthermore, the system will, according to a preset version compatibility strategy (e.g., strict matching, forward compatibility, or backward compatibility), accurately retrieve the historical version metadata corresponding to the timestamp in the reference from the version history of the metadata entry to ensure that the static analysis uses the correct context information.

[0118] This application's solution effectively addresses the potential version inconsistency between dynamic changes in external metadata and static references in the source code by introducing a timestamp and version history mechanism. Specifically, by generating a timestamp for each metadata reference, this application's solution provides a clear version snapshot of the external metadata that the reference depends on. When resolving a reference, comparing the timestamp in the reference with the latest timestamp in the external metadata storage allows for timely detection of metadata version mismatches. Once an inconsistency is detected, the system not only issues a warning but, more importantly, retrieves the metadata version precisely corresponding to the reference timestamp from a detailed version history based on a preset version compatibility strategy. This ensures that even if external metadata is updated, static analysis is always based on the correct metadata context expected when the code sample was created, thereby avoiding false positives or false negatives caused by metadata version differences.

[0119] Through the aforementioned technical solution, this application significantly improves the robustness and accuracy of the training data generation method based on static application security detection. This solution ensures that the external metadata context upon which static analysis relies remains accurate and traceable in a dynamically changing development environment, thereby avoiding analysis errors caused by metadata version mismatches. This not only improves the reliability of defect detection but also enhances the quality and effectiveness of the generated training data, thus improving the technical performance of the Static Application Security Detection Tool (SAST) itself and providing a solid foundation for subsequent machine learning model training. Furthermore, by providing version mismatch warnings and the ability to retrieve historical versions on demand, this application's solution greatly enhances the system's maintainability and diagnostic capabilities.

[0120] In some of the embodiments described above in this application, a version history is maintained for each metadata entry in an external metadata store, and a timestamp of each change is recorded. However, if an efficient and reliable mechanism is not adopted to manage these version histories during implementation, it may lead to problems such as difficulty in version tracing, difficulty in ensuring data integrity, and low efficiency in version management in a distributed environment.

[0121] In this regard, this application further proposes maintaining a version history for each metadata entry in an external metadata storage, wherein the version history records the timestamp of each change to the metadata entry, including:

[0122] The external metadata storage adopts a content-addressable distributed version control system;

[0123] Each time the metadata entry is modified, a new content hash value is generated as a version identifier;

[0124] The version history of the metadata entries is stored in a chain structure using a distributed hash table index. Each version node in the chain structure contains a timestamp, a content hash value, and a pointer to the previous version.

[0125] Specifically, the external metadata storage can be understood as a persistent storage medium or system used to store metadata information. As a preferred implementation, this storage system is designed to employ a content-addressed distributed version control system. Content-addressed means that the unique identifier of the data (e.g., a hash value) originates directly from the data content itself, rather than being assigned by an external system. The distributed version control system allows metadata to be stored and managed on multiple nodes, improving system availability and fault tolerance. For example, technologies such as Git and IPFS (InterPlanetary File System) can be used as the underlying implementation.

[0126] Each time a metadata entry is modified, the system generates a new content hash value as a version identifier. This content hash value is obtained by performing a cryptographic hash calculation on the modified metadata entry content, ensuring the uniqueness of each version identifier. Furthermore, any minor modification to the metadata content will result in a change in the hash value, thus guaranteeing the immutability of the version. For example, hash algorithms such as SHA-256 can be used.

[0127] Furthermore, the version history of the metadata entries is stored in a chained structure using a distributed hash table index. A distributed hash table (DHT) can efficiently map content hash values ​​to storage locations, enabling fast retrieval of metadata versions. The chained structure means that each version node contains a pointer to its previous version, forming an immutable chain. Specifically, each version node in the chained structure contains a timestamp, a content hash value, and a pointer to the previous version. The timestamp records the specific time the version was created; the content hash value serves as a unique identifier for the version; and the pointer to the previous version establishes a historical association between versions, allowing for complete tracing of all changes to the metadata entries.

[0128] This application's solution effectively addresses the problems of version tracing difficulties, data integrity issues, and low efficiency in distributed environments inherent in traditional version management by introducing a content-addressable distributed version control system. Specifically, when a metadata entry changes, the system generates a new content hash value as a version identifier. This hash value directly reflects the metadata content, ensuring the uniqueness and immutability of each version. Any unauthorized modification will result in a hash value mismatch, which will be detected immediately, greatly enhancing data integrity. Simultaneously, a distributed hash table index allows for efficient location and retrieval of metadata for any historical version. Furthermore, the version history is stored in a chained structure, with each version node containing a timestamp, a content hash value, and a pointer to the previous version. This structure naturally provides complete audit trail capabilities, allowing users to clearly trace all change paths and time points of metadata from creation to the current state, thus solving the version tracing problem. In addition, the adoption of a distributed version control system enables metadata version management to possess high availability and scalability, adapting to large-scale, high-concurrency distributed application scenarios.

[0129] Through the above technical solution, this application provides a highly reliable, auditable, and efficient version management mechanism for external metadata storage. Compared to solutions that only record timestamps, this application ensures the immutability and integrity of metadata versions through content hash values, effectively preventing malicious tampering or accidental data loss. The chain-like structure design makes the metadata change history fully traceable, greatly simplifying version backtracking and auditing. In some preferred embodiments, this application is specifically implemented as follows:

[0130] Suppose that during the generation of training data for static application security testing, a metadata entry regarding "security processing logic" needs to be maintained. This entry contains security configuration information for a specific service interface. When this security configuration information changes, for example, from "allow all requests" to "allow only authenticated requests," the system will trigger an update to the metadata entry.

[0131] Specifically, when a user submits a change to this metadata entry:

[0132] 1. The system first obtains the content of the changed metadata entry and performs a SHA-256 hash calculation on it to generate a new content hash value, such as `hash_new_config`.

[0133] 2. The `hash_new_config` is used as a unique identifier for the new version.

[0134] 3. The system creates a new version node, which contains the current timestamp, `hash_new_config`, and a pointer to the previous version node (e.g., `hash_old_config`).

[0135] 4. This new version node and its content are stored in an IPFS-based distributed version control system. IPFS utilizes its content addressing feature to ensure that `hash_new_config` can uniquely map to the new version metadata content stored on the network.

[0136] 5. Through a distributed hash table (e.g., a DHT based on the Kademlia protocol), the version node can be quickly located based on `hash_new_config`, and further traced back to all historical versions through its pointer to the previous version.

[0137] For example, if it is necessary to trace back to a security configuration at a specific point in time, the system can query the version node corresponding to that timestamp and verify its content hash value, thereby ensuring that the obtained historical configuration is authentic and has not been tampered with. This mechanism not only ensures the consistency and reliability of metadata during the training data generation process, but also provides strong support for subsequent security audits and problem investigation.

[0138] In some of the embodiments described above in this application, a method is proposed to compare the timestamp in the reference with the latest timestamp of the corresponding metadata in the external metadata storage when resolving the reference. However, in its implementation, if the latest timestamp itself has integrity issues or has not been effectively verified, it may lead to inaccurate comparison results, thereby affecting the reliability of metadata version management and potentially introducing security risks.

[0139] In this regard, this application further proposes that when resolving the aforementioned reference, the steps of comparing the timestamp in the reference with the latest timestamp of the corresponding metadata in the external metadata storage include:

[0140] When resolving a reference, extract the timestamp from the reference;

[0141] Send a query request to retrieve the latest timestamp of the corresponding metadata in the external metadata storage;

[0142] Perform integrity verification and validation on the latest timestamp obtained;

[0143] The obtained timestamp is compared with the latest timestamp after integrity verification to determine whether the two are consistent.

[0144] Specifically, when resolving a reference, the first step is to accurately extract the timestamp contained within it. This reference can be a link, path, or identifier pointing to external metadata storage, and it typically embeds a timestamp indicating the point in time of the metadata version the reference points to. This extraction process can be accomplished by resolving the reference's specific format or structure.

[0145] The system then sends a query request to the external metadata store to retrieve the latest timestamp corresponding to the metadata entry referenced by the reference. The external metadata store can be a distributed database, a file system, or a dedicated metadata service, which is responsible for maintaining the version history of each metadata entry and providing the latest version timestamp.

[0146] Among the key steps in this solution is verifying the integrity of the latest timestamp obtained. Integrity verification aims to ensure that the acquired timestamp data has not been tampered with or corrupted during transmission or storage. This can be achieved in various ways, such as calculating a hash value for the timestamp data and comparing it with a pre-stored hash value, or using digital signature technology to verify its origin and integrity. The verification step further confirms the validity of the timestamp, such as checking whether its format conforms to specifications and whether it falls within a reasonable timeframe.

[0147] Finally, the timestamp extracted from the reference is compared with the latest timestamp that has been verified and validated for integrity. If they match, it indicates that the metadata version pointed to by the reference matches the latest version in external storage; if they do not match, a version mismatch warning may be triggered, and further processing will be performed according to a preset strategy.

[0148] This application's solution effectively addresses the limitation of traditional solutions where unreliable comparison results may arise due to inherent problems with the latest timestamp data itself, by introducing an integrity verification and validation step for the latest timestamp before the comparison. Specifically, extracting the timestamp from the reference ensures the accuracy of the comparison benchmark; sending a query request to obtain the latest timestamp is a necessary step in acquiring the comparison object; and performing integrity verification and validation on the acquired latest timestamp fundamentally guarantees the authenticity and reliability of the comparison object, avoiding erroneous judgments caused by data corruption or malicious tampering. Therefore, by comparing the rigorously verified latest timestamp with the timestamp in the reference, the accuracy and security of version matching judgment are ensured.

[0149] Through the above technical solution, this application can significantly improve the reliability and security of metadata version comparison. By performing integrity verification and validation on the latest timestamp obtained, it effectively avoids timestamp data anomalies caused by data transmission errors, storage corruption, or malicious attacks, thereby ensuring the accuracy of version comparison results. This enables the system to make decisions based on more reliable information when dealing with metadata version mismatches, such as triggering warnings or implementing version compatibility policies, thereby improving the robustness and reliability of the entire static application security detection training data generation method.

[0150] In some preferred embodiments, a specific example is given below. Suppose a structured annotation block contains a reference to an external metadata store, such as `metadata_repo / component_A / config_v1.2.json?timestamp=1678886400`. When parsing this reference, the timestamp 1678886400 is first extracted from the URL parameter.

[0151] The system then sends a query request to `metadata_repo` to retrieve the latest timestamp of `component_A / config_v1.2.json` in the external metadata store. Assume the latest timestamp returned by the external storage is 1678886400, and that this timestamp is accompanied by a digital signature or checksum.

[0152] Next, the system will perform an integrity check on the latest timestamp 1678886400 and its accompanying verification information. For example, it will verify the digital signature or recalculate the checksum and compare it with the received checksum to confirm that the timestamp data has not been tampered with during transmission. If the verification passes, the latest timestamp is considered complete and reliable.

[0153] Finally, the timestamp 1678886400 extracted from the reference is compared with the latest timestamp 1678886400 after integrity verification. Since they match, the system determines that the metadata version matches, and there is no need to trigger a warning or perform a version rollback.

[0154] Conversely, if the latest timestamp returned by the external storage is 1678887200, and the integrity check has been performed, the comparison result is inconsistent. The system will trigger a metadata version mismatch warning according to the preset policy, and may attempt to retrieve the metadata corresponding to version 1678886400 from the historical records.

[0155] In some of the embodiments described above in this application, verifying the integrity of the latest timestamp is a crucial step in ensuring the reliability of metadata. However, in practical applications, when metadata may be stored in heterogeneous systems or exist in fragmented form, traditional single verification mechanisms may struggle to comprehensively cover all data fragments, thus failing to effectively guarantee the integrity of the overall metadata and posing a potential risk of data inconsistency or tampering. To address this, this application further proposes an optimized scheme for verifying the integrity of the latest timestamp, aiming to ensure high reliability of metadata in complex storage environments through a multi-dimensional, fragmented verification mechanism.

[0156] Specifically, the integrity verification of the latest timestamp obtained includes:

[0157] Identify the sharding method and storage location of the metadata corresponding to the latest timestamp in the heterogeneous storage system;

[0158] Based on the sharding method and the storage location, obtain the corresponding metadata fragments from each heterogeneous storage system;

[0159] For each acquired metadata fragment, the fragment verification value is calculated independently according to the verification mechanism of the corresponding storage system;

[0160] Merge all metadata fragments into complete metadata and calculate the overall checksum of the complete metadata;

[0161] The overall verification value is compared with the preset complete metadata verification value to determine the overall integrity of the complete metadata.

[0162] Identifying the sharding method and storage location of the metadata corresponding to the latest timestamp in the heterogeneous storage system means that the system first needs to obtain detailed information about the metadata storage topology. This includes understanding whether the metadata is divided into multiple fragments and which different types of storage systems these fragments are stored in (e.g., relational databases, NoSQL databases, distributed file systems, object storage, etc.). The sharding method can refer to horizontal sharding, vertical sharding, or hash-based sharding, etc. The storage location specifically refers to the specific address or identifier of each fragment in the corresponding storage system.

[0163] Furthermore, retrieving corresponding metadata fragments from various heterogeneous storage systems based on the sharding method and storage location means that, after clarifying the distribution of metadata, the system will, according to the identified sharding strategy and storage location information, retrieve all fragments constituting complete metadata from different heterogeneous storage systems in parallel or serially through corresponding storage interfaces or protocols. For example, if metadata is sharded and stored in database A and file system B, the system will retrieve the corresponding fragments from A and B respectively.

[0164] Furthermore, for each acquired metadata fragment, a fragment checksum is calculated independently based on the corresponding storage system's verification mechanism. This means that after acquiring the various metadata fragments, the system does not immediately merge them. Instead, for each fragment, an independent checksum is calculated using the verification methods provided or recommended by its respective storage system (e.g., row-level checksums for databases, block-level checksums for file systems, ETags for object storage, etc.). This measure aims to ensure that each local fragment is not damaged or tampered with during transmission or storage.

[0165] Subsequently, all metadata fragments are merged into complete metadata. The overall checksum of this complete metadata is calculated. This means that after the independent verification of all fragments, the system recombines these verified fragments according to a predetermined order or logical structure to form a complete metadata entity. Based on this, the system calculates an overall checksum for this complete metadata, using hash algorithms such as MD5 or SHA-256, to provide macroscopic integrity assurance for the entire metadata content.

[0166] Finally, the overall verification value is compared with a preset complete metadata verification value to determine the overall integrity of the complete metadata. This means that the system compares the calculated overall verification value of the complete metadata with a preset verification value that is stored in advance or is known and represents the correct metadata status. If the two are consistent, it indicates that the metadata has maintained its integrity during the acquisition and reconstruction process; otherwise, it indicates that the metadata may be damaged, tampered with, or inconsistent, requiring further processing.

[0167] This application's solution effectively addresses the problem that traditional single-verification methods cannot fully guarantee data integrity when metadata is distributed across heterogeneous systems or exists in fragmented form. Specifically, it first identifies the metadata fragmentation method and storage location, enabling the system to accurately locate and retrieve all fragments constituting complete metadata, avoiding omissions or mis-retrieval. Second, each retrieved metadata fragment is independently verified, utilizing the verification mechanisms of each storage system to ensure the reliability of local data, which is crucial for detecting minor local damage or tampering. Finally, by merging all fragments and calculating the overall verification value, it compares it with a preset value, providing macro-level integrity assurance for the entire metadata content. It is precisely this verification strategy, from local to overall, from heterogeneous to unified, that enables comprehensive and reliable verification of metadata integrity in complex storage environments.

[0168] Through the above technical solution, this application can significantly improve the accuracy and reliability of metadata integrity verification, especially in complex scenarios where metadata is distributed and stored in heterogeneous systems or exists in fragmented form. Compared with methods that only perform a single overall verification, this application can more precisely detect local data corruption or tampering by independently verifying each metadata fragment, thereby effectively avoiding overall verification failure or misjudgment due to partial data problems. In addition, the verification is combined with the characteristics of heterogeneous storage systems, making the verification process more targeted and efficient, further enhancing the system's ability to ensure metadata reliability, and providing a more solid data foundation for subsequent defect confirmation and tag generation.

[0169] In some preferred embodiments, a specific example is given below. Suppose a metadata entry is logically divided into three fragments: fragment A is stored in a relational database (such as MySQL), fragment B is stored in a distributed file system (such as HDFS), and fragment C is stored in a key-value store (such as Redis).

[0170] First, the system identifies that the metadata entry consists of three fragments and determines their respective storage systems and locations. For example, fragment A might be a specific row in a table in MySQL, fragment B might be a file on HDFS, and fragment C might be a key-value pair in Redis.

[0171] Next, based on this information, the system retrieves fragment A, fragment B, and fragment C from MySQL, HDFS, and Redis, respectively. During the retrieval process, the system utilizes the verification mechanisms inherent in each storage system. For example, for fragment A in MySQL, the CRC32 checksum of its corresponding row data can be calculated; for fragment B in HDFS, HDFS's block-level checksum mechanism can be used; and for fragment C in Redis, its MD5 hash can be calculated. These independent fragment checksums are calculated and stored.

[0172] The system then merges the acquired fragments A, B, and C in a predetermined logical order to form complete metadata. For example, if the metadata is a JSON object, the contents of the three fragments are concatenated into a complete JSON string. The system then calculates the overall checksum of this complete metadata, for example, by generating a hash value using the SHA-256 algorithm.

[0173] Finally, the system compares the calculated SHA-256 hash value with a pre-stored SHA-256 hash value representing the correct state of the metadata. If they match, the integrity of the metadata in the heterogeneous storage environment is confirmed; if they do not match, a warning is triggered, indicating that the metadata may be corrupted or tampered with, requiring further investigation and processing. This layered, fragmented verification method ensures that even if a single fragment in a storage system has a problem, it can be detected promptly, thus improving the robustness of the overall metadata verification.

[0174] Reference Figure 3 The present invention provides a training data generation system architecture diagram based on static application security detection, comprising:

[0175] The detection end is used to analyze the source code of the target application to obtain key condition variables and their usage locations; based on the key condition variables and their usage locations, conditional logic is introduced into the source code to create an unsafe execution path triggered under specific runtime conditions;

[0176] The processing end is used to generate runtime environment simulation information according to the conditional logic; verify the source code sample after introducing the conditional logic, and confirm whether a defect exists according to the environment simulation information; if so, generate a defect label. It should be noted that the training data generation system based on static application security detection provided in this embodiment of the invention is used to execute all the process steps of the training data generation method based on static application security detection in the above embodiments. The working principles and beneficial effects of the two correspond one-to-one, and therefore will not be described again. This embodiment of the invention also provides a terminal device. The terminal device includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the above embodiments of the training data generation method based on static application security detection, for example... Figure 1 As shown. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the above system embodiments.

[0177] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the terminal device.

[0178] The terminal device may be a desktop computer, laptop, handheld computer, or smart tablet, etc. The terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above components are merely examples of terminal devices and do not constitute a limitation on the terminal device. It may include more or fewer components than described above, or a combination of certain components, or different components. For example, the terminal device may also include input / output devices, network access devices, buses, etc.

[0179] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0180] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the terminal device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0181] Wherein, if the modules / units integrated in the terminal device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the various method embodiments described above.

[0182] The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or system capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0183] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0184] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for generating training data based on static application security detection, characterized in that, include: Analyze the source code of the target application to obtain key condition variables and their usage locations; Based on the key condition variables and the usage location, conditional logic is introduced into the source code to create unsafe execution paths that are triggered under specific runtime conditions; Based on the aforementioned conditional logic, runtime environment simulation information is generated; The source code sample after introducing the conditional logic is verified, and the presence of defects is confirmed based on the environmental simulation information; if so, a defect label is generated. The step of introducing conditional logic into the source code based on the key condition variables and the usage location to create an unsafe execution path triggered under specific runtime conditions includes: Static analysis is performed on the source code to identify the security processing logic called through the service interface, and the method signature, parameter type and return value of the security processing logic are analyzed. Read the location of the external configuration, establish the mapping relationship between the external configuration and the dynamic component, and obtain the dynamic security service interface and external configuration dependencies; A behavior proxy class is generated based on the dynamic security service interface and the external configuration dependency. The behavior proxy class implements the dynamic security service interface. The internal logic of the behavior proxy class is to simulate defective behavior under specific conditions. The behavior proxy class contains a flag to control the defective behavior, which is used to activate or deactivate the defective behavior to obtain the defective behavior proxy. The specific conditions include skipping security checks, returning error data, or performing unauthorized operations.

2. The training data generation method based on static application security detection according to claim 1, characterized in that, The method further includes: In the source code after injecting the behavior agent replacement logic, add a structured comment block. The structured comment block lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, thus obtaining a static analysis context description.

3. The training data generation method based on static application security detection according to claim 2, characterized in that, The obtained static analysis context description includes: Identify and analyze the remote configuration services or inter-component communication protocols that the original components depend on in the distributed environment; Generate a context mapping table for distributed conditions, wherein the context mapping table associates the internal defect activation state with a specific configuration item in the remote configuration service or a specific data field in the inter-component communication protocol; The structured annotation block contains a reference to the context mapping table; The reference is parsed to obtain the complete conditional context across components.

4. The training data generation method based on static application security detection according to claim 2, characterized in that, In the source code after the injected behavior agent replacement logic, a structured comment block is added. This structured comment block explicitly lists the original components simulated by the behavior agent, the activated defect types, the simulated external configuration conditions, and the internal defect activation status of the behavior agent, including: In the source code after the injection behavior proxy replacement logic, add a structured comment block. The structured comment block contains metadata identifiers, version information, and references to external metadata storage. The structured comment block includes cross-file or cross-module association identifiers. The association identifiers are used to logically associate the context information of the current injection point with the context information of other related components in the distributed system. The system stores the original component, the activated defect type, the simulated external configuration conditions, and the internal defect activation status of the behavior agent.

5. The training data generation method based on static application security detection according to claim 4, characterized in that, In the source code following the injection behavior proxy replacement logic, a structured comment block is added. This structured comment block includes a metadata identifier, version information, and a reference to an external metadata store. It also includes: Generate a timestamp for the reference; In the external metadata store, a version history is maintained for each metadata entry, and the version history is updated with the timestamp of each change to the metadata entry; When resolving the reference, the timestamp in the reference is compared with the latest timestamp of the corresponding metadata in the external metadata storage; Based on the comparison results, if the timestamp in the reference is inconsistent with the latest timestamp of the corresponding metadata in the external metadata storage, a metadata version mismatch warning is triggered, and according to the preset version compatibility strategy, the metadata corresponding to the timestamp in the reference is retrieved from the version history.

6. The training data generation method based on static application security detection according to claim 5, characterized in that, The method of maintaining a version history for each metadata entry in an external metadata store, wherein the version history updates the timestamp of each change to the metadata entry, includes: The external metadata storage adopts a content-addressable distributed version control system; Each time the metadata entry is modified, a new content hash value is generated as a version identifier; The version history of the metadata entries is stored in a chain structure using a distributed hash table index. Each version node in the chain structure contains a timestamp, a content hash value, and a pointer to the previous version.

7. The training data generation method based on static application security detection according to claim 5, characterized in that, When resolving the reference, the timestamp in the reference is compared with the latest timestamp of the corresponding metadata in the external metadata storage, including: When resolving the reference, the timestamp is extracted from the reference; Send a query request to obtain the latest timestamp of the corresponding metadata in the external metadata storage; Perform integrity verification and validation on the latest timestamp obtained; The obtained timestamp is compared with the latest timestamp after integrity verification to determine whether the two are consistent.

8. The training data generation method based on static application security detection according to claim 7, characterized in that, The integrity verification of the latest timestamp obtained includes: Identify the sharding method and storage location of the metadata corresponding to the latest timestamp in the heterogeneous storage system; Based on the sharding method and the storage location, obtain the corresponding metadata fragments from each heterogeneous storage system; For each acquired metadata fragment, the fragment verification value is calculated independently according to the verification mechanism of the corresponding storage system; Merge all metadata fragments into complete metadata and calculate the overall checksum of the complete metadata; The overall verification value is compared with the preset complete metadata verification value to determine the overall integrity of the complete metadata.

9. A training data generation system based on static application security detection, characterized in that, include: The detection end is used to analyze the source code of the target application to obtain key condition variables and their usage locations; Based on the key condition variables and the usage location, conditional logic is introduced into the source code to create unsafe execution paths that are triggered under specific runtime conditions; The step of introducing conditional logic into the source code based on the key condition variables and the usage location to create an unsafe execution path triggered under specific runtime conditions includes: Static analysis is performed on the source code to identify the security processing logic called through the service interface, and the method signature, parameter type and return value of the security processing logic are analyzed. Read the location of the external configuration, establish the mapping relationship between the external configuration and the dynamic component, and obtain the dynamic security service interface and external configuration dependencies; A behavior proxy class is generated based on the dynamic security service interface and the external configuration dependency. The behavior proxy class implements the dynamic security service interface. The internal logic of the behavior proxy class is to simulate defective behavior under specific conditions. The behavior proxy class contains a flag to control the defective behavior, which is used to activate or deactivate the defective behavior to obtain the defective behavior proxy. The specific conditions include skipping security checks, returning error data, or performing unauthorized operations. The processing end is used to generate runtime environment simulation information based on the conditional logic; to verify the source code sample after the conditional logic is introduced, and to confirm whether a defect exists based on the environment simulation information; if so, a defect label is generated.

Images