Code submission security check and configuration reminder method and device, equipment and medium

Abstract

The application relates to the field of artificial intelligence and information security technology, and discloses a code submission security verification and configuration reminding method, device, equipment and medium. The method comprises the following steps: in response to a code submission event, obtaining newly added or modified to-be-verified files in a code repository; performing category identification on the to-be-verified files and extracting to-be-verified content, wherein the to-be-verified content comprises at least one of configuration items, code segments and database statements; performing semantic analysis and security verification on the code segments and / or database statements by using a pre-trained code understanding model to obtain a first verification result; performing configuration verification on the configuration items related to a target running environment to obtain a second verification result; and generating and outputting reminding information according to the first verification result and the second verification result. The application can be applied to the code submission verification scene in the software research and release process, and can improve the code submission security verification integrity, the configuration verification reliability and the abnormal reminding accuracy.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and information security technology, and in particular to a method, apparatus, device and medium for code submission security verification and configuration reminder. Background Technology

[0002] As software systems grow in scale and iteration frequency, security verification and configuration checks during code submission have become crucial aspects of the software development process. In software development scenarios with high requirements for data security and system stability, code files, database script files, and configuration files are frequently added to or modified with each version iteration. If the submitted content contains database operation risks, configuration errors, or runtime environment incompatibility issues, it may affect the system's data security and operational stability. Therefore, how to effectively verify submitted content during the code submission phase is a technical issue that needs attention in the process of secure software development.

[0003] In existing technologies, security checks and configuration item checks before code submission typically rely on static analysis tools, manual review, or simple rule matching methods. Static analysis tools are generally used to identify security issues such as syntax errors or known patterns; manual review is usually conducted by developers or auditors who check the submissions; rule matching methods mostly use pre-defined keywords, formatting rules, or configuration rules to match and judge parts of the code, database scripts, or configuration files.

[0004] However, the above methods still have limitations when handling multiple types of commits. Static analysis tools often struggle to identify logical risks or runtime environment configuration errors in complex contexts, simple rule matching is insufficient to determine whether configuration items are suitable for the target runtime environment, and manual review is easily affected by review efficiency and omission rates. Especially when a single commit contains code files, database script files, and configuration files, existing methods struggle to consistently and comprehensively verify the execution permissions of database statements, potential execution risks, and the environment adaptability of configuration items. This can lead to security vulnerabilities or configuration anomalies in the commits only being discovered during subsequent build, deployment, or runtime phases, thus affecting system security and stability. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and medium for code submission security verification and configuration reminder, in order to solve the technical problems of existing code submission verification methods that are difficult to perform consistent and comprehensive verification of multiple types of submission content and that are difficult to identify configuration anomalies and security risks in a timely manner.

[0006] Firstly, a method for code submission security verification and configuration alerts is provided, including: In response to a code commit event, retrieve newly added or modified files to be verified in the code repository. The files to be verified include configuration files, as well as at least one of code files and database script files. The file to be verified is identified by file category, and the content to be verified is extracted from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. A pre-trained code understanding model is used to perform semantic analysis on the code fragment and / or the database statement to obtain semantic analysis results, and security verification is performed on the code fragment and / or the database statement based on the semantic analysis results to obtain a first verification result; Based on the field name, field value, and field context of the configuration item, the target configuration item related to the target runtime environment is determined, and the target configuration item is configured and verified according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result; Based on the first verification result and the second verification result, the abnormal object, abnormal location and risk level are determined, and a reminder message corresponding to the abnormal object is generated and output.

[0007] Secondly, a code submission security verification and configuration reminder device is provided, including: The file acquisition module is used to acquire newly added or modified files to be verified in the code repository in response to code commit events. The files to be verified include configuration files, as well as at least one of code files and database script files. The content extraction module is used to identify the file category of the file to be verified and extract the content to be verified from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. The semantic verification module is used to perform semantic analysis on the code fragment and / or the database statement using a pre-trained code understanding model, obtain semantic analysis results, and perform security verification on the code fragment and / or the database statement based on the semantic analysis results to obtain a first verification result. The configuration verification module is used to determine the target configuration item related to the target runtime environment based on the field name, field value and field context of the configuration item, and to perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications and target runtime environment configuration template to obtain a second verification result; The reminder output module is used to determine the abnormal object, abnormal location and risk level based on the first verification result and the second verification result, generate reminder information corresponding to the abnormal object, and output the reminder information.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-mentioned code submission security verification and configuration reminder method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, it implements the steps of a code submission security verification and configuration reminder method.

[0010] The solution implemented by the above-mentioned code submission security verification and configuration reminder method, device, equipment, and medium can respond to code submission events to obtain newly added or modified files to be verified in the code repository. The files to be verified include at least one of configuration files, code files, and database script files. The files to be verified are then classified to extract the content to be verified, including at least one of configuration items, code snippets, and database statements. Subsequently, a pre-trained code understanding model is used to perform semantic analysis and security verification on the code snippets and / or database statements to obtain a first verification result. At the same time, the target configuration items related to the target runtime environment are determined based on the field names, field values, and field contexts of the configuration items. Configuration verification is then performed in conjunction with the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result. Finally, based on the first and second verification results, the abnormal object, abnormal location, and risk level are determined, and corresponding reminder information is generated and output. In this invention, the technical problems of the existing technology, such as the difficulty in consistently and comprehensively verifying code files, database script files, and configuration files during the code submission stage, and the difficulty in timely detecting semantic risks, configuration anomalies, and runtime environment compatibility issues, are addressed. By coordinating the extraction of content to be verified, semantic security verification, configuration verification, and the generation and output of reminder information, the code submission content can complete identification, verification, anomaly location, and risk warning in the same processing chain. This forms a closed loop of security verification and configuration reminder technology for code submission content, thereby reducing the possibility that security risks and configuration anomalies in the submission content will only be discovered in the subsequent build, deployment, or runtime stages, and enhancing the integrity of the code submission verification process, the reliability of configuration verification, and the accuracy of anomaly reminders.

[0011] The code submission security verification and configuration reminder method provided by this invention can solve the technical problems of existing code submission verification methods, which are difficult to perform consistent and comprehensive verification of multiple types of submission content and are difficult to identify configuration anomalies and security risks in a timely manner. It has the technical effect of improving the integrity of code submission content security verification, the reliability of configuration verification, and the accuracy of anomaly reminders, and can be widely used in business scenarios such as financial technology and healthcare.

[0012] These or other aspects of the invention will become more apparent from the following description of the embodiments. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating the code submission security verification and configuration reminder method in one embodiment of the present invention.

[0015] Figure 2 yes Figure 1 A schematic diagram of a specific implementation method for step S20.

[0016] Figure 3 yes Figure 2 A flowchart illustrating a specific implementation of step S23.

[0017] Figure 4 yes Figure 1 A schematic diagram of a specific implementation method for step S30.

[0018] Figure 5 yes Figure 1 A flowchart illustrating another specific implementation of step S30.

[0019] Figure 6 yes Figure 1 A flowchart illustrating another specific implementation of step S40.

[0020] Figure 7 yes Figure 1 A schematic diagram of a specific implementation method for step S50.

[0021] Figure 8 This is a schematic diagram of the structure of a code submission security verification and configuration reminder device in one embodiment of the present invention.

[0022] Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0023] 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, not all, of the embodiments of the present invention. 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.

[0024] The code submission security verification and configuration reminder method provided in this invention can be applied to code submission verification scenarios in software development processes. It is particularly suitable for the development and release environments of software systems with high requirements for data security and system stability, such as financial technology payment systems, transaction systems, and medical and health electronic medical record systems and remote consultation systems. The core execution entity of this method is the server, which can be a server or server cluster and can be deployed between the developer's terminal, code repository, configuration data storage system, and target runtime environment configuration resources. When a developer submits code to the code repository through the terminal, it retrieves newly added or modified files in the code repository and interacts with data resources such as project historical configurations, configuration specifications, and target runtime environment configuration templates to form a verification and reminder processing result for the code submission content. The developer's terminal is used to initiate code submissions and receive reminder information. The code repository is used to store configuration files, as well as at least one of code files and database script files. Related configuration data resources are used to provide comparison basis for configuration item verification. The server acts as the central node for the above data flow and verification processing, completing the security verification of code snippets and / or database statements, configuration item verification, and reminder information output.

[0025] Please see Figure 1 As shown, Figure 1 A flowchart illustrating the code submission security verification and configuration reminder method provided in this embodiment of the invention includes the following steps: S10: In response to a code commit event, retrieve newly added or modified files to be verified in the code repository. The files to be verified include configuration files, as well as at least one of code files and database script files.

[0026] Code commit events are events generated when a developer submits new or modified files to a code repository. A code repository can be used to store project files such as code files, database script files, and configuration files. Files to be verified refer to files that have been added or modified compared to their previous state in this commit, and these files include configuration files, as well as at least one of code files and database script files. Code files can include source files that implement the software's functional logic; database script files can include script files that describe database operations; and configuration files can include files that describe the system operating environment, connection parameters, port parameters, database connection information, etc.

[0027] Optionally, the list of newly added or modified files corresponding to this commit can be determined by listening to code commit events, receiving commit notifications from the code repository, or reading the commit history after code commit. The files to be verified can then be obtained based on this list. Taking a fintech payment system as an example, the files to be verified submitted by the developer may include payment interface-related code files and service connection configuration files, or database change script files and service connection configuration files. Taking a medical and health electronic medical record system as an example, the files to be verified may include medical record data access logic-related code files and service configuration files in the target runtime environment, or database table change script files and service configuration files in the target runtime environment. By obtaining the newly added or modified files to be verified during the code commit phase, subsequent verification processing can directly focus on the changes in this commit, avoiding redundant processing of irrelevant files and providing an input basis for subsequent content recognition, security verification, and configuration verification.

[0028] S20: Identify the file type of the file to be verified, and extract the content to be verified from the file to be verified according to the identified file type. The content to be verified includes configuration items, as well as at least one of code snippets and database statements.

[0029] The file category identification process determines the file category of the file to be verified. The file category can include configuration categories, as well as at least one of code and database script categories. The content to be verified refers to the content extracted from the file to be verified that needs to participate in subsequent verification processing. Configuration items are used for subsequent runtime environment compatibility verification, code snippets can be used for subsequent semantic analysis and security verification, and database statements can be used for subsequent semantic analysis, database operation risk identification, and security verification.

[0030] Optionally, files to be verified can be categorized based on their filename, file extension, file path, file content format, or key structural elements. For example, for files submitted in payment or transaction systems, runtime environment configuration files and service logic code or database scripts can be identified; for files submitted in electronic medical record or remote consultation systems, service addresses, ports, or database connection configuration files and business service code or database operation scripts can be identified. The file category identification results can serve as the basis for extracting the content to be verified, enabling the extraction of configuration items, code snippets, or database statements corresponding to different file categories. This allows at least one of the configuration items, code snippets, and database statements to be converted into input objects that can be processed by subsequent verification processes.

[0031] In one embodiment, see Figure 2 S20: Identify the file category of the file to be verified, and extract the content to be verified from the file according to the identified file category. This may include the following steps: S21: Obtain the file identifier information and file content information of the file to be verified.

[0032] File identification information can include information reflecting the file category, such as file name, file extension, file path, and file type identifier. File content information can include the text content, structured fields, script statements, configuration key-value pairs, etc. By obtaining both file identification and file content information simultaneously, the possibility of inaccurate category identification due to relying solely on file name or file extension can be reduced. For example, some database scripts may be saved as plain text files, and some configuration content may be embedded in general configuration files; therefore, combining file content identification helps improve the reliability of file category recognition.

[0033] S22: Determine at least one file category corresponding to the file to be verified based on at least one of the file identification information and file content information. The file category includes at least one of the configuration category, code category, and database script category.

[0034] Among them, the configuration category indicates that the file to be verified contains system operation configuration related content, the code category indicates that the file to be verified contains program logic related content, and the database script category indicates that the file to be verified contains database operation related content.

[0035] Optionally, the approximate category of a file can be determined based on file identification information, and the rationality of this category determination can be further verified based on the file content information. For example, when the file content contains paired field names and values, it can be determined that the file corresponds to a configuration category or contains configuration items; when the file content is program logic statements, it can be determined that the file corresponds to a code category or contains code snippets; when the file content contains database operation statements, it can be determined that the file corresponds to a database script category or contains database statements. The above classification process does not require that the same file to be verified can only correspond to a single file category; for files to be verified that simultaneously contain multiple contents such as code snippets, database statements, or configuration items, the corresponding content to be verified can be extracted separately.

[0036] S23: Extract the corresponding content to be verified from the file to be verified according to the file category. The corresponding content to be verified includes configuration items, as well as at least one of code snippets and database statements.

[0037] For files identified as configuration categories to be verified, configuration items can be extracted from them. Configuration items can include field names and field values. Field names characterize the type or meaning of the configuration item, while field values ​​characterize its specific configuration content. For example, configuration items can represent service addresses, ports, database connection information, key-related information, etc. Configuration items can be extracted based on the structured format, key-value pairs, or field context in the configuration file, allowing subsequent steps to identify the relevance to the target runtime environment based on the field names, values, and context of the configuration items.

[0038] For files identified as code to be verified, code snippets can be extracted. These snippets can be program statements, function snippets, method snippets, or logic blocks within the file that correspond to the new or modified content of the current submission. Code snippets can be extracted based on newly added or modified areas within the file, or the file can be fragmented according to its structure. The extracted code snippets can serve as input for subsequent semantic analysis and security verification to identify any context-dependent security or logical risks.

[0039] For files identified as database scripts, database statements can be extracted. These statements can include operations on database tables, fields, or data records. Complete database operation statements can be extracted from database script files, or corresponding statements can be extracted from submission files containing database operation content. The extracted database statements can serve as input for subsequent semantic analysis to determine their operation type, target, and potential execution risks.

[0040] Through the above processing, the corresponding content to be verified can be extracted after the file category is determined, so that at least one of the configuration items, code snippets and database statements can be converted into technical objects that can be processed by subsequent semantic security verification and configuration verification, thereby improving the consistency of the multi-type submission content processing chain.

[0041] In one embodiment, see Figure 3 S23: Extract the corresponding content to be verified from the file to be verified according to the file category, which may also include the following steps: S231: Determine the programming language type and / or development framework type corresponding to the file to be verified.

[0042] The programming language type indicates the programming language category used in the project to which the file to be verified belongs or the corresponding code content of the file to be verified. The development framework type indicates the software development framework category adapted to the project to which the file to be verified belongs or the configuration structure corresponding to the file to be verified. The server can determine the programming language type and / or development framework type of the file to be verified based on the file extension, file directory structure, file content syntax characteristics, or project configuration file. This step is used to adapt to the possible differences in file structure, code syntax, database script organization methods, and configuration item organization methods under different languages ​​and different frameworks.

[0043] S232: Determine the content extraction rules that match the file to be verified based on the programming language type and / or development framework type.

[0044] Content extraction rules instruct the server on what content to extract from the file to be verified and how to identify that content. For example, code snippets may have different boundaries in different programming languages, and configuration file paths, field naming conventions, database connection configurations, or database script organization methods may differ in different development frameworks. Therefore, the server can select the appropriate content extraction rules based on the programming language type and / or development framework type to extract structurally consistent content that can participate in subsequent verification processing from different types of software projects.

[0045] S233: Extract the corresponding content to be verified from the file to be verified according to the content extraction rules.

[0046] After extraction according to the content extraction rules, the server can obtain configuration items, as well as at least one of code snippets and database statements. The configuration items can be used for subsequent configuration verification related to the target runtime environment, while the code snippets and / or database statements can be used for subsequent semantic analysis and security verification.

[0047] Through the above processing, based on the determined file category, the corresponding content extraction rules can be selected by combining the programming language type and / or development framework type. This allows configuration items, code snippets, or database statements in different languages ​​and framework projects to be identified and extracted according to the matching extraction rules. This reduces the possibility of missing or incorrect extraction of the content to be verified due to differences in project structure, file organization, or configuration format, and provides a more reliable input basis for subsequent security verification and configuration verification.

[0048] S30: Use a pre-trained code understanding model to perform semantic analysis on code snippets and / or database statements, obtain semantic analysis results, and perform security verification on code snippets and / or database statements based on the semantic analysis results to obtain the first verification result.

[0049] In this context, the pre-trained code understanding model refers to a model capable of semantic representation, semantic recognition, or semantic understanding of code snippets or database statements. In this embodiment, the model's role is to perform semantic analysis on code snippets and / or database statements, rather than being limited to a specific model name, model structure, or training parameters. The model's input can be code snippets and / or database statements, and its output can be the semantic analysis results. The semantic analysis results can be used to characterize the operational semantics, associated objects, risk-related semantics, or contextual semantic information of the code snippets and / or database statements. The first verification result is a security verification result obtained based on the code snippets and / or database statements, which can be used to indicate whether there are security risks, execution risks, or logical risks.

[0050] Optionally, the code snippets and / or database statements extracted in the aforementioned steps can be converted into text input that the model can process, and a pre-trained code understanding model can perform semantic analysis on this text input. Taking a fintech transaction system as an example, code snippets may involve transaction status updates, account data access, or payment interface calls, while database statements may involve transaction record tables, account-related tables, or transaction status fields. Semantic analysis can identify the operational semantics, associated objects, or risk-related semantics within these snippets to subsequently determine whether there are potential security or execution risks. Taking a healthcare electronic medical record system as an example, code snippets may involve medical record data access logic or consultation service call logic, while database statements may involve medical record tables or consultation record tables. Semantic analysis can identify the data access semantics, operational objects, or contextual risk information corresponding to the code snippets and / or database statements to subsequently determine whether there are data leakage risks, operational anomaly risks, or inappropriate data operation risks. The above examples are only used to illustrate the input, output, and processing objectives of the code understanding model and do not involve the illegal processing of specific financial or medical data; related data processing should be based on authorized development, testing, or release processes.

[0051] In one embodiment, see Figure 4 S30: Perform security verification on code snippets and / or database statements based on semantic analysis results to obtain a first verification result, which may include the following steps: S31: Based on the semantic analysis results, perform semantic risk verification on the code snippets and / or database statements to obtain the semantic risk verification results.

[0052] Semantic analysis results can be used to characterize the operational semantics, associated objects, risk-related semantics, or contextual semantic information of code snippets and / or database statements. Semantic risk verification refers to determining whether code snippets and / or database statements contain potential risks related to their semantic meaning based on the semantic analysis results. Unlike matching based solely on keywords or fixed formats, semantic risk verification can make judgments by combining the actual operational meaning expressed by the code snippets or database statements.

[0053] Optionally, the semantic analysis results can be used to determine the operational intent, data access object, data processing method, or contextual relationship corresponding to the code snippet or database statement, and based on this information, determine whether there are potential semantic risks. For example, in the software submission scenario of a fintech transaction system, the code snippet may involve transaction status updates, account data access, or payment interface calls; the semantic analysis results can be used to determine whether there are risks of inappropriate data access or status modification. In the software submission scenario of a medical and health electronic medical record system, the code snippet may involve medical record data access logic or consultation service call logic; the semantic analysis results can be used to determine whether there are risks of inappropriate data access or operational anomalies. The semantic risk verification results can be used to indicate whether there are semantic-level security risks in the code snippet and / or database statement, and serve as one of the bases for generating the first verification result.

[0054] S32: Perform syntax validation on code snippets and / or database statements, and obtain the syntax validation results.

[0055] Syntax validation is used to determine whether code snippets and / or database statements conform to the basic syntax rules of the corresponding programming language, scripting language, or database statement. The syntax validation result can be used to indicate whether the content to be validated contains syntax errors, abnormal statement structure, or does not conform to preset syntax constraints.

[0056] Optionally, syntax checks can be performed on code snippets and / or database statements based on the programming language type corresponding to the code snippet, the script type corresponding to the database statement, or the content extraction rules of the file to be verified. For example, for code snippets, the completeness of their statement structure, call structure, or code block structure can be checked; for database statements, the corresponding syntax requirements can be checked for their statement structure, description of the operand, or statement end marker. Through syntax verification, anomalies at the basic syntax level can be identified first, providing basic verification information for subsequent rule verification, logic verification, and the generation of the first verification result.

[0057] S33: Perform rule validation on code snippets and / or database statements according to preset validation rules, and obtain the rule validation results.

[0058] The preset verification rules can be pre-set verification rules for code submission security requirements, database statement usage requirements, or project security specifications. Rule verification is used to determine whether code snippets and / or database statements meet preset security constraints or specification constraints. Preset verification rules may include rules set for known risk patterns, prohibited operation patterns, non-standard syntax, or specific security requirements, but this embodiment does not limit the specific number of rules, rule format, or rule parameters.

[0059] Optionally, code snippets and / or database statements can be matched against preset validation rules to determine if any rule-matching anomalies exist. For example, for code snippets, rule validation can be used to determine if they contain access methods or call methods that do not comply with project security specifications; for database statements, rule validation can be used to determine if they contain statement forms or operation patterns that do not comply with database operation specifications. The rule validation results can be used to indicate whether the code snippets and / or database statements match preset validation rules, and the type of rule match or anomaly. Through rule validation, known security patterns can be incorporated into the generation process of the first validation result.

[0060] S34: Perform logical verification based on the context information of the code snippet and / or database statement to determine whether the code snippet and / or database statement have the risk of data leakage and / or the risk of runtime exception caused by executing the code snippet and / or database statement, and obtain the logical verification result.

[0061] The context information can include adjacent code within the file to be verified, the function or code block it belongs to, related call relationships, the script segment containing the database statement, related configuration items, or other content to be verified in the same code commit event. Logical verification is used to determine, in conjunction with the context information, whether the code segment and / or database statement may pose a risk of data leakage or operational anomalies in a specific usage environment.

[0062] Optionally, the context information of code snippets or database statements can be combined to determine whether there are any anomalies in the operation objects, calling relationships, data access paths, or execution logic. For example, in the software submission scenario of a fintech payment system, if a code snippet involves reading, transmitting, or outputting transaction data in the context, the context information can be used to determine whether there is a risk of data leakage; if a database statement in the context may affect the normal access to the transaction status table or account-related tables, the execution of the database statement can be used to determine whether there is a risk of runtime anomalies caused by the execution of the database statement. In the software submission scenario of a medical and health electronic medical record system, if a code snippet or database statement involves access to electronic medical record data, querying consultation records, or calling services in the context, the data leakage risk or runtime anomaly risk can be determined. The above processing is only used for security verification of the submitted software content and does not involve value judgments, discriminatory classifications, or illegal data processing of individuals, patients, transaction entities, or other natural persons.

[0063] Logical validation results can be used to indicate whether code snippets and / or database statements pose risks of data leakage, runtime anomalies, or other logical risks within a given context. By incorporating contextual information into logical validation, the limitations of relying solely on syntax or rule-based validation in identifying contextual risks can be overcome.

[0064] S35: Generate the first verification result based on the semantic risk verification result, syntax verification result, rule verification result, and logic verification result.

[0065] Optionally, the semantic risk verification results, syntax verification results, rule verification results, and logic verification results can be aggregated to generate a first verification result. The first verification result may include whether there are anomalies in the code snippets and / or database statements, the type of anomaly, the source of the anomaly, risk-related information, or intermediate results used for generating subsequent alerts. The verification information to be recorded in the first verification result can be determined based on whether any anomalies exist in each verification result, and the type or risk level of the anomaly.

[0066] Through the above steps S31 to S35, this embodiment of the invention can combine semantic risk verification, syntax verification, rule verification, and contextual logic verification. This allows the security verification of code snippets and / or database statements to go beyond simple syntax checking or rule matching, and instead comprehensively consider semantic information, rule constraints, and contextual relationships to form a first verification result. This enhances the ability to identify semantic risks, data leakage risks, and runtime anomaly risks in submitted code, and provides a reliable basis for subsequently determining the anomaly object, anomaly location, and risk level based on the first and second verification results.

[0067] In one embodiment, see Figure 5S30: Perform security verification on the database statements based on the semantic analysis results to obtain the first verification result, which may include the following steps: S36: Based on the semantic analysis results, determine the operation type and operation object corresponding to the database statement.

[0068] The operation type characterizes the category of operation performed by a database statement on a database object, while the operation object characterizes the database table, field, or data record that the database statement affects. Semantic analysis results can include the operation semantics of the database statement, information about the affected object, and semantic information related to execution risk.

[0069] Optionally, the semantic analysis results output by the pre-trained code understanding model can be used to determine the operation type and target of the database statement. For example, in the software submission scenario of a fintech transaction system, the target of the database statement could be a transaction record table, an account-related table, or a transaction status field; in the software submission scenario of a healthcare electronic medical record system, the target of the database statement could be a medical record table or a consultation record table. By determining the operation type and target, a data foundation can be provided for subsequent judgments on whether the database statement involves sensitive operations and for assessing its execution risk.

[0070] S37: Determine whether the database statement involves sensitive operations based on the operation type and the operation object. Sensitive operations include at least one of the following: data deletion operation, data truncation operation, and table structure modification operation.

[0071] Sensitive operations refer to database operations that may affect data integrity, data availability, or database structure stability. Data deletion operations correspond to deleting database records, data truncation operations correspond to batch clearing of data content, and table structure modification operations correspond to modifying the database table structure, field structure, or related structure definitions. The above sensitive operation types are only used to characterize the risk category of database statements and do not limit the specific form of the database statements.

[0072] Optionally, the database statement's operation type can be used to determine whether it involves data deletion, data truncation, or table structure modification. Furthermore, the operation's target can be considered to determine if it affects database objects requiring close monitoring within the target operating environment. For example, if the database statement's operation type indicates data deletion, and the target is a transaction record table or a medical record table, then the statement is considered to involve a sensitive operation. This step helps filter out operations in the database statements that may affect data security or system stability, providing a basis for determining subsequent execution risk information.

[0073] S38: In response to a database statement involving a sensitive operation, determine the execution risk information corresponding to the database statement based on the execution permission information and the operation object of the database statement in the target runtime environment.

[0074] The target runtime environment can be the runtime environment that the file to be verified is expected to adapt to or may be affected by. Execution permission information is used to characterize whether the database statement has execution permissions, execution conditions, or execution restrictions in the target runtime environment. Execution risk information is used to characterize the potential risks that may arise after the database statement is executed in the target runtime environment.

[0075] Optionally, after determining that a database statement involves sensitive operations, the execution risk information can be further determined by combining the execution permission information and the operation object of the database statement in the target operating environment. For example, if a database statement involves deleting data from a transaction record table and has execution permissions in the target operating environment, then the database statement can be determined to have a high execution risk; if a database statement involves modifying the table structure of electronic medical record related data tables and the database statement can be executed in the target operating environment, then it can be determined that it may have an execution risk affecting data access or service operation. The above processing is only used for security verification of database statements and does not involve evaluation, classification, or decision-making regarding specific users, patients, or transaction entities.

[0076] S39: Generate the first verification result based on the judgment result of the sensitive operation and the execution risk information.

[0077] Optionally, a first verification result can be generated based on the judgment result of whether the database statement involves sensitive operations, and the execution risk information determined when the database statement involves sensitive operations. The first verification result can be used to characterize whether the database statement contains sensitive operations, whether it has execution risks, and the corresponding risk-related information.

[0078] For example, when a database statement does not involve sensitive operations, a first verification result indicating that no sensitive operation risk has been identified can be generated based on the judgment result of sensitive operations. When a database statement involves sensitive operations, a first verification result indicating that there is an execution risk or that a warning is required can be generated by further combining execution risk information. Through the above S36 to S39, this embodiment can continuously judge the operation type, operation object, sensitive operation, and execution risk of the database statement based on the semantic analysis results, so that potential execution risks in the database script can be identified at the code submission stage, thereby providing a basis for subsequently determining abnormal objects, abnormal locations, risk levels, and generating warning information.

[0079] Through S36 to S39 described above, this embodiment of the invention can determine the operation type and operation object of a database statement based on semantic analysis results. Furthermore, it combines the results of sensitive operation judgment with execution permission information in the target runtime environment to determine execution risk information. This allows the security verification of database statements to not only rely on the textual form of the statement but also to consider the actual operational meaning of the database statement, its target object, and its executability in the target runtime environment. Therefore, it can improve the ability to identify potential execution risks in database scripts, reduce the possibility that sensitive or high-risk operations in database statements will only be discovered during subsequent construction, deployment, or runtime phases, and provide more accurate verification basis for subsequent anomaly location, risk level determination, and alert information generation.

[0080] It should be noted that, Figure 4 The illustrated embodiments are primarily used to explain the multi-dimensional security verification process for code snippets and / or database statements. Figure 5 The embodiments shown are mainly used to illustrate the special risk verification process for database statements when the content to be verified includes database statements; both are specific implementations of obtaining the first verification result in S30, and can be executed individually or in combination according to the type of content to be verified and verification requirements. The embodiments of the present invention do not limit this.

[0081] S40: Based on the field name, field value, and field context of the configuration item, determine the target configuration item related to the target runtime environment, and perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain the second verification result.

[0082] Configuration items can be fields extracted from configuration files that describe system operating parameters, connection parameters, or environment parameters. Field names can characterize the type or meaning of a configuration item, field values ​​can characterize the specific configuration content of the configuration item, and field context can characterize the location of the configuration item in the configuration file, its associated configuration section, adjacent fields, or environment identifier information. The target operating environment can be the operating environment that the file to be verified is expected to adapt to or may affect. Target configuration items refer to configuration items related to the target operating environment that require configuration verification. The second verification result can be used to characterize whether the target configuration item has configuration anomalies, environment adaptation anomalies, or configuration specification mismatches.

[0083] Optionally, the configuration type can be identified based on the field name of the configuration item, the specific configuration content can be identified based on the field value, and the relevant context can be used to determine whether the configuration item is related to the target runtime environment. For example, in the software submission scenario of a fintech payment system or transaction system, configuration items may involve runtime parameters such as service address, port, and database connection information; in the software submission scenario of a medical and health electronic medical record system or remote consultation system, configuration items may involve runtime parameters such as business service address, database connection configuration, or service call configuration. Target configuration items related to the target runtime environment can be compared with the project's historical configurations, configuration specifications, and target runtime environment configuration templates to determine whether the configuration item meets the configuration requirements of the target runtime environment. This step can identify mismatches between configuration items and the target runtime environment during the code submission phase, providing a basis for configuration verification for subsequent generation of reminder information.

[0084] In one embodiment, see Figure 6 S40: Based on the field name, field value, and field context of the configuration item, determine the target configuration item related to the target runtime environment, and perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result. This may include the following steps: S41: Determine the configuration type corresponding to the configuration item based on the field name of the configuration item.

[0085] The configuration type is used to characterize the category of the configuration object to which the configuration item belongs. The field name can be a name used in the configuration file to represent the meaning of the configuration item, such as information about the service address, port, database name, database connection information, key-related information, or other runtime parameters.

[0086] Optionally, the configuration type corresponding to a configuration item can be determined based on the semantics represented by the field name. For example, when the field name represents a service access address, the configuration item can be identified as an address configuration type; when the field name represents a port, the configuration item can be identified as a port configuration type; and when the field name represents database connection information, the configuration item can be identified as a database connection configuration type. By determining the configuration type, a basis can be provided for subsequently selecting the appropriate comparison criteria based on different configuration objects.

[0087] S42: Determine the configuration content corresponding to the configuration item based on the field value of the configuration item.

[0088] The configuration content refers to the actual configuration values ​​recorded in the current commit file. Field values ​​can be used to represent specific addresses, port values, database connection strings, database names, key-related field values, or other runtime parameter values.

[0089] Optionally, the field values ​​of configuration items can be read, and the corresponding configuration content can be determined based on the field values. For example, for address configuration types, the configuration content can be a specific service address; for port configuration types, the configuration content can be a specific port value; for database connection configuration types, the configuration content can be database connection parameters. The configuration content is the primary object for subsequent comparison with historical project configurations, configuration specifications, and target runtime environment configuration templates. By determining the configuration content, configuration validation can go beyond simply identifying field names and further determine whether specific configuration values ​​meet the requirements of the target runtime environment.

[0090] S43: Determine the runtime environment attributes corresponding to the configuration item based on its context location in the configuration file.

[0091] The context location can include the file path where the configuration item is located, the configuration section, the hierarchical structure, adjacent fields, the environment identifier, or the associated location with other configuration items. The runtime environment attribute is used to characterize the environment type or environment relationship corresponding to this configuration item, such as development environment, testing environment, pre-release environment, or target runtime environment.

[0092] Optionally, the context of the configuration item within the configuration file can be used to determine whether it belongs to the target runtime environment. For example, a configuration file may contain configuration sections corresponding to multiple environments; the runtime environment attribute can be determined based on the configuration section where the configuration item is located or the identifier of an adjacent environment. By combining contextual location to determine the runtime environment attribute, misjudgments caused by configuration validation based solely on field names or values ​​can be avoided, making subsequent identification of target configuration items more consistent with the actual organizational structure of the configuration file.

[0093] S44: Determine the target configuration item based on the configuration type, configuration content, and runtime environment attributes.

[0094] Among them, the target configuration item is the configuration item that needs to participate in the target runtime environment configuration verification. The server can comprehensively consider the configuration type, configuration content, and runtime environment attributes to determine whether the configuration item is related to the target runtime environment, and identify the configuration item that is related to the target runtime environment as the target configuration item.

[0095] Optionally, if a configuration item's configuration type is related to the runtime environment, its configuration content is actual runtime parameters, and its runtime environment attribute points to the target runtime environment, then this configuration item can be identified as the target configuration item. For example, database connection configuration, service address configuration, or port configuration in the target runtime environment can all be used as target configuration items in the subsequent configuration verification process. This step allows for the selection of configuration items that need to participate in the target runtime environment verification from the extracted configuration items, reducing the interference of irrelevant configuration items on the verification results.

[0096] S45: Compare the target configuration item with the project's historical configuration, configuration specifications, and target runtime environment configuration template respectively to obtain the historical configuration comparison results, specification comparison results, and template comparison results.

[0097] Among them, project history configuration can be used to represent the configuration content maintained during the project's historical versions, historical commits, or historical operations; configuration specifications can be used to represent the project's or team's preset configuration requirements; and target runtime environment configuration templates can be used to represent the recommended, permitted, or required configuration structure and content for the target runtime environment. Historical configuration comparison results, specification comparison results, and template comparison results are used to represent the matching status between the target configuration items and different configuration bases.

[0098] Optionally, the field names, field values, configuration types, configuration content, and runtime environment attributes of the target configuration item can be compared with the project's historical configurations, configuration specifications, and the target runtime environment configuration template, respectively. For example, it can be determined whether the target configuration item is consistent with the target runtime environment configuration in a historical version, whether it meets the requirements of the configuration specification regarding field format, configuration scope, or configuration structure, and whether it conforms to the configuration requirements in the target runtime environment configuration template. By generating historical configuration comparison results, specification comparison results, and template comparison results separately, it is possible to determine whether there are any anomalies in the target configuration item from multiple configuration criteria dimensions.

[0099] S46: Based on the historical configuration comparison results, standard comparison results, and template comparison results, determine whether there are any configuration anomalies in the target configuration item, and generate a second verification result.

[0100] Configuration anomalies can include inconsistencies between the target configuration item and the project's historical configuration, mismatches with configuration specifications, inconsistencies with the target runtime environment's configuration template, or mismatches between configuration content and runtime environment attributes. The second verification result can be used to characterize whether the target configuration item has configuration anomalies, the type of anomaly, the source of the anomaly, or configuration risk information required for subsequent alerts.

[0101] Optionally, a comprehensive judgment can be made based on historical configuration comparison results, specification comparison results, and template comparison results to determine whether the target configuration item has configuration anomalies. For example, when the field value of the target configuration item is inconsistent with the target runtime environment configuration template, or when the configuration content does not match its runtime environment attributes, it can be determined that the target configuration item has configuration anomalies, and a corresponding second verification result can be generated.

[0102] Through the above steps S41 to S46, the embodiments of the present invention can identify target configuration items related to the target operating environment based on field name, field value and field context, and perform multi-dimensional comparisons by combining project historical configuration, configuration specifications and target operating environment configuration templates, thereby improving the reliability of configuration item environment adaptability verification, reducing the possibility that configuration anomalies will only be discovered in the subsequent construction, deployment or operation stages, and providing configuration verification basis for subsequent anomaly object identification and reminder information generation.

[0103] S50: Based on the first and second verification results, determine the abnormal object, abnormal location, and risk level, generate the corresponding reminder information for the abnormal object, and output the reminder information.

[0104] The first verification result can be used to characterize the security verification status of code snippets and / or database statements, while the second verification result can be used to characterize the configuration verification status of configuration items. An anomaly object refers to a code snippet, database statement, and / or configuration item that is found to be abnormal based on the first and second verification results. The anomaly location characterizes the position of the anomaly object within the file to be verified. The risk level characterizes the degree of risk corresponding to the anomaly object. The alert information is used to feed back the anomaly object, anomaly location, risk level, and preset remediation suggestions to the developer's terminal or relevant processing nodes in the code submission process.

[0105] Optionally, the first and second verification results can be summarized to identify objects with anomalies. A reminder message can then be generated by combining the location of the anomaly object in the file to be verified, the anomaly type, the risk level, and preset remediation suggestions. The reminder message can be output through an interface with information output functionality, system messages, submission comments, or other compliant notification methods. This embodiment does not limit the specific third-party tools or platforms. Through this step, the aforementioned security verification results and configuration verification results can be transformed into location-based, promptable, and processable output information, enabling security risks or configuration anomalies in the submitted content to be reported during the code submission stage.

[0106] In one embodiment, see Figure 7 S50: Based on the first and second verification results, determine the abnormal object, abnormal location, and risk level, generate and output the alert information corresponding to the abnormal object, which may include the following steps: S51: Based on the first and second verification results, identify the code segments, database statements, and / or configuration items that contain exceptions as exception objects.

[0107] The exception object can originate from the code snippet and / or database statement corresponding to the first verification result, or from the configuration item corresponding to the second verification result. The first verification result can indicate whether the code snippet or database statement has semantic risks, syntax exceptions, rule exceptions, logical risks, or execution risks; the second verification result can indicate whether the configuration item has configuration exceptions or runtime environment adaptation exceptions.

[0108] Optionally, the exception identifier, exception type, or risk information in the first and second verification results can be read respectively, and the code snippets, database statements, and / or configuration items containing exceptions can be identified as exception objects. For example, if the first verification result indicates that a database statement has an execution risk, then that database statement can be considered an exception object; if the second verification result indicates that a configuration item is inconsistent with the target runtime environment configuration template, then that configuration item can be considered an exception object. By identifying the exception objects, the specific objects to be processed corresponding to subsequent alert information can be clearly defined.

[0109] S52: Determine the location of the abnormal object in the file to be verified.

[0110] The exception location indicates the specific position of the exception object within the file to be verified. The exception location can include file path, file name, line position, field position, statement position, or configuration item position, etc.

[0111] Optionally, the abnormal location of the abnormal object in the file to be verified can be determined based on the file source information, line number information, field position information, or script position information recorded during the extraction process of the content to be verified. For example, for a code snippet, its file path and line position can be determined; for a database statement, its script file and statement position can be determined; for a configuration item, its configuration file, configuration section, and field position can be determined. By determining the abnormal location, the alert message can be directed to the specific file location, facilitating subsequent location and handling of the abnormal object.

[0112] S53: Determine the risk level of the abnormal object based on the abnormal type and the verification result.

[0113] The exception type can be used to characterize the problem category corresponding to the exception object, such as code semantic risk, database statement execution risk, configuration exception, or runtime environment adaptation exception. The verification result can include specific risk information, exception identifier, or comparison result corresponding to the exception object from the first and second verification results. The risk level is used to characterize the severity of the risk corresponding to the exception object.

[0114] Optionally, the risk level of an abnormal object can be determined based on the abnormal type, risk information in the verification results, and preset risk grading rules. For example, if a database statement involves sensitive operations and has execution permissions in the target runtime environment, its risk level can be determined to be high; if a configuration item is inconsistent with the target runtime environment configuration template, the corresponding risk level can be determined based on the configuration type and content of the configuration item. This embodiment does not limit the specific number, name, or threshold of risk levels. By determining the risk level, the alert information can have risk differentiation capabilities, facilitating subsequent processing based on the degree of risk.

[0115] S54: Generate and output reminder information based on the abnormal object, abnormal location, risk level, and preset repair suggestions.

[0116] The preset repair suggestions can be pre-configured prompts or templates, used to prompt the submitter to check, modify, or confirm the abnormal object. Different preset repair suggestions can correspond to different anomaly types, risk levels, or verification results. The reminder information can include at least one of the following: abnormal object, anomaly location, risk level, and preset repair suggestions; it can also include the anomaly type or corresponding verification result.

[0117] Optionally, the abnormal object, abnormal location, risk level, and remediation suggestions can be combined to generate an alert message, which can then be output to the developer's terminal or the relevant processing node in the code submission process. For example, for database statements with execution risks, the alert message can indicate the script location, risk level, and the object or execution permission that needs to be verified; for configuration items with configuration anomalies, the alert message can indicate the configuration file location, anomaly type, and the target runtime environment configuration that needs to be verified. By generating and outputting alert messages, the aforementioned first and second verification results can be transformed into location-accurate, understandable, and processable feedback information, thereby improving the timeliness and accuracy of exception handling during the code submission phase.

[0118] Through steps S51 to S54 described above, this embodiment of the invention can uniformly transform the verification results of code snippets, database statements, and configuration items into alert information including the exception object, exception location, risk level, and preset repair suggestions, ensuring that security verification results and configuration verification results are output in the same alert chain. This enhances the traceability of code submission verification results and the relevance of alert information, reducing the likelihood that security vulnerabilities or configuration anomalies will only be discovered during subsequent build, deployment, or runtime phases.

[0119] The code submission security verification and configuration alert method provided in this embodiment of the invention, through the above-described steps S10 to S50, can obtain the newly added or modified file to be verified in the code repository after a code submission event occurs, and extract at least one of the following from the file: configuration items, code snippets, and database statements. Then, semantic analysis and security verification are performed on the code snippets and / or database statements to obtain a first verification result, and configuration verification is performed on the target configuration items related to the target runtime environment to obtain a second verification result. Finally, based on the first and second verification results, the abnormal object, abnormal location, and risk level are determined, and alert information corresponding to the abnormal object is generated and output. Thus, a continuous data processing link can be formed between the acquisition of the file to be verified, the extraction of the content to be verified, security verification, configuration verification, and alert information output. This allows code snippets, database statements, and configuration items to be processed in the same code submission verification process, thereby solving the technical problems of existing code submission verification methods that are difficult to perform consistent and comprehensive verification of multiple types of submission content and difficult to identify configuration anomalies and security risks in a timely manner. This method has the technical effect of improving the integrity of code submission content security verification, the reliability of configuration verification, and the accuracy of anomaly alerts.

[0120] In one embodiment, after outputting the alert message, feedback optimization data can be obtained, and the code understanding model and / or verification strategy can be optimized based on the feedback optimization data. The feedback optimization data can include at least one of the following: feedback results generated in response to the alert message, manual review comments, and historical security event data. Feedback results can be the modification results, confirmation results, or processing results made by the developer or relevant processing entity in response to the alert message; manual review comments can be review comments generated by reviewers based on the alert message, submitted content, or processing results; historical security event data can be records of security events related to code submissions, database scripts, configuration anomalies, or operational risks in the past.

[0121] Optionally, the system can determine whether the alert information has been confirmed, modified, or excluded based on the feedback results, correct false alarms or omissions in the verification strategy based on manual review comments, and adjust the risk types or configuration anomaly types that the verification strategy focuses on based on historical security event data. For the code understanding model, the feedback optimization data can be used in the model optimization process, making the semantic analysis results of subsequent code snippets or database statements more consistent with the actual risk characteristics of the project. For the verification strategy, the preset verification rules, configuration comparison criteria, or risk level determination logic can be updated based on the feedback optimization data. Through this optional implementation method, without changing the main process of code submission security verification and configuration alerts, the verification model or verification strategy can be continuously optimized based on feedback data, thereby further reducing the possibility of repeated false alarms or omissions.

[0122] If the feedback optimization data involves personal information, business data, financial data, or medical and health-related data, it should be processed within the authorized scope, and can be anonymized, minimized, or subject to access control as needed to avoid illegal collection, illegal use, or improper processing of sensitive information.

[0123] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0124] In one embodiment, a code submission security verification and configuration reminder device is provided, which corresponds one-to-one with the code submission security verification and configuration reminder method in the above embodiments. For example... Figure 8 As shown, the code submission security verification and configuration reminder device includes a file acquisition module 101, a content extraction module 102, a semantic verification module 103, a configuration verification module 104, and a reminder output module 105. Detailed descriptions of each functional module are as follows: The file acquisition module 101 is used to acquire newly added or modified files to be verified in the code repository in response to code commit events. The files to be verified include configuration files, as well as at least one of code files and database script files. The content extraction module 102 is used to identify the file category of the file to be verified and extract the content to be verified from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. The semantic verification module 103 is used to perform semantic analysis on code snippets and / or database statements using a pre-trained code understanding model, obtain semantic analysis results, and perform security verification on code snippets and / or database statements based on the semantic analysis results to obtain a first verification result; the configuration verification module 104 is used to determine the target configuration items related to the target runtime environment based on the field name, field value, and field context of the configuration items, and perform configuration verification on the target configuration items based on the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result; The reminder output module 105 is used to determine the abnormal object, abnormal location and risk level based on the first verification result and the second verification result, and generate reminder information corresponding to the abnormal object and output the reminder information.

[0125] In one embodiment, the content extraction module 102 is specifically used for: Obtain the file identifier and file content information of the file to be verified; Based on at least one of the file identification information and file content information, determine at least one file category corresponding to the file to be verified. The file category includes at least one of the configuration category, code category, and database script category. According to the file category, extract the corresponding content to be verified from the file to be verified. The corresponding content to be verified includes configuration items, as well as at least one of code snippets and database statements.

[0126] In one embodiment, the content extraction module 102 is further configured to: Determine the programming language type and / or development framework type corresponding to the file to be verified; Determine the content extraction rules that match the file to be verified based on the programming language type and / or development framework type; According to the content extraction rules, extract the corresponding content to be verified from the file to be verified.

[0127] In one embodiment, the semantic verification module 103 is specifically used for: Based on the semantic analysis results, semantic risk verification is performed on code snippets and / or database statements to obtain semantic risk verification results. Perform syntax validation on code snippets and / or database statements, and obtain the syntax validation results; The code snippets and / or database statements are validated according to preset validation rules to obtain the validation results. Logical verification is performed based on the context information of code snippets and / or database statements to determine whether there is a risk of data leakage and / or a risk of runtime anomalies caused by executing code snippets and / or database statements, and the logical verification results are obtained. The first verification result is generated based on the semantic risk verification result, the syntax verification result, the rule verification result, and the logic verification result.

[0128] In one embodiment, the semantic verification module 103 is specifically used for: Based on the semantic analysis results, determine the operation type and operation object corresponding to the database statement; Based on the operation type and the operation object, determine whether the database statement involves sensitive operations. Sensitive operations include at least one of the following: data deletion operation, data truncation operation, and table structure modification operation. In response to database statements involving sensitive operations, the execution risk information corresponding to the database statements is determined based on the execution permission information and the operation objects of the database statements in the target runtime environment. Based on the judgment results of sensitive operations and the execution risk information, the first verification result is generated.

[0129] In one embodiment, the configuration verification module 104 is specifically used for: The configuration type corresponding to the configuration item is determined by the field name of the configuration item; The configuration content corresponding to the configuration item is determined based on the field value of the configuration item; The runtime environment properties corresponding to the configuration item are determined based on the context location of the configuration item in the configuration file; The target configuration item is determined based on the configuration type, configuration content, and runtime environment attributes; The target configuration item is compared with the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain the historical configuration comparison results, specification comparison results, and template comparison results. Based on the historical configuration comparison results, standard comparison results, and template comparison results, determine whether there are any configuration anomalies in the target configuration item, and generate a second verification result.

[0130] In one embodiment, the reminder output module 105 is specifically used for: Based on the first and second verification results, the code snippets, database statements, and / or configuration items containing anomalies are identified as anomaly objects. Determine the location of the abnormal object in the file to be verified; The risk level of the abnormal object is determined based on the abnormal type and the verification result. Based on the abnormal object, abnormal location, risk level, and preset repair suggestions, generate and output reminder information.

[0131] The code submission security verification and configuration reminder device provided in this embodiment of the invention responds to code submission events through a file acquisition module, acquiring a file to be verified that includes at least one of configuration files, code files, and database script files; a content extraction module identifies the file category of the file to be verified and extracts content to be verified that includes at least one of configuration items, code snippets, and database statements; a semantic verification module performs semantic analysis and security verification on the code snippets and / or database statements to obtain a first verification result; a configuration verification module determines the target configuration item based on the field name, field value, and field context of the configuration item, and performs configuration verification in conjunction with the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result; and a reminder output module determines the abnormal object, abnormal location, and risk level based on the first and second verification results, and generates and outputs reminder information. Therefore, the device can form a complete processing chain from code submission content acquisition, content extraction to be verified, security verification, configuration verification to reminder information output, enabling code snippets, database statements and configuration items to be processed together in the same code submission verification process. This improves the completeness of code submission content security verification, the reliability of configuration verification and the accuracy of anomaly reminders, and reduces the possibility that security risks or configuration anomalies will only be discovered in the subsequent build, deployment or operation phases.

[0132] Specific limitations regarding the code submission security verification and configuration alert device can be found in the limitations of the code submission security verification and configuration alert method described above, and will not be repeated here. Each module in the aforementioned code submission security verification and configuration alert device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0133] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the function or steps of a code submission security verification and configuration alert method.

[0134] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: In response to a code commit event, retrieve newly added or modified files to be verified in the code repository. The files to be verified include configuration files, as well as at least one of code files and database script files. The file to be verified is identified by file category, and the content to be verified is extracted from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. A pre-trained code understanding model is used to perform semantic analysis on code snippets and / or database statements to obtain semantic analysis results. Based on the semantic analysis results, security verification is performed on the code snippets and / or database statements to obtain the first verification result. Based on the field name, field value, and field context of the configuration item, determine the target configuration item related to the target runtime environment, and perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain the second verification result; Based on the first and second verification results, the abnormal object, abnormal location, and risk level are determined, and a reminder message corresponding to the abnormal object is generated and output.

[0135] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: In response to a code commit event, retrieve newly added or modified files to be verified in the code repository. The files to be verified include configuration files, as well as at least one of code files and database script files. The file to be verified is identified by file category, and the content to be verified is extracted from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. A pre-trained code understanding model is used to perform semantic analysis on code snippets and / or database statements to obtain semantic analysis results. Based on the semantic analysis results, security verification is performed on the code snippets and / or database statements to obtain the first verification result. Based on the field name, field value, and field context of the configuration item, determine the target configuration item related to the target runtime environment, and perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain the second verification result; Based on the first and second verification results, the abnormal object, abnormal location, and risk level are determined, and a reminder message corresponding to the abnormal object is generated and output.

[0136] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0137] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0138] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0139] 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.

[0140] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for code submission security verification and configuration reminders, characterized in that, include: In response to a code commit event, retrieve newly added or modified files to be verified in the code repository. The files to be verified include configuration files, as well as at least one of code files and database script files. The file to be verified is identified by file category, and the content to be verified is extracted from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. A pre-trained code understanding model is used to perform semantic analysis on the code fragment and / or the database statement to obtain semantic analysis results, and security verification is performed on the code fragment and / or the database statement based on the semantic analysis results to obtain a first verification result; Based on the field name, field value, and field context of the configuration item, the target configuration item related to the target runtime environment is determined, and the target configuration item is configured and verified according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result; Based on the first verification result and the second verification result, the abnormal object, abnormal location and risk level are determined, and a reminder message corresponding to the abnormal object is generated and output.

2. The method of claim 1, wherein, The step of identifying the file category of the file to be verified and extracting the content to be verified from the file according to the identified file category includes: Obtain the file identifier information and file content information of the file to be verified; Based on at least one of the file identification information and the file content information, determine at least one file category corresponding to the file to be verified, wherein the file category includes at least one of the configuration category, code category, and database script category; According to the file category, the corresponding content to be verified is extracted from the file to be verified, wherein the corresponding content to be verified includes configuration items, as well as at least one of code snippets and database statements.

3. The method of claim 2, wherein, The step of extracting the corresponding content to be verified from the file to be verified according to the file category includes: Determine the programming language type and / or development framework type corresponding to the file to be verified; Based on the programming language type and / or the development framework type, determine the content extraction rules that match the file to be verified; According to the content extraction rules, the corresponding content to be verified is extracted from the file to be verified.

4. The method of claim 1, wherein, The step of performing security verification on the code fragment and / or the database statement based on the semantic analysis result to obtain a first verification result includes: Based on the semantic analysis results, semantic risk verification is performed on the code fragment and / or the database statement to obtain the semantic risk verification results. Perform syntax validation on the code snippet and / or the database statement to obtain the syntax validation result; The code fragment and / or the database statement are validated according to preset validation rules to obtain the validation results. Logical verification is performed based on the context information of the code snippet and / or the database statement to determine whether the code snippet and / or the database statement pose a risk of data leakage and / or a risk of runtime anomalies caused by executing the code snippet and / or the database statement, and the logical verification result is obtained. The first verification result is generated based on the semantic risk verification result, the syntax verification result, the rule verification result, and the logic verification result.

5. The method of claim 1, wherein, The step of performing security verification on the database statement based on the semantic analysis result to obtain a first verification result includes: Based on the semantic analysis results, the operation type and operation object corresponding to the database statement are determined; Based on the operation type and the operation object, it is determined whether the database statement involves a sensitive operation, which includes at least one of data deletion operation, data truncation operation and table structure modification operation; In response to the database statement involving a sensitive operation, the execution risk information corresponding to the database statement is determined based on the execution permission information of the database statement in the target runtime environment and the operation object; The first verification result is generated based on the judgment result of the sensitive operation and the execution risk information.

6. The method of claim 1, wherein, The step involves determining the target configuration item related to the target runtime environment based on the field name, field value, and field context of the configuration item, and performing configuration verification on the target configuration item according to the project's historical configuration, configuration specifications, and target runtime environment configuration template to obtain a second verification result, including: The configuration type corresponding to the configuration item is determined based on the field name of the configuration item; The configuration content corresponding to the configuration item is determined based on the field value of the configuration item; The runtime environment attribute corresponding to the configuration item is determined based on the context position of the configuration item in the configuration file; The target configuration item is determined based on the configuration type, the configuration content, and the runtime environment attributes; The target configuration item is compared with the project's historical configuration, the configuration specification, and the target runtime environment configuration template to obtain the historical configuration comparison result, specification comparison result, and template comparison result. Based on the historical configuration comparison results, the specification comparison results, and the template comparison results, it is determined whether the target configuration item has any configuration anomalies, and the second verification result is generated.

7. The method of claim 1, wherein, The step of determining the abnormal object, abnormal location, and risk level based on the first verification result and the second verification result, and generating and outputting the alert information corresponding to the abnormal object, includes: Based on the first verification result and the second verification result, the code segment, database statement and / or configuration item with abnormality is determined as the abnormal object; Determine the abnormal location of the abnormal object in the file to be verified; Based on the anomaly type and verification result corresponding to the anomaly object, the risk level corresponding to the anomaly object is determined; Based on the abnormal object, the abnormal location, the risk level, and the preset repair suggestion information, the reminder information is generated and output.

8. A code submission security check and configuration reminder apparatus, characterized by, include: The file acquisition module is used to acquire newly added or modified files to be verified in the code repository in response to code commit events. The files to be verified include configuration files, as well as at least one of code files and database script files. The content extraction module is used to identify the file category of the file to be verified and extract the content to be verified from the file to be verified according to the identified file category. The content to be verified includes configuration items, as well as at least one of code snippets and database statements. The semantic verification module is used to perform semantic analysis on the code fragment and / or the database statement using a pre-trained code understanding model, obtain semantic analysis results, and perform security verification on the code fragment and / or the database statement based on the semantic analysis results to obtain a first verification result. The configuration verification module is used to determine the target configuration item related to the target runtime environment based on the field name, field value and field context of the configuration item, and to perform configuration verification on the target configuration item according to the project's historical configuration, configuration specifications and target runtime environment configuration template to obtain a second verification result; The reminder output module is used to determine the abnormal object, abnormal location and risk level based on the first verification result and the second verification result, generate reminder information corresponding to the abnormal object, and output the reminder information.

9. A computer device, comprising: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the code submission security verification and configuration alert method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the code submission security verification and configuration reminder method as described in any one of claims 1 to 7.

Images