Compliance verification method, apparatus, device, medium, and product

Abstract

The present disclosure relates to the technical field of computers, and particularly provides a compliance verification method and device, equipment, medium and product. In the present disclosure, verification information and warehouse registration information of a to-be-verified file are obtained, the verification information representing actual compliance information written by the to-be-verified file, and the warehouse registration information representing a compliance information source of the to-be-verified file; based on the warehouse registration information, a target verification rule is determined from a pre-established verification library, the verification library including at least one verification rule of a code source; and based on the target verification rule and the verification information, compliance verification is performed on the to-be-verified file to obtain a verification result. Through the verification library established by multiple code sources, the diversity of the verification rule can be improved, so as to be compatible with the compliance verification in different code file scenarios, avoid the problem that only open source code analysis cannot identify potential security vulnerabilities, and at the same time, the operation and maintenance burden can be reduced. Therefore, the accuracy of the compliance verification can be improved.

Description

Technical Field

[0001] This disclosure belongs to the field of computer technology, and specifically relates to a compliance verification method, apparatus, equipment, medium and product. Background Technology

[0002] Software development often incorporates open-source or third-party code, and software products must meet compliance requirements upon release. Code copyright grants creators exclusive rights to their code, including rights to copy, modify, distribute, and display. Code licenses and copyrights form an indispensable legal and regulatory framework within the software development ecosystem. A code license, through an authorization agreement, clarifies the conditions under which others can use the code, jointly protecting developers' rights and regulating code usage. Therefore, checking code licenses and copyrights for compliance is a crucial way to protect developers' rights.

[0003] In related technologies, SCA (Software Composition Analysis) tools can be used to analyze software components and scan for code compliance. Software composition analysis involves scanning source code to discover and confirm the presence of open-source code, along with its copyright and license information, thereby verifying the existence of potential risks. However, this verification method primarily focuses on analyzing open-source code to identify licenses and potential security vulnerabilities, and cannot check for compliance scenarios involving all licenses and copyrights. Therefore, it reduces the accuracy of code compliance verification. Summary of the Invention

[0004] This disclosure addresses some deficiencies mentioned in the background art by providing a compliance verification method, apparatus, device, medium, and product that can improve the accuracy of compliance verification.

[0005] In a first aspect, embodiments of this disclosure provide a compliance verification method, including: Obtain the verification information and warehouse registration information of the file to be verified. The verification information represents the compliance information actually written to the file to be verified, and the warehouse registration information represents the source of the compliance information of the file to be verified. Based on the warehouse registration information, target verification rules are determined from a pre-established verification library, which includes at least one verification rule for a code source. Based on the target verification rules and the verification information, the file to be verified is subjected to compliance verification to obtain the verification result.

[0006] Optionally, the verification library includes at least one of the following: a rule base and a trusted base; A rule base is used to store verification rules; the verification rules are obtained by extracting the terms and formats of code license information and code copyright information, and the code license information and code copyright information are compliance information from at least one of third-party code, self-developed code and open source code; A trusted library is used to store all trusted code license information and trusted code copyright information of the software to which the file to be verified belongs; the trusted code license information and the trusted code copyright information are compliance information obtained from at least one of repository registration information and open source components.

[0007] Optionally, determining the target verification rule from the pre-established verification database based on the warehouse registration information includes: Based on the repository registration information, the target code license information and target code copyright information of the file to be verified are determined from the trusted repository; Based on the target code license information and the target code copyright information, the target verification rule is determined from the rule base.

[0008] Optionally, the step of performing compliance verification on the file to be verified based on the target verification rule and the verification information to obtain the verification result includes: The target verification rules are used to verify the entered verification information. If the target verification rule is consistent with the verification information filled in, the verification result indicates compliance. If the target verification rule is inconsistent with the verification information entered, the verification result indicates an anomaly.

[0009] Optionally, the method further includes: When the verification result indicates an anomaly, the verification information of the file to be verified is updated based on the target verification rule and verification auxiliary information. The verification auxiliary information is compliance information representing code compliance in historically submitted code files.

[0010] Optionally, the verification auxiliary information includes at least one of the following: submission time, submitting user, and scope of code changes.

[0011] Optionally, the method further includes: Responding to user action requests; When the operation request is a code submission request, it is determined that the file to be verified is a newly added and / or modified code file; When the operation request is a version release request, the file to be verified is determined to be all code files.

[0012] Optionally, obtaining the verification information of the file to be verified includes: The verification information is obtained from the license file, declaration file, and / or source code file header comments in the root directory of the code repository to which the file to be verified belongs.

[0013] In a second aspect, embodiments of this disclosure provide a compliance verification device, comprising: The acquisition module is used to acquire the verification information and warehouse registration information of the file to be verified. The verification information represents the compliance information actually written to the file to be verified, and the warehouse registration information represents the source of the compliance information of the file to be verified. The first determining module is used to determine the target verification rule from a pre-established verification library based on the warehouse registration information, wherein the verification library includes at least one verification rule from a code source. The verification module is used to perform compliance verification on the file to be verified based on the target verification rules and the verification information, and obtain the verification result.

[0014] In a third aspect, embodiments of this disclosure provide an electronic device, 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 above-described compliance verification method.

[0015] In a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the above-described compliance verification method.

[0016] In a fifth aspect, embodiments of this disclosure provide a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described compliance verification method.

[0017] In this disclosure, verification information and repository registration information of the file to be verified are obtained. The verification information represents the compliance information actually written into the file to be verified, and the repository registration information represents the source of the compliance information in the file to be verified. Based on the repository registration information, target verification rules are determined from a pre-established verification library, which includes verification rules from at least one code source. Compliance verification is performed on the file to be verified based on the target verification rules and the verification information to obtain the verification result. The verification library established through multiple code sources can improve the diversity of verification rules, enabling compliance verification in scenarios with different code files and avoiding the problem of failing to identify potential security vulnerabilities due to analysis only of open-source code. Simultaneously, automated verification can reduce the operational burden. Therefore, the accuracy of compliance verification can be improved.

[0018] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0019] Figure 1 A diagram illustrating the differences in the relevant technical code licenses provided in this disclosure.

[0020] Figure 2 This is a flowchart of a compliance verification method provided in this disclosure.

[0021] Figure 3 This is a schematic diagram illustrating the construction of the rule base provided in this disclosure.

[0022] Figure 4 This is a schematic diagram illustrating the construction of the trusted library provided in this disclosure.

[0023] Figure 5 Another flowchart for a compliance verification method provided in this disclosure.

[0024] Figure 6 This is a schematic diagram of a compliance verification device provided in this disclosure.

[0025] Figure 7 This is a hardware block diagram of an electronic device provided in this disclosure.

[0026] Figure 8 This is a schematic diagram of a computer program product provided in this disclosure. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solution of this application, the application scenario of this application will be described first below.

[0028] In software development, open-source code or third-party code is often introduced to improve development efficiency. However, when a software product is released, it needs to meet compliance requirements, especially regarding code licenses and copyrights. Code copyright is the exclusive right granted to the creator of the code, which includes rights such as copying, modification, distribution, and display. Code licenses and copyrights are an indispensable legal and regulatory framework in the software development ecosystem. A code license is a licensing agreement between the copyright holder and others, clearly defining the conditions for others to use the code, jointly protecting the rights of developers, and regulating the use of code. Figure 1 This is a diagram illustrating the differences in the relevant technical code licenses provided in this disclosure. For example... Figure 1As shown, different open-source code licenses have their own code copyright requirements. Taking Apache as an example: if the code is modified, it must be stated in the modified files; derivative code must include the original license, trademark, patent notices, and other notices required by the original author; if a redistributed product includes a Notice file, it must include the Apache License. Users can add their own licenses to the Notice, but these cannot be presented as modifications to the Apache License. Therefore, checking code licenses and copyrights for compliance is an important way to protect developers' rights.

[0029] In related technologies, software code compliance checks are generally performed using SCA (Software Composition Analysis) tools such as Blackduck and AnShiQingYuan to analyze software components, scan for code compliance, and check for unknown, conflicting, or tampered licenses. This generates a "list of materials" that allows users to understand the open-source code components included in the code and analyze the potential risks (intellectual property risks, security vulnerabilities, etc.). Software composition analysis involves scanning source code to discover and confirm the presence of open-source code and its copyright and license information to verify for potential risks. However, this verification method using SCA tools cannot guarantee that all developers are familiar with the compliance requirements for licenses and copyrights of self-developed, open-source, and third-party code. For self-developed code, the main issue is the accuracy and completeness of license and copyright information. For open-source or third-party code, the main issue is that developers may not comply with the open-source or third-party license and copyright terms after modifying the code (as in the example above). In other words, SCA tools are primarily for analyzing open-source code, identifying its licenses and potential security vulnerabilities, and cannot check for compliance in all license and copyright scenarios. Therefore, it will reduce the accuracy of code compliance verification.

[0030] To address the aforementioned technical problems, this disclosure provides an inventive concept: by establishing a multi-source code verification library, the diversity of verification rules can be improved to ensure compliance verification in scenarios with different code files, avoiding the problem of failing to identify potential security vulnerabilities due to analysis only of open-source code. Simultaneously, automated verification can reduce the operational burden. Therefore, the accuracy of compliance verification can be improved.

[0031] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present disclosure and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the drawings, not the entire structure.

[0032] Figure 2 This is a flowchart illustrating a compliance verification method provided in this disclosure. Figure 2 As shown, the method includes: S201: Obtain the verification information and warehouse registration information of the file to be verified.

[0033] Specifically, in this embodiment, the verification information of the file to be verified represents the compliance information actually written into the file, namely the code license information and code copyright information actually written into the code file. A code repository is a centralized / distributed storage space used to store, track, and manage historical versions of project code. It records every code change (author, time, content) through a version control system, supports branch management, version rollback, and multi-user collaboration. The repository registration information represents the source of the compliance information of the file to be verified, i.e., it records all operations (such as commits, merges, permission changes, etc.), supporting operation traceability and compliance review.

[0034] Obtaining warehouse registration information can be used to subsequently determine the target verification rules corresponding to the documents to be verified, and then, in combination with the verification information, to perform compliance verification on the documents to be verified in order to obtain the verification results.

[0035] S202: Based on warehouse registration information, determine the target verification rules from the pre-established verification database.

[0036] Specifically, in this embodiment, the verification library stores pre-extracted verification rules and all trusted code license and copyright information of the software to which the file to be verified belongs. By searching and matching the obtained repository registration information from the pre-established verification library, the target verification rule corresponding to the file to be verified can be determined.

[0037] In this way, by building a verification library from multiple source codes, verification rules for different code file scenarios can be obtained. The verification library includes verification rules from at least one code source. Furthermore, the verification rules include rules for open source / closed source code, which improves the diversity and compatibility of the verification rules, thereby improving the verification accuracy.

[0038] S203: Perform compliance verification on the file to be verified based on the target verification rules and verification information to obtain the verification result.

[0039] Specifically, the content entered in the verification information is matched and verified using the target verification rules to obtain the matching result, i.e., the verification result. If the match is consistent, the verification result is compliant; if the match is inconsistent, the verification result is abnormal.

[0040] In this disclosure, verification information and repository registration information of the file to be verified are obtained. The verification information represents the compliance information actually written into the file to be verified, and the repository registration information represents the source of the compliance information in the file to be verified. Based on the repository registration information, target verification rules are determined from a pre-established verification library. The verification library is used to store verification rules for open-source code and / or closed-source code. Based on the target verification rules and verification information, compliance verification is performed on the file to be verified to obtain the verification result. The verification library established through multiple code sources can improve the diversity of verification rules, enabling compliance verification in scenarios with different code files and avoiding the problem of failing to identify potential security vulnerabilities due to analysis only of open-source code. Simultaneously, automated verification can reduce the operational burden. Therefore, the accuracy of compliance verification can be improved.

[0041] In one possible implementation, an exemplary method for obtaining verification information of the file to be verified includes: Obtain verification information from the license file, declaration file, and / or source code file header comments in the root directory of the code repository to which the file to be verified belongs.

[0042] Specifically, the verification information refers to the code license information and code copyright information actually written in the code file. This information can be placed in the Notice and License files in the root directory of the code repository, or in the header comments of the source code files. The root directory of the code repository is used to record security policy files and compliance files. The corresponding verification information required for the file to be verified can be extracted from the root directory of the code repository and / or the header comments of the source code files.

[0043] In one possible implementation, the verification library includes at least one of the following: a rule base and a trusted base.

[0044] The rule base is used to store verification rules. The verification rules are extracted from the terms and formats of code license information and code copyright information. The code license information and code copyright information are compliance information from at least one of third-party code, self-developed code and open source code.

[0045] Specifically, Figure 3 This is a schematic diagram illustrating the construction of the rule base provided in this disclosure, such as... Figure 3 As shown, the system acquires code license and copyright information for third-party code, self-developed code, and / or open-source code, extracts relevant requirements, and generates verification rules. Each verification rule represents a verification scenario. The purpose of this rule base is to check whether the code license and copyright information of code files complies with the corresponding terms and conditions.

[0046] The trusted library stores all trusted code license information and trusted code copyright information of the software to which the file to be verified belongs; the trusted code license information and trusted code copyright information are compliance information obtained from at least one of the following: repository registration information and open source components.

[0047] Specifically, Figure 4 This is a schematic diagram of the trusted library construction provided in this disclosure, such as... Figure 4 As shown, trusted code license information and copyright information can be obtained from the repository registration information of third-party code, self-developed code, and / or open-source code; alternatively, trusted code license information and copyright information can be obtained from the open-source component SBom (Software Material List), thereby constructing a trusted library for the target software. The open-source repository registration information refers to the manually or automatically tagged repository source, i.e., code license information and copyright information; the open-source component SBom contains a list of software components, the code license information type for each component, the dependencies between components, and the original source of the components. Building a trusted library can then be used to extract corresponding target verification rules from a rule base.

[0048] In one possible implementation, an exemplary method for determining target verification rules from a pre-established verification database based on warehouse registration information includes: Based on the repository registration information, the target code license information and target code copyright information of the file to be verified are determined from the trusted database; based on the target code license information and target code copyright information, the target verification rules are determined from the rule base.

[0049] Specifically, repository registration information is the core carrier of software collaboration and version management, and includes at least one dimension of information such as basic information, access control, version rules, automated configuration, security compliance, and environment dependencies. Based on the repository registration information, information such as the license agreement, compliance documents, data compliance, and audit logs of the file to be verified can be determined. Then, the corresponding target code license information and target code copyright information can be found from the trusted repository. Based on the corresponding license and copyright information, the target verification rules that can be used for compliance verification are selected from a pre-built rule base.

[0050] In one possible implementation, an exemplary method for obtaining a verification result by performing compliance verification on the file to be verified based on the target verification rules and verification information includes: The target verification rules are used to verify the information entered. If the target verification rules are consistent with the information entered, the verification result indicates compliance; if the target verification rules are inconsistent with the information entered, the verification result indicates anomaly.

[0051] Specifically, the input information is validated using target validation rules to determine if it matches the rule requirements. If they match, the validation is compliant; otherwise, it is invalid. By clearly defining the target validation rules for the code to be validated, code license and copyright verification can be performed, making the entire process simpler and faster, and allowing for the discovery and fixing of problems at an earlier stage of development.

[0052] In one possible implementation, the method further includes: When the verification result indicates an anomaly, the verification information of the file to be verified is updated based on the target verification rules and verification auxiliary information.

[0053] Specifically, related technologies have shortcomings in terms of code license and copyright risk and compatibility analysis, and lack automatic repair capabilities, especially in the analysis and repair of licenses and copyrights for third-party code and self-developed code. In this embodiment, when an anomaly is detected in the verification result, the erroneous verification information in the file to be verified can be updated and repaired based on the target verification rules and verification auxiliary information, such as by filling, supplementing, or correcting. Verification auxiliary information refers to compliance information representing code compliance in historically submitted code files, which can be obtained through the repository's commit history. For example, verification auxiliary information includes at least one of the following: commit time, committing user, and scope of code changes.

[0054] Code files are primarily managed using repositories such as Git, GitHub, and SVN. These systems can obtain code commit information, such as commit time, committer, and scope of code changes. This commit information can serve as auxiliary verification information, allowing for the repair of abnormal parts when verification results are not found. Furthermore, while related technologies can manually identify and repair license and copyright issues, this requires significant resources and is not feasible. This embodiment, however, automates verification through scripts, reducing the burden on developers and operations teams.

[0055] In one possible implementation, the method further includes: In response to user operation requests; when the operation request is a code commit request, determine that the file to be verified is a newly added and / or modified code file; when the operation request is a version release request, determine that the file to be verified is all code files.

[0056] Specifically, before performing compliance verification, it is necessary to obtain the user's operation request that triggered the verification. After receiving the relevant operation request, it is necessary to determine the type of the operation request, as different operation request types correspond to different files to be verified.

[0057] When the operation request is a code commit request, the file to be verified is determined to be newly added and / or modified code files. In other words, the corresponding compliance verification is incremental code verification, only targeting newly added and / or modified code files. Accordingly, user operation requests are generally triggered during code commit processes. When the operation request is a version release request, the file to be verified is determined to be all code files. In other words, the corresponding compliance verification is full code verification, verifying all code files of the target software. Accordingly, user operation requests are generally triggered during version release processes.

[0058] Figure 5 Another flowchart for a compliance verification method provided in this disclosure. Figure 5 As shown, the method includes: S501: Trigger the verification process.

[0059] Specifically, the verification process can be triggered during code submission or version release. It's important to understand that the only difference between these triggering methods is the timing; the actual verification process remains the same.

[0060] S502: Startup code verification.

[0061] Specifically, when verification is triggered during code submission, incremental code is verified; when verification is triggered during version release, all code is verified.

[0062] S503: Based on the rule base and trusted base, obtain the target verification rules required for the current code file.

[0063] Specifically, a rule base and a trusted database are pre-built. The rule base stores verification rules extracted from the terms and formats of code license information and code copyright information. The code license information and code copyright information are compliance information from at least one of third-party code, self-developed code, and open-source code. The trusted database stores at least one of the trusted code license information and trusted code copyright information for all software to which the file to be verified belongs.

[0064] Obtain the repository registration information of the current code file, determine the corresponding code license information and code copyright information from the trusted database based on the repository registration information, and then determine the corresponding target verification rules in the rule base.

[0065] S504: Get the verification information of the current code file.

[0066] Specifically, verification information can be obtained from the license file, declaration file, and / or source code file header comments in the root directory of the code repository to which the file to be verified belongs.

[0067] S505: Perform verification according to the target verification rules.

[0068] Specifically, the verification information and the target verification rules are matched and verified. If they match, the code is compliant and the verification passes, proceeding to S507. If they do not match, the code is abnormal and the verification fails, proceeding to S506.

[0069] S506: Based on the target verification rules and verification auxiliary information, repair the verification information related to the current code file.

[0070] Specifically, if the verification fails, it indicates an anomaly. In this case, the current code file can be repaired based on the target verification rules and verification auxiliary information to resolve issues with the code license information and / or code copyright information. Afterwards, proceed to S507 to determine if any other unverified code files exist. If so, proceed to S503 to continue evaluating the target verification rules; if none exist, the verification process ends.

[0071] S507: Determine if all code files have been verified.

[0072] Specifically, if the current code file passes the verification, it is then determined whether there are any other unverified code files. If so, the process proceeds to S503 to continue judging the target verification rule. If not, the verification process ends.

[0073] Furthermore, for different code types (open source code, third-party code, and self-developed code), there are many scenarios for license and copyright verification. The following examples illustrate each scenario: 1) Comply with copyright format requirements.

[0074] Regardless of whether the code is open-source, third-party, or self-developed, it must include copyright information such as the copyright holder's name and the year the copyright was granted. The general format is as follows: Copyright (c) [Year] [Your Name or Your Company's Name] Copyright (c) [Year-Year] [Your Name or Your Company's Name] However, users may make mistakes or fail to meet standards when manually entering code copyright information. Therefore, it is necessary to verify the compliance of the copyright information.

[0075] 2) Comply with the license terms.

[0076] For example, with Apache: when modifying or deriving open-source code, you need to follow the license agreement stipulated by the original author or project, which usually includes retaining copyright, trademark, patent declarations, etc.

[0077] First, the original copyright notice must be retained: the original copyright and license notice should be retained at the top of the modified file.

[0078] For example: /

[0079] Copyright (c) 2012-2023 The Apache Software Foundation, Licensedunder the Apache License, Version 2.0.

[0080] Original code: https: / / www.apache.org / / Next, add a modification statement: After retaining the original statement, you can add a modification statement to explain the user who made the changes and what changes were made, so as to ensure that the code license information verification is compliant.

[0081] For example: /

[0082] Copyright (c) 2012-2023 The Apache Software Foundation, Licensedunder the Apache License, Version 2.0.

[0083] Original code: https: / / www.apache.org /

[0084] Modifications by John Doe: - Added support for HTTP / 2 protocol in request handling (2023-09-01) / Figure 6This is a schematic diagram of the structure of a compliance verification device provided in this disclosure. Figure 6 As shown, the device 600 includes: an acquisition module 610, a first determination module 620, and a verification module 630.

[0085] The acquisition module 610 is used to acquire the verification information and warehouse registration information of the file to be verified. The verification information represents the compliance information actually written to the file to be verified, and the warehouse registration information represents the source of the compliance information of the file to be verified. The first determining module 620 is used to determine the target verification rule from a pre-established verification library based on the warehouse registration information, wherein the verification library includes at least one verification rule from a code source. The verification module 630 is used to perform compliance verification on the file to be verified based on the target verification rules and the verification information, and obtain the verification result.

[0086] Optionally, the verification library includes at least one of the following: a rule base and a trusted base; A rule base is used to store verification rules; the verification rules are obtained by extracting the terms and formats of code license information and code copyright information, and the code license information and code copyright information are compliance information from at least one of third-party code, self-developed code and open source code; A trusted library is used to store all trusted code license information and trusted code copyright information of the software to which the file to be verified belongs; the trusted code license information and the trusted code copyright information are compliance information obtained from at least one of repository registration information and open source components.

[0087] Optionally, the first determining module is used to: Based on the repository registration information, the target code license information and target code copyright information of the file to be verified are determined from the trusted repository; Based on the target code license information and the target code copyright information, the target verification rule is determined from the rule base.

[0088] Optionally, the verification module is used for: The target verification rules are used to verify the entered verification information. If the target verification rule is consistent with the verification information filled in, the verification result indicates compliance. If the target verification rule is inconsistent with the verification information entered, the verification result indicates an anomaly.

[0089] Optionally, the device further includes: The update module is used to update the verification information of the file to be verified based on the target verification rules and verification auxiliary information when the verification result indicates an anomaly. The verification auxiliary information is compliance information representing code compliance in historically submitted code files.

[0090] Optionally, the verification auxiliary information includes at least one of the following: submission time, submitting user, and scope of code changes.

[0091] Optionally, the device further includes: The response module is used to respond to user operation requests; The second determining module is used to determine that the file to be verified is a newly added and / or modified code file when the operation request is a code submission request; The third determination module is used to determine that the file to be verified is the entire code file when the operation request is a version release request.

[0092] Optionally, the acquisition module is used for: The verification information is obtained from the license file, declaration file, and / or source code file header comments in the root directory of the code repository to which the file to be verified belongs.

[0093] This application also provides an electronic device for performing the above-described compliance verification method. Please refer to... Figure 7 It illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 7 As shown, the electronic device 70 includes: a processor 700, a memory 701, a bus 702, and a communication interface 703. The processor 700, the communication interface 703, and the memory 701 are connected via the bus 702. The memory 701 stores a computer program that can run on the processor 700. When the processor 700 runs the computer program, it executes the compliance verification method provided in any of the foregoing embodiments of this application.

[0094] The memory 701 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between the device network element and at least one other network element is achieved through at least one communication interface 703 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0095] Bus 702 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 701 is used to store programs. After receiving an execution instruction, the processor 700 executes the program. The compliance verification method disclosed in any of the foregoing embodiments of this application can be applied to the processor 700, or implemented by the processor 700.

[0096] The processor 700 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 700 or by instructions in software form. The processor 700 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 701. Processor 700 reads the information in memory 701 and, in conjunction with its hardware, completes the steps of the above method.

[0097] The electronic device provided in this application embodiment and the compliance verification method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0098] This application also provides a computer-readable storage medium corresponding to the compliance verification method provided in the foregoing embodiments. The computer-readable storage medium shown can be an optical disc, on which a computer program is stored. When the computer program is run by a processor, it executes the compliance verification method provided in any of the foregoing embodiments.

[0099] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0100] The computer-readable storage medium provided in the above embodiments of this application and the compliance verification method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0101] This application also provides a computer program product 800, such as... Figure 8 As shown. This computer program product carries a computer program 801. The instructions included in the program code can be used to execute the steps of the compliance verification method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0102] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0103] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0104] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0105] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0106] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0107] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0108] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0109] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A compliance verification method, characterized in that, include: Obtain the verification information and warehouse registration information of the file to be verified. The verification information represents the compliance information actually written to the file to be verified, and the warehouse registration information represents the source of the compliance information of the file to be verified. Based on the warehouse registration information, target verification rules are determined from a pre-established verification library, which includes at least one verification rule for a code source. Based on the target verification rules and the verification information, the file to be verified is subjected to compliance verification to obtain the verification result.

2. The method according to claim 1, characterized in that, The verification library includes at least one of the following: a rule base and a trusted base; A rule base is used to store verification rules; the verification rules are obtained by extracting the terms and formats of code license information and code copyright information, and the code license information and code copyright information are compliance information from at least one of third-party code, self-developed code and open source code; A trusted library is used to store all trusted code license information and trusted code copyright information of the software to which the file to be verified belongs; The trusted code license information and the trusted code copyright information are compliance information obtained from at least one of the following: repository registration information and open source components.

3. The method according to claim 2, characterized in that, The step of determining the target verification rule from the pre-established verification database based on the warehouse registration information includes: Based on the repository registration information, the target code license information and target code copyright information of the file to be verified are determined from the trusted repository; Based on the target code license information and the target code copyright information, the target verification rule is determined from the rule base.

4. The method according to claim 1, characterized in that, The compliance verification of the file to be verified based on the target verification rules and the verification information, to obtain the verification result, includes: The target verification rules are used to verify the entered verification information. If the target verification rule is consistent with the verification information filled in, the verification result indicates compliance. If the target verification rule is inconsistent with the verification information entered, the verification result indicates an anomaly.

5. The method according to claim 4, characterized in that, The method further includes: When the verification result indicates an anomaly, the verification information of the file to be verified is updated based on the target verification rule and verification auxiliary information. The verification auxiliary information is compliance information representing code compliance in historically submitted code files.

6. The method according to claim 5, characterized in that, The verification auxiliary information includes at least one of the following: submission time, submitting user, and scope of code changes.

7. The method according to claim 1, characterized in that, The method further includes: Responding to user action requests; When the operation request is a code submission request, it is determined that the file to be verified is a newly added and / or modified code file; When the operation request is a version release request, the file to be verified is determined to be all code files.

8. The method according to claim 1, characterized in that, The step of obtaining the verification information of the file to be verified includes: The verification information is obtained from the license file, declaration file, and / or source code file header comments in the root directory of the code repository to which the file to be verified belongs.

9. A compliance verification device, characterized in that, include: The acquisition module is used to acquire the verification information and warehouse registration information of the file to be verified. The verification information represents the compliance information actually written to the file to be verified, and the warehouse registration information represents the source of the compliance information of the file to be verified. The first determining module is used to determine the target verification rule from a pre-established verification library based on the warehouse registration information, wherein the verification library includes at least one verification rule from a code source. The verification module is used to perform compliance verification on the file to be verified based on the target verification rules and the verification information, and obtain the verification result.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1-8.

Images