Security rule base dynamic linkage code review method, device and related equipment

Abstract

The application relates to the technical field of computer software, can be applied to the field of science and technology finance / digital medicine, and discloses a dynamic linkage code review method of a security rule base. The method comprises the following steps: receiving a code submission request, obtaining source code data and running environment identification data associated with the code submission request; determining rule screening conditions according to the running environment identification data, generating rule query parameters, and sending a rule acquisition request to the security rule base based on the rule query parameters; receiving a target rule data set returned by the security rule base and corresponding to the running environment identification data; performing matching processing on the source code data according to the target rule data set, and generating risk level data corresponding to the source code data according to the matching processing result; generating a code submission control instruction according to the risk level data, and changing the submission process state of the source code data according to the code submission control instruction. The method improves the pertinence and process controllability of code security review.

Description

Technical Field

[0001] This application relates to the field of computer software technology and can be applied to the fields of financial technology / digital healthcare, and in particular to a method, apparatus and related equipment for dynamic linkage code review of security rule base. Background Technology

[0002] As software development becomes increasingly complex, code review has become a crucial step in ensuring software quality and security. Traditional code review methods primarily rely on static analysis tools, which scan source code based on fixed rule bases to identify potential defects and security vulnerabilities. However, in large-scale codebases, especially complex projects involving multiple programming languages, traditional static analysis techniques have gradually revealed many shortcomings. For example, manual code review is inefficient in large-scale projects, and it often becomes a mere formality for low-risk code submissions, failing to effectively identify potential security issues. This leads to missed vulnerabilities and data leaks. Furthermore, the rule bases of existing static analysis tools are typically fixed and cannot flexibly adapt to specific enterprise security compliance requirements. For instance, in the financial industry, many tools cannot effectively perform security checks for specific compliance standards such as PCI-DSS (Payment Card Industry Data Security Standard). In addition, the remediation mechanisms of traditional tools are relatively weak; while they can identify potential problems, they fail to provide targeted remediation suggestions. After discovering vulnerabilities, developers often need to spend additional time finding and verifying solutions, thus extending the remediation cycle and increasing development costs. Summary of the Invention

[0003] The main technical problem addressed by the implementation method of this application is that traditional code review technology struggles to identify code risks in a timely and accurate manner in multilingual and high-frequency submission scenarios, and it is also difficult to effectively control the code submission process.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a dynamic linkage code review method for a security rule base, comprising: receiving a code submission request, obtaining source code data and runtime environment identifier data associated with the code submission request; determining rule filtering conditions based on the runtime environment identifier data, generating rule query parameters, and sending a rule acquisition request to the security rule base based on the rule query parameters; receiving a target rule data set returned by the security rule base and corresponding to the runtime environment identifier data; performing matching processing on the source code data based on the target rule data set, and generating risk level data corresponding to the source code data based on the matching processing result; generating a code submission control instruction based on the risk level data, and changing the submission process status of the source code data according to the code submission control instruction.

[0005] To address the aforementioned technical problems, the second technical solution adopted in this application is: providing a dynamic linkage code review device for a security rule base, comprising: a request receiving module, used to receive code submission requests, obtain source code data and runtime environment identifier data associated with the code submission request; a rule query module, used to determine rule filtering conditions based on the runtime environment identifier data, generate rule query parameters, and send a rule acquisition request to the security rule base based on the rule query parameters; a rule receiving module, used to receive a set of target rule data returned by the security rule base and corresponding to the runtime environment identifier data; a matching and rating module, used to perform matching processing on the source code data based on the target rule data set, and generate risk level data corresponding to the source code data based on the matching processing result; and a process control module, used to generate code submission control instructions based on the risk level data, and change the submission process status of the source code data according to the code submission control instructions.

[0006] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the security rule base dynamic linkage code review method as described above.

[0007] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device executes the security rule base dynamic linkage code review method as described above.

[0008] Unlike related technologies, this application obtains runtime environment identification data associated with the submission request during the code submission stage, and determines rule filtering conditions based on the runtime environment identification data to dynamically obtain a target rule data set corresponding to the runtime environment from the security rule base. This allows code review to adapt to the submission context instead of relying on statically preset rules, thereby addressing the problems of insufficient rule adaptability and untimely risk identification in traditional code review scenarios involving multiple languages ​​and high-frequency submissions. It improves the targeting of rule matching and reduces the risk of missed or false detections caused by irrelevant rules participating in the detection. Furthermore, after obtaining the target rule data set, this application performs rule matching processing on the source code data and generates risk level data. Then, based on the risk level data, it generates code submission control instructions to change the submission process status, enabling the risk identification results to directly drive the automated handling of the submission process. This addresses the problem that traditional technologies struggle to effectively implement detection results into submission process control, achieving immediate interception or release control of risky submissions and improving the controllability and security governance capabilities of the code submission process. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0010] Figure 1 This is a schematic diagram of the operating environment of the dynamic linkage code review method for the security rule base provided in this application embodiment.

[0011] Figure 2 This is a schematic diagram of the execution flow of the security rule base dynamic linkage code review method provided in the embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the execution flow of matching data preprocessing in the dynamic linkage code review method for security rule base provided in this application embodiment.

[0013] Figure 4 This is a schematic diagram of the execution flow of generating code submission control instructions in the dynamic linkage code review method for security rule base provided in this application embodiment.

[0014] Figure 5 This is a schematic diagram of the system structure of the security rule base dynamic linkage code review device provided in the embodiments of this application.

[0015] Figure 6 This is a schematic diagram of the hardware structure of the electronic device that performs the dynamic linkage code review method for executing the security rule base provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0017] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0019] To facilitate understanding of this embodiment, a detailed description of the dynamic linkage code review method for security rule bases disclosed in this application embodiment will be provided first. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the security rule base dynamic linkage code review method provided in the embodiments of this application, such as... Figure 1 As shown, the execution subject of the dynamic linkage code review method for the security rule base provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this dynamic linkage code review method for the security rule base can be implemented by the processor calling computer-readable instructions stored in the memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0020] Please continue reading. Figure 2 , Figure 2This is a schematic diagram of the execution flow of the security rule base dynamic linkage code review method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Receive code submission requests and obtain source code data and runtime environment identification data associated with the code submission request.

[0021] In this process, at the entry point of the code review chain, "commit events" are transformed into structured input data that can be directly applied to subsequent rule filtering and risk calculation. This step receives code submission requests and extracts source code data (such as the file content, difference fragments, and associated configurations involved in the change). Simultaneously, it acquires runtime environment identification data associated with the submission request (such as context identifiers like deployment environment, target business domain, pipeline stage, and data sensitivity level). This allows subsequent processes to select rules and control workflows based on the submission context, rather than simply performing a one-size-fits-all scan of static code. In engineering implementation, the aforementioned source code data and runtime environment identification data are typically associated and encapsulated using the submission identifier as the primary key, forming a unified review input object for subsequent parsing, matching, classification, and audit tracing modules to call.

[0022] As examples, in financial scenarios, when a submission for payment or clearing services enters the release pipeline, the source code data, including the encryption processing logic, key loading configuration, and dependency list, is extracted simultaneously with the submission request. The corresponding runtime environment identifiers, such as the production environment identifier, payment business domain identifier, and release stage identifier, are also obtained. This allows subsequent reviews to more rigorously identify and control technical risks related to key management, sensitive information output, and dependent component risks within this context. In healthcare scenarios, when an interface change submission for an electronic medical record or prescription system triggers review, the source code data, including the exported interface implementation, permission verification logic, and field mapping configuration, is extracted. The runtime environment identifiers, such as the production environment identifier, patient information business domain identifier, and interface boundary identifier, are also obtained. This allows subsequent reviews to conduct targeted detection of technical risks related to permission verification, audit trails, data anonymization, and export scope restrictions, and to decide whether to approve, re-confirm, or block the submission.

[0023] S2. Determine the rule filtering conditions based on the operating environment identification data, generate rule query parameters, and send a rule retrieval request to the security rule base based on the rule query parameters.

[0024] After obtaining the source code data and its runtime environment context, the applicable security rules are filtered based on the runtime environment identification data, and rule query parameters are generated for querying the rule base, thereby achieving dynamic rule acquisition. Specifically, based on information such as environment type, business domain identifier, deployment stage, or data sensitivity level in the runtime environment identifier data, rule filtering conditions matching the current code submission are determined, and rule query parameters (such as rule category identifier, risk level range, or business domain identifier) ​​are constructed accordingly. Then, a rule acquisition request is sent to the security rule base through an interface to obtain a set of target rule data adapted to the current runtime environment. In this way, uniform matching of all rules can be avoided, enabling the code review process to dynamically select applicable rules based on the runtime environment, improving the targeting and execution efficiency of rule matching.

[0025] As examples, in financial scenarios, when the runtime environment identification data of a code submission indicates that the code will be deployed in a production environment and belongs to a payment business module, corresponding rule query parameters are generated based on these identifiers. A set of security rules related to the payment business and the production environment is then requested from the security rule base, such as rules concerning the use of encryption algorithms, key management specifications, or restrictions on sensitive information log output. In medical scenarios, when the runtime environment identification data indicates that the code involves electronic medical records or patient information processing modules, corresponding rule query parameters are generated based on the business domain identifier. A set of security rules related to patient information protection, access control, and data export auditing is then retrieved from the security rule base, enabling subsequent steps to perform targeted security checks on the code based on these rules.

[0026] S3. Receive the set of target rule data returned by the security rule base and corresponding to the runtime environment identifier data.

[0027] In this process, after sending a rule retrieval request, the code review system receives the target rule data set returned by the security rule base and associates this rule data set with the current code submission task as rule input for subsequent code matching processing. Specifically, the security rule base completes rule filtering based on the rule query parameters in step S2 and returns the rule data corresponding to the runtime environment identifier data to the code review system. After receiving the target rule data set, the system parses and organizes the rule identifiers, rule types, rule conditions, and risk level information contained therein, and loads the parsed rule data into the rule execution context of the current code review process. This method ensures that subsequent code matching processing is only executed based on the rule set adapted to the current runtime environment and business scenario, thereby avoiding irrelevant rules from participating in the detection and improving the targeting and execution efficiency of the code review process.

[0028] As an optional implementation, after step S3 above, an audit can also be performed, which may specifically include the following steps: S31. Obtain the rule version identifier data corresponding to the target rule data set.

[0029] Specifically, after the security rule base returns the target rule data set, the corresponding rule version identifier information is parsed or extracted from the rule data set to uniquely identify the version of the rule set used in this review. This version identifier is usually generated by the rule base when a rule is published or updated, and is used to distinguish rule sets at different points in time or under different configuration states, thereby providing a basis for subsequent auditing and tracing.

[0030] S32. Associate the rule version identifier data with the code submission request submission identifier data to generate review record data, and write the review record data into the review record storage module.

[0031] This step establishes a link between code commit records and rule versions, creating persistent review records. Rule version identifier data is bound to commit identifier data corresponding to the code commit request, constructing review record data containing information such as rule version, commit identifier, and review time. This record is then written to the review record storage module. This method allows for quick identification of the specific rule version used in a code review during subsequent review or auditing.

[0032] S33. When an audit traceability request is received, the rule version identifier data is read from the audit record storage module based on the submission identifier data.

[0033] S34. Send a versioned rule retrieval request to the security rule base according to the rule version identifier data, and receive the historical rule data set corresponding to the rule version identifier data.

[0034] This step involves restoring the historical rule environment to reproduce or verify previous review results. Based on the obtained rule version identifier data, a versioned rule retrieval request is initiated to the security rule base, causing the rule base to return a set of historical rule data consistent with that version identifier. In this way, a rule set consistent with the original review process can be retrieved again, ensuring that subsequent review operations are performed under the same rule conditions.

[0035] S35. Perform review and matching processing on the source code data corresponding to the submission identifier data based on the historical rule data set, generate review risk result data and output it.

[0036] Specifically, firstly, the source code data corresponding to the submission is located and obtained based on the submission identifier data. This source code data is then parsed to obtain a structured representation (e.g., syntax structure data or intermediate representation data) for rule detection. Subsequently, based on the rule conditions, rule types, and risk level information in the historical rule data set, rule matching operations are performed on the structured code data to determine if any code segments or configuration patterns satisfy the rule triggering conditions exist. During the matching process, the rule set can be traversed one by one, performing condition judgments or pattern comparisons on the parsed code feature data, and recording the matched rule identifiers and corresponding risk information. Finally, review risk result data is generated based on the matching results and output to verify the original review results or provide audit evidence, thereby ensuring the reproducibility and verifiability of the code review results at the rule version level.

[0037] As examples, in the software development process of financial systems, after a code submission involving payment services or clearing and settlement modules completes a security review, the version of the security rule used in that review is recorded. This rule version is then associated with the corresponding code submission identifier and stored in the review record. When subsequent security audits or compliance checks are required, the rule version used at that time can be located from the review record based on the submission identifier, and a set of historical rules consistent with that version can be retrieved from the security rule base. After obtaining the historical rule set, a matching analysis is re-executed on the source code corresponding to that submission to confirm whether the code triggered the relevant security rules under the given rule environment, and a risk review result is generated for audit verification. Similarly, in the software development process of medical information systems, for example, after a code submission involving electronic medical records or patient information processing modules completes a security review, the version of the rule used in that review is also recorded and associated with the code submission record. When it is necessary to perform security traceability or compliance review on a certain submission, the corresponding rule version information can be obtained based on the submission identifier and the rule set under that version can be restored from the security rule base. Then, the rule matching analysis can be performed on the corresponding source code again to generate review risk results, thereby verifying the accuracy of the original review results and providing a basis for medical data security audit.

[0038] Through steps S31 to S35 above, a correlation between code submission records and rule versions can be established during the code review process. This allows for accurate restoration of the rule environment used at the time of submission when subsequent audits or retrospective analyses are needed. Consequently, matching analysis can be re-executed on the corresponding source code under the same rule conditions, generating review results. This approach ensures the traceability and reproducibility of code review results, enabling the verification of the accuracy of historical review conclusions even when rules are updated or review strategies are adjusted. Simultaneously, it enhances the audit reliability and compliance of the code security review process.

[0039] S4. Match the source code data according to the target rule data set, and generate the risk level data corresponding to the source code data based on the matching results.

[0040] In step S4, after obtaining a rule set adapted to the current operating environment, rule detection is performed on the source code to be reviewed, generating a risk assessment result. Specifically, the structured representation or feature data of the code obtained from the aforementioned parsing is compared item by item with the rule conditions in the target rule data set. The rule hit status is determined by identifying whether the code structure, configuration pattern, or call relationship meets the rule triggering conditions. After completing the rule matching, the detection results are comprehensively evaluated based on the hit rule type, rule risk level, or rule weight information, thereby generating risk level data to characterize the current source code security risk level and providing a basis for subsequent code submission process control or risk handling.

[0041] As an optional implementation, the process of matching source code data according to the target rule data set in step S4 above can specifically include the following steps S401 to S404.

[0042] S401. Extract code change scope identifier data from the code submission request. The code change scope identifier data includes the identifier of the changed file set, the identifier of the changed line interval, or the identifier of the changed semantic unit.

[0043] S402. Perform incremental parsing processing on the source code data based on the code change scope identifier data to generate an intermediate representation incremental data structure corresponding to the code change scope identifier data.

[0044] Step S402 reduces unnecessary full-scale parsing overhead during code review, thereby improving detection efficiency. Specifically, it locates the code area involved in the current submission based on the code change scope identifier data, performs parsing processing only on the relevant changed parts, and generates a corresponding intermediate representation incremental data structure based on this. This intermediate representation incremental data structure only contains semantic units and control relationships related to the changed code, which can limit the detection scope to the changed parts while maintaining the expressive power of the code's semantic structure, thereby reducing repeated parsing of unchanged code.

[0045] S403. Determine the rule subset data corresponding to the intermediate representation incremental data structure based on the target rule data set, and perform incremental matching processing on the intermediate representation incremental data structure based on the rule subset data.

[0046] In step S403, after completing incremental parsing, the rule matching scope is further narrowed to improve rule detection efficiency. Based on the correlation between the target rule dataset and the intermediate incremental data structure, a subset of rules related to the current code change features is selected, and matching analysis is performed only on this subset. This avoids matching all rules one by one, allowing the rule detection process to focus more on potentially affected rule sets, thereby reducing the computational overhead caused by irrelevant rules participating in the matching.

[0047] S404. Generate incremental risk calculation result data based on incremental matching processing, and update the risk level data based on the incremental risk calculation result data.

[0048] In step S404, the code risk status is dynamically updated after incremental matching is completed. The corresponding incremental risk calculation result data is calculated based on the incremental matching result, and this result is integrated with the existing risk assessment result to update the risk level data corresponding to the current code submission. In this way, the newly added or eliminated risk status can be reflected in real time when only the changed code is analyzed, thus ensuring that the risk assessment results are continuously updated with code changes and remain consistent with the latest code status.

[0049] As examples, in the software development scenario of financial systems, when code submissions involving payment services or account management modules only modify some business logic or configuration files, the files and code areas involved in the modification can be located based on the change scope identifier data in the submission. Incremental parsing is then performed only on these changed parts to generate the corresponding intermediate representation structure. Subsequently, a subset of security rules related to the changed code is selected based on its characteristics, such as rules involving encrypted calls or sensitive information processing. Rule matching is then performed on the incremental structure to calculate the updated risk result. In the software development scenario of medical information systems, when code submissions for electronic medical records or patient information processing modules only adjust certain interface logic or data access methods, the code areas involved in the submission can also be determined based on the code change scope identifier data. Parsing and rule matching analysis are then performed only on the relevant code. In this way, security checks can be performed on the newly added or changed parts without re-analyzing the entire codebase, and the risk level of the current code submission can be updated based on the matching results.

[0050] Through steps S401 to S404, the code review process can focus on parsing and rule matching only for the code changes involved in the current submission, thereby avoiding redundant analysis of the entire codebase, reducing computational overhead, and improving detection efficiency. Simultaneously, by performing incremental risk calculations on the changed code and dynamically updating the risk level data, the risk assessment results can promptly reflect the impact of code modifications, thus improving the real-time nature and processing efficiency of the code security detection process.

[0051] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow of matching data preprocessing in the dynamic linkage code review method for security rule bases provided in this application embodiment, as shown below. Figure 3 As shown, the specific steps may include S41 to S45.

[0052] S41. Identify the programming language type corresponding to the source code data.

[0053] S42. Based on the programming language type, call the corresponding language parsing module to perform lexical and syntactic analysis on the source code data, and generate syntactic structure data corresponding to the source code data based on the analysis results.

[0054] Step S42 involves structured parsing of the source code data to convert the raw code text into a hierarchical syntactic representation suitable for subsequent analysis. Specifically, based on the identified programming language type, the corresponding language parsing module is invoked to perform lexical and syntactic analysis on the source code, parsing keywords, identifiers, operators, and statement structures into hierarchical syntactic structure data. This process allows for the structured expression of syntactic information such as statement blocks, function call relationships, and variable scope in the original code, thus providing foundational data for subsequent construction of a unified code representation and rule-matching analysis.

[0055] S43. Construct an abstract syntax tree data structure based on the syntax structure data.

[0056] S44. Perform structure normalization processing on the abstract syntax tree data structure to convert the syntax structures of different programming languages ​​into a unified intermediate representation data structure. The intermediate representation data structure is used to represent the semantic units and control flow units of source code data in a unified model.

[0057] Step S44 addresses the difficulty of rule matching caused by differences in syntactic structures across multiple programming languages. Specifically, it performs structure normalization on the abstract syntax tree data structure, mapping the syntactic structures of different programming languages ​​to a unified intermediate representation data structure through preset transformation rules. This allows semantic units, control flow relationships, and key call patterns in the code to be represented using a unified data model. In this way, subsequent security rules can be matched and analyzed at a unified code representation layer, eliminating the need to write separate detection logic for different programming languages. This improves rule reusability and reduces the complexity of rule maintenance in a multi-language environment.

[0058] S45. Extract the feature data to be matched corresponding to the target rule data set based on the intermediate representation data structure, and use the feature data to be matched as the input data for matching processing.

[0059] Step S45 extracts key feature information for rule detection from a unified code representation structure and uses it as input data for the rule matching process. Specifically, it identifies security-related code features in the intermediate representation data structure, such as function call relationships, key interface calls, configuration parameter usage, and control flow paths. These features are then filtered and organized according to the detection conditions defined in the target rule data set to form the feature data to be matched. This approach allows the rule matching process to directly perform conditional judgments or pattern recognition based on structured code features, thereby improving the accuracy and efficiency of rule detection.

[0060] As examples, in the software development scenario of financial systems, when code involving payment services, clearing and settlement modules, or account management modules is submitted for review, the first step is to identify the programming language type based on the characteristics of the code file, and then call the corresponding language parsing module to perform structured parsing of the source code. After syntax analysis and abstract syntax tree construction, the syntactic structures of different languages ​​are normalized, converting function calls, encryption interface usage, and configuration access logic in the code into a unified intermediate representation structure. This allows for the identification of code features such as encryption algorithm call methods, sensitive information log output, or key interface call chains under a unified model. Subsequently, feature data related to security rules is extracted from this intermediate representation structure, and this feature data is used as rule matching input to detect whether the code has an implementation pattern that violates financial security regulations. In the software development scenario of medical information systems, for example, when code involving electronic medical record management, patient information processing, or prescription service modules is submitted for review, the source code is similarly parsed based on the code language type to generate a syntactic structure representation. Then, through abstract syntax tree normalization, the syntactic structures of different languages ​​are mapped to a unified intermediate representation structure. This unified structure identifies key semantic units such as interface call relationships, permission verification logic, and data access paths. It further extracts code features related to medical data protection, such as patient information access control, data export processing logic, and log recording behavior. These feature data are then used to perform rule-matching analysis, thereby identifying implementation patterns in the code that may affect medical data security or access control standards.

[0061] Through steps S41 to S45, source code written in different programming languages ​​can be uniformly converted into a structured intermediate representation. This allows semantic units and control flow relationships in the code to be expressed under a unified data model, providing standardized input data for subsequent rule matching. Based on this, a unified rule detection logic can be executed based on the extracted code features, eliminating the need to build separate detection mechanisms for different programming languages. This improves the applicability of code review in multilingual environments and the ability to reuse rules, further enhancing the accuracy and efficiency of the security detection process.

[0062] S5. Generate code submission control instructions based on risk level data, and change the submission process status of source code data according to the code submission control instructions.

[0063] In step S5, after completing the code risk assessment, the code submission process is controlled based on the obtained risk level results, thereby achieving automated security governance. Specifically, a corresponding processing strategy is determined based on the generated risk level data, and corresponding code submission control instructions are generated, such as allowing the submission process to continue, triggering secondary confirmation, or blocking the submission. Subsequently, the current code submission process status is adjusted according to the control instructions, such as changing the execution status of pipeline tasks or updating the processing nodes of the submission process, so that the code submission can continue to enter the subsequent build, testing, or deployment stages if security requirements are met, or be restricted from further release if a high risk is detected. In this way, code security detection results can be directly applied to the software development process, thereby achieving automated risk control in continuous integration or continuous delivery environments.

[0064] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow of generating code submission control instructions in the dynamic linkage code review method for security rule base provided in this application embodiment, such as... Figure 4 As shown, the specific steps may include S51 to S54.

[0065] S51. Based on the risk level data, the source code data is divided into whitelist, blacklist, or graylist categories.

[0066] Step S51 maps the risk assessment results to executable process control categories, enabling subsequent control actions to be implemented with clear branching logic. Specifically, risk level data is converted into three control labels—whitelist, blacklist, or graylist—according to preset classification rules. This transforms risk results from "assessment data" into "control conditions," providing a unified entry point for determining process status changes corresponding to different risk levels and avoiding instability in process control caused by relying solely on a single threshold.

[0067] S52. When source code data is classified into a whitelist category, generate quick pass instruction data and update the submission process status to pass.

[0068] S53. When source code data is classified into a blacklist category, generate blocking submission instruction data and update the submission process status to the blocking status.

[0069] S54. When source code data is classified into a gray list category, a dynamic evaluation process is triggered, the risk scoring model is called to perform weighted calculation on the source code data, and corresponding submission process control instruction data is generated based on the calculation results.

[0070] Step S54 addresses situations where the risk level is uncertain or requires further differentiation by introducing a dynamic evaluation mechanism to generate more refined control criteria. Specifically, when source code is classified into a gray list category, a dynamic evaluation process is triggered, and a risk scoring model is invoked. The model inputs include the matched rule information, code characteristic information, and runtime environment factors. The risk is weighted and calculated to generate a more granular score or level result, which then generates corresponding submission process control instructions. This approach allows for the differentiation and handling of intermediate risk scenarios without direct blocking, improving the stability and interpretability of process control, and enabling gray list processing to balance risk management with development process continuity.

[0071] As examples, in the software development scenarios of financial systems, after code submissions involving payment services or account management modules undergo risk detection, the code is categorized based on risk level data. For instance, if the detection results indicate that the code does not trigger critical security rules and has a low risk, it can be classified into a whitelist category, allowing the code to directly enter the subsequent build or release process. If high-risk issues such as weak encryption algorithm calls, sensitive information log output, or critical security configuration errors are detected, the code is classified into a blacklist category and the submission process is blocked to prevent high-risk code from entering the production environment. If the code risk is in the intermediate range, such as involving unclear encryption interface usage or uncertainties in some security configurations, it can be classified into a graylist category. A risk scoring model is used to comprehensively calculate the relevant rule hits and environmental factors to generate a more refined risk assessment result, thereby determining whether further submission is allowed or further confirmation is required. In the software development scenarios of medical information systems, after code submissions involving electronic medical records or patient information processing modules enter the review process, the code is also categorized based on risk level. For example, when code implementation complies with access control and logging standards and does not trigger data protection rules, it can be classified as a whitelist category and directly enter the subsequent testing or deployment phase. When high-risk issues such as potential patient information leakage or missing permission verification are detected, the code will be classified as a blacklist category and submission will be blocked to avoid affecting medical data security. In some cases, if the code involves data access logic or interface permission control but the degree of risk is not yet fully determined, it can be classified as a graylist category and further evaluated using a risk scoring model combined with code characteristics and runtime environment information to generate more accurate process control decisions.

[0072] Through steps S51 to S54, the risk detection results can be transformed into executable process control categories. This enables code submissions to be handled hierarchically and form a closed-loop control within the automated development process, thereby avoiding inconsistencies caused by relying solely on manual judgment. When the risk is low, it can be quickly released to maintain delivery efficiency; when the risk is high, it can be promptly blocked to reduce the probability of high-risk code entering subsequent stages; and for situations where the risk is uncertain, dynamic evaluation generates more refined control criteria, thus achieving a balance between security and process continuity and improving the stability and interpretability of overall risk handling.

[0073] As another optional implementation, the process of changing the submission status of source code data according to the code submission control instruction in step S5 above may also specifically include the following steps S501 to S504.

[0074] S501. Generate trigger condition judgment results based on risk level data and operating environment identification data.

[0075] In step S501, the "risk assessment result" and "submission context" are integrated into an executable triggering basis, thereby avoiding misjudgments or control instability caused by making process decisions based solely on a single risk level. Specifically, risk level data and operating environment identification data are jointly judged to form a triggering condition judgment result for pipeline control, so that the same risk level can correspond to different handling intensities in different environments, and a unified judgment entry point is provided for subsequent graded actions.

[0076] S502. When the trigger condition judgment result meets the high-risk condition, generate blocking push instruction data, send blocking control signal to the continuous integration pipeline system, and send notification data containing risk information to the preset security management terminal.

[0077] In particular, step S502 implements mandatory control and alarm linkage for the continuous integration pipeline in high-risk scenarios. It generates blocking control information for pipeline execution, sending control signals to the continuous integration pipeline system to stop or roll back the submission process, thereby preventing high-risk code from entering subsequent build, release, or deployment stages. Simultaneously, it outputs notification data containing risk information to the security management side, enabling security personnel to promptly learn of risk events and conduct subsequent handling and tracking, forming a closed-loop linkage of "process blocking + security alarm."

[0078] S503. When the trigger condition judgment result meets the medium risk condition, generate repair prompt instruction data, send repair solution data to the code submission terminal, and generate secondary confirmation request data to make the submission process enter the pending confirmation state.

[0079] Step S503 addresses the "controllable release" mechanism in medium-risk scenarios, guiding remediation and strengthening human confirmation without immediate blocking. It outputs actionable remediation plan data to the code submission side, enabling developers to perform targeted remediation based on review results. Simultaneously, it puts the submission process into a pending confirmation state, separating medium-risk submissions from the automatic release path through a secondary confirmation mechanism. This reduces the probability of risks continuing to circulate without remediation or confirmation, and improves the auditability and explainability of process control.

[0080] S504. When the trigger condition judgment result meets the low-risk condition, generate audit record data, write the audit record data to the audit log storage module, and generate periodic summary task data.

[0081] As examples, in the software development scenario of financial systems, after code submissions involving payment services or account management modules complete security checks, a comprehensive judgment is made based on the risk level results and the corresponding runtime environment information. If the code involves the production environment and high-risk rules related to encrypted interface calls or sensitive log output are detected, a blocking control signal is immediately issued to the continuous integration pipeline, preventing the code from continuing into the build or release phase. Simultaneously, a risk notification is sent to the security management terminal so that security personnel can promptly understand and address the risk. If the detection result indicates a medium-risk situation, such as potential vulnerabilities in certain security configurations that can still be fixed, a repair suggestion is returned to the code submission terminal, and the code submission enters a pending confirmation state, requiring developers to fix the issues or obtain confirmation before continuing the submission process. In the software development scenario of medical information systems, when code submissions involving electronic medical records or patient information processing modules enter the review process, trigger conditions are also determined based on the risk level and runtime environment information. For example, when code triggers high-risk rules related to patient information access control or data protection in a production environment, it will prevent the code from entering the subsequent deployment stage and send a risk notification to the security management terminal to prompt relevant personnel to handle the situation. If the detection result is a medium-risk situation, such as some interface permission control logic having potential non-standard implementations but not directly causing data risks, corresponding remediation suggestions will be provided to the code submission terminal, and the submission process will enter a pending confirmation state. This allows for further confirmation and handling of potential risks without affecting the continuity of the overall development process.

[0082] Through steps S501 to S504, after code review, the code submission process can be tiered and controlled based on risk level results and runtime environment information, allowing code with different risk levels to be treated differently in the continuous integration process. For high-risk code, process blocking can be triggered promptly, and risk notifications can be sent to the security management side, thus preventing high-risk code from entering subsequent release stages. For medium-risk code, repair prompts and secondary confirmation mechanisms can guide developers to handle the issue and maintain process controllability. For low-risk code, audit records and periodic summaries enable review traceability and subsequent statistical analysis. In this way, a security management mechanism combining risk identification, process control, and audit traceability can be formed in the automated development process, thereby improving the security, controllability, and audit reliability of the code review process.

[0083] As an alternative implementation, after the process of generating code and submitting control instructions based on risk level data in step S5 above, the following steps S55 to S58 may also be included.

[0084] S55. Determine the corresponding rule identifier data based on the matching processing results.

[0085] S56. Send a case query request to the security knowledge base based on the rule identifier data, and receive audit case data corresponding to the rule identifier data.

[0086] Step S56 establishes a traceable link between the rule hit result and the enterprise's internal security knowledge system, thereby providing a reusable basis for subsequent remediation. A query is initiated to the security knowledge base using the rule identifier as the search key, prompting the knowledge base to return audit case data corresponding to the rule. This audit case data can include structured content such as risk causes, triggering patterns, handling suggestions, and historical rectification examples. By introducing case-level knowledge, "rule hit" can be transformed from a simple alarm into an interpretable handling input, providing contextual support for generating remediation solutions.

[0087] S57. Generate programming language-compatible fix code data based on the programming language type of the audit case data and source code data.

[0088] In step S57, after acquiring audit case knowledge, general remediation suggestions are converted into directly applicable remediation outputs that match the current code implementation. Combining the remediation patterns or replacement strategies in the audit case data with the programming language type and syntactic constraints of the source code, remediation code data consistent with the syntax structure of that language is generated. This includes code snippets that replace calling methods, supplement security checks, or adjust configuration usage. This approach avoids the need for developers to perform secondary searches and adaptations due to only outputting abstract suggestions, thus improving the usability and consistency of the remediation outputs.

[0089] S58. Generate specification document reference data and send the specification document reference data and the fixed code data to the code submission terminal.

[0090] In step S58, the repair output and the supporting specifications are delivered to the submission terminal simultaneously, forming a closed-loop feedback of "executable repair + traceable basis". Specification document reference data is generated to point to the enterprise specification items or compliance requirements corresponding to the current rules and rectification requirements. This reference data, along with the repair code data, is returned to the code submission terminal, enabling developers to clearly understand the source of the repair content while obtaining it, thereby enhancing the interpretability and audit traceability of the repair process.

[0091] As examples, in the software development scenario of financial systems, when code submissions involving payment services or account management modules trigger a security rule, relevant audit case data can be retrieved from the security knowledge base based on the corresponding rule identifier. This could include rectification cases from historical reviews regarding the use of encrypted interfaces or the handling of sensitive log output. Subsequently, a corresponding fix code snippet is generated based on the programming language type of the current source code. This fix code, along with reference information from relevant security specification documents, is sent to the code submission terminal, enabling developers to complete the rectification based on the example code and specification guidelines. In the software development scenario of medical information systems, when code in electronic medical records or patient information processing modules triggers data access control rules, corresponding audit case data can also be retrieved from the security knowledge base based on the rule identifier. Adaptive permission verification or data processing fix code can then be generated based on the current code language. Simultaneously, reference information from relevant data security specification documents is returned to the code submission terminal, allowing developers to adjust the code according to the specification requirements, thereby reducing potential data security risks.

[0092] Through steps S55 to S58, the rule detection results can be correlated with historical audit experience in the security knowledge base. This enables the code review system not only to identify risks but also to generate targeted remediation suggestions based on existing cases, providing developers with the corresponding regulatory guidelines for the remediation. In this way, security detection results can be directly transformed into actionable remediation plans, reducing the time developers spend analyzing risks and finding remediation methods, improving problem-solving efficiency, enhancing the interpretability and consistency of the code review process, and further improving overall security governance capabilities.

[0093] The security rule base dynamic linkage code review method provided in this application embodiment has passed.

[0094] Please continue reading. Figure 5 , Figure 5This is a schematic diagram of the system structure of the security rule base dynamic linkage code review device provided in the embodiments of this application, such as... Figure 5 As shown, the security rule base dynamic linkage code review device 50 includes: a request receiving module 51, a rule query module 52, a rule receiving module 53, a matching rating module 54, and a process control module 55.

[0095] The request receiving module 51 is specifically used to receive code submission requests, obtain source code data and runtime environment identifier data associated with the code submission request.

[0096] The rule query module 52 is specifically used to determine rule filtering conditions based on the operating environment identification data, generate rule query parameters, and send a rule retrieval request to the security rule base based on the rule query parameters; The rule receiving module 53 is specifically used to receive a set of target rule data returned by the security rule base and corresponding to the runtime environment identifier data; The matching rating module 54 is specifically used to perform matching processing on the source code data according to the target rule data set, and generate risk level data corresponding to the source code data based on the matching processing result; The process control module 55 is specifically used to generate code submission control instructions based on the risk level data, and to change the submission process status of the source code data according to the code submission control instructions.

[0097] As an optional implementation, the matching rating module 54 is further specifically used to identify the programming language type corresponding to the source code data; call the corresponding language parsing module according to the programming language type to perform lexical analysis and syntax analysis on the source code data, and generate syntax structure data corresponding to the source code data based on the analysis results; construct an abstract syntax tree data structure based on the syntax structure data; perform structure normalization processing on the abstract syntax tree data structure to convert the syntax structures of different programming languages ​​into a unified intermediate representation data structure, the intermediate representation data structure being used to represent the semantic units and control flow units of the source code data with a unified model; extract the feature data to be matched corresponding to the target rule data set based on the intermediate representation data structure, and use the feature data to be matched as the input data for the matching process.

[0098] As an optional implementation, the process control module 55 is further configured to classify the source code data into a whitelist category, a blacklist category, or a graylist category based on the risk level data; when the source code data is classified into a whitelist category, a fast pass instruction is generated, and the submission process status is updated to pass; when the source code data is classified into a blacklist category, a blocking submission instruction is generated, and the submission process status is updated to blocking; when the source code data is classified into a graylist category, a dynamic evaluation process is triggered, a risk scoring model is invoked to perform weighted calculation processing on the source code data, and corresponding submission process control instruction data is generated based on the calculation results.

[0099] As an optional implementation, the process control module 55 is further configured to generate a trigger condition judgment result based on the risk level data and the operating environment identification data; when the trigger condition judgment result meets the high-risk condition, generate blocking push instruction data, send a blocking control signal to the continuous integration pipeline system, and send notification data containing risk information to the preset security management terminal; when the trigger condition judgment result meets the medium-risk condition, generate repair prompt instruction data, send repair solution data to the code submission terminal, and generate secondary confirmation request data to make the submission process enter the pending confirmation state; when the trigger condition judgment result meets the low-risk condition, generate audit record data, write the audit record data to the audit log storage module, and generate periodic summary task data.

[0100] As an optional implementation, the process control module 55 is further configured to: determine the corresponding rule identifier data based on the matching processing result; send a case query request to the security knowledge base based on the rule identifier data; receive audit case data corresponding to the rule identifier data; generate programming language-adapted fix code data based on the programming language types of the audit case data and the source code data; generate specification document reference data; and send the specification document reference data and the fix code data to the code submission terminal.

[0101] As an optional implementation, the matching and rating module 54 is further configured to extract code change scope identifier data from the code submission request, the code change scope identifier data including a changed file set identifier, a changed line interval identifier, or a changed semantic unit identifier; perform incremental parsing processing on the source code data based on the code change scope identifier data to generate an intermediate representation incremental data structure corresponding to the code change scope identifier data; determine a rule subset data corresponding to the intermediate representation incremental data structure according to the target rule data set, and perform incremental matching processing on the intermediate representation incremental data structure according to the rule subset data; generate incremental risk calculation result data according to the incremental matching processing, and update the risk level data according to the incremental risk calculation result data.

[0102] As an optional implementation, the rule receiving module 53 is further specifically used to obtain rule version identifier data corresponding to the target rule data set; associate the rule version identifier data with the submission identifier data of the code submission request to generate review record data, and write the review record data into the review record storage module; when an audit traceability request is received, read the rule version identifier data from the review record storage module according to the submission identifier data; send a versioned rule acquisition request to the security rule base according to the rule version identifier data, and receive the historical rule data set corresponding to the rule version identifier data; perform review matching processing on the source code data corresponding to the submission identifier data according to the historical rule data set, generate review risk result data, and output it.

[0103] It should be noted that the aforementioned security rule base dynamic linkage code review device can execute the security rule base dynamic linkage code review method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in the embodiments of the security rule base dynamic linkage code review device can be found in the security rule base dynamic linkage code review method provided in the embodiments of this application.

[0104] Figure 6 This is a schematic diagram of the hardware structure of the electronic device that executes the dynamic linkage code review method for security rule bases provided in the embodiments of this application, such as... Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0105] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0106] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the dynamic linkage code review method for the security rule base in this embodiment. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the dynamic linkage code review method for the security rule base described in the above embodiment.

[0107] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the security rule base dynamic linkage code review device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and these remote memories can be connected to the security rule base dynamic linkage code review device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0108] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the security rule base dynamic linkage code review method in any of the above method embodiments. For example, they perform the above-described... Figure 2 Method steps S1 to S5, Figure 3 Method steps S41 to S45, Figure 4 The method steps S51 to S54 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0109] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0110] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 enables one or more of the processors to execute the security rule base dynamic linkage code review method in any of the above method embodiments, for example, to execute the method described above. Figure 2 Method steps S1 to S5, Figure 3Method steps S41 to S45, Figure 4 The method steps S51 to S54 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0111] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to execute the security rule base dynamic linkage code review method described in any of the above method embodiments. For example, it executes the method described above. Figure 2 Method steps S1 to S5, Figure 3 Method steps S41 to S45, Figure 4 The method steps S51 to S54 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0112] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. 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.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0114] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for dynamic linkage code review of security rule bases, characterized in that, include: Receive code submission requests and obtain source code data and runtime environment identification data associated with the code submission requests; Based on the runtime environment identification data, rule filtering conditions are determined, rule query parameters are generated, and a rule retrieval request is sent to the security rule base based on the rule query parameters; Receive the set of target rule data returned by the security rule base and corresponding to the runtime environment identifier data; The source code data is matched according to the target rule data set, and risk level data corresponding to the source code data is generated based on the matching results. Generate code submission control instructions based on the risk level data, and change the submission process status of the source code data according to the code submission control instructions.

2. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, Before the step of matching the source code data according to the target rule data set, the method further includes: Identify the programming language type corresponding to the source code data; According to the programming language type, the corresponding language parsing module is called to perform lexical and syntactic analysis on the source code data, and syntactic structure data corresponding to the source code data is generated based on the analysis results; Construct an abstract syntax tree data structure based on the grammatical structure data; The abstract syntax tree data structure is subjected to structure normalization processing to convert the syntax structures of different programming languages ​​into a unified intermediate representation data structure. The intermediate representation data structure is used to represent the semantic units and control flow units of the source code data in a unified model. Based on the intermediate representation data structure, extract the feature data to be matched corresponding to the target rule data set, and use the feature data to be matched as the input data for the matching process.

3. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, The step of generating a code to submit a control instruction based on the risk level data includes: Based on the risk level data, the source code data is divided into whitelist, blacklist, or graylist categories; When the source code data is classified into a whitelist category, quick pass instruction data is generated, and the submission process status is updated to pass status. When the source code data is classified into a blacklist category, a submission blocking instruction is generated, and the submission process status is updated to a blocking status. When the source code data is classified into a gray list category, a dynamic evaluation process is triggered, which calls the risk scoring model to perform weighted calculation on the source code data and generates corresponding submission process control instruction data based on the calculation results.

4. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, The step of changing the submission process status of the source code data according to the code submission control instruction includes: Based on the risk level data and the operating environment identification data, a trigger condition judgment result is generated; When the trigger condition judgment result meets the high-risk condition, a blocking push instruction data is generated, a blocking control signal is sent to the continuous integration pipeline system, and a notification data containing risk information is sent to the preset security management terminal. When the trigger condition judgment result meets the medium risk condition, a repair prompt instruction data is generated, repair solution data is sent to the code submission terminal, and a secondary confirmation request data is generated to make the submission process enter the pending confirmation state. When the trigger condition judgment result meets the low-risk condition, audit record data is generated, the audit record data is written to the audit log storage module, and periodic summary task data is generated.

5. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, After the step of generating a code to submit a control instruction based on the risk level data, the method further includes: The corresponding rule identifier data is determined based on the matching process result; Based on the rule identifier data, a case query request is sent to the security knowledge base, and audit case data corresponding to the rule identifier data is received. Based on the programming language type of the audit case data and the source code data, generate programming language-adapted repair code data; Generate specification document reference data, and send the specification document reference data and the fix code data to the code submission terminal.

6. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, The step of matching the source code data according to the target rule data set includes: Extract code change scope identifier data from the code submission request. The code change scope identifier data includes a set identifier of changed files, a range identifier of changed lines, or an identifier of changed semantic units. Based on the code change scope identifier data, incremental parsing processing is performed on the source code data to generate an intermediate incremental data structure corresponding to the code change scope identifier data; Based on the target rule data set, determine the rule subset data corresponding to the intermediate representation incremental data structure, and perform incremental matching processing on the intermediate representation incremental data structure based on the rule subset data; Incremental risk calculation result data is generated based on the incremental matching process, and the risk level data is updated based on the incremental risk calculation result data.

7. The method for dynamic linkage code review of security rule base according to claim 1, characterized in that, After the step of receiving the target rule data set returned by the security rule base and corresponding to the runtime environment identifier data, the method further includes: Obtain the rule version identifier data corresponding to the target rule data set; The rule version identifier data and the code submission request submission identifier data are associated to generate review record data, and the review record data is written to the review record storage module. When an audit traceability request is received, the rule version identifier data is read from the review record storage module based on the submission identifier data; Based on the rule version identifier data, a versioned rule retrieval request is sent to the security rule base, and a set of historical rule data corresponding to the rule version identifier data is received; Based on the historical rule data set, the source code data corresponding to the submission identifier data is subjected to review and matching processing to generate review risk result data and output it.

8. A dynamic linkage code review device for a security rule base, characterized in that, include: The request receiving module is used to receive code submission requests, obtain source code data and runtime environment identification data associated with the code submission request; The rule query module is used to determine rule filtering conditions based on the runtime environment identification data, generate rule query parameters, and send a rule retrieval request to the security rule base based on the rule query parameters; The rule receiving module is used to receive a set of target rule data returned by the security rule base and corresponding to the runtime environment identifier data; The matching and rating module is used to match the source code data according to the target rule data set, and generate risk level data corresponding to the source code data based on the matching results. The process control module is used to generate code submission control instructions based on the risk level data, and to change the submission process status of the source code data according to the code submission control instructions.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the dynamic linkage code review method for the security rule base as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the security rule base dynamic linkage code review method according to any one of claims 1-7.

Images