CN112883342A

CN112883342A - Component management and control method, device and equipment

Info

Publication number: CN112883342A
Application number: CN202110324118.XA
Authority: CN
Inventors: 张学舟; 黄玺磊; 胡晓菲; 余立
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2021-03-26
Filing date: 2021-03-26
Publication date: 2021-06-01

Abstract

The embodiment of the specification provides a method, a device and equipment for managing and controlling components, and the method, the device and the equipment for managing and controlling the components can be used in the technical field of information security. The method comprises the steps of receiving a component checking request sent by a version control system; the component checking request comprises identification information of a target application; acquiring the latest submitted content of the target application from the version control system according to the identification information; determining a component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified; inspecting the component to be inspected to obtain an inspection result; determining whether to submit the latest submission into a library based on the checking result. By utilizing the embodiment of the specification, the efficiency of using and controlling the third-party component can be obviously improved, and the condition of illegally using the third-party component is effectively reduced.

Description

Component management and control method, device and equipment

Technical Field

The present application relates to the field of information security technologies, and in particular, to a method, an apparatus, and a device for managing and controlling components.

Background

At present, in the process of software development of an enterprise, in order to reduce the difficulty of software development and improve the efficiency of employee development, third-party components are often used in large quantities. However, while enjoying the convenience of third-party components, the third-party components themselves have many problems, for example, the third-party components often have some defects or security holes, so that the software developed based on the third-party components has weak links or potential safety hazards. As a result, the regulation of third party components is becoming increasingly important.

In the prior art, the use of third party components by an application is regulated mainly by issuing a regulation and then taking a manual inspection based on the regulation. This kind of mode not only needs to consume a large amount of manpowers, appears carelessly moreover easily to lead to the less effective management and control to third party's subassembly.

Therefore, there is a need for a solution to the above technical problems.

Disclosure of Invention

The embodiment of the specification provides a component management and control method, device and equipment, which can obviously improve the efficiency of managing and controlling the use of a third-party component and effectively reduce the condition of illegally using the third-party component.

The method, the device and the equipment for managing and controlling the components are realized in the following modes.

A method of component management, comprising: receiving a component checking request sent by a version control system; the component checking request comprises identification information of a target application; acquiring the latest submitted content of the target application from the version control system according to the identification information; determining a component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified; inspecting the component to be inspected to obtain an inspection result; determining whether to submit the latest submission into a library based on the checking result.

An assembly management and control device, comprising: the receiving module is used for receiving a component checking request sent by the version control system; the component checking request comprises identification information of a target application; the acquisition module is used for acquiring the latest submitted content of the target application from the version control system according to the identification information; the determining module is used for determining the components to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified; the inspection module is used for inspecting the component to be inspected to obtain an inspection result; and the management and control module is used for determining whether to submit the latest submitted content into a warehouse or not based on the check result.

An assembly management and control device comprising at least one processor and a memory storing computer executable instructions, which when executed by the processor, implement the steps of any one of the method embodiments of the present specification.

A computer readable storage medium having stored thereon computer instructions which, when executed, implement the steps of any one of the method embodiments in the present specification.

The specification provides a method, a device and equipment for managing and controlling components. In some embodiments, a component check request sent by a version control system may be received, where the component check request includes identification information of a target application, a latest submission content of the target application is obtained from the version control system according to the identification information, and then a component to be checked included in the latest submission content is determined based on the latest submission content and a last submission content, where the component to be checked includes a third-party component that is newly used and/or modified. Further, the component to be checked can be checked, and whether the latest submitted content is submitted into a warehouse or not can be determined based on the checking result. By adopting the implementation scheme provided by the specification, the efficiency of using and controlling the third-party component can be obviously improved, and the condition of illegally using the third-party component is effectively reduced.

Drawings

The accompanying drawings, which are included to provide a further understanding of the specification, are incorporated in and constitute a part of this specification, and are not intended to limit the specification. In the drawings:

FIG. 1 is a schematic diagram of a scenario of a method for managing components provided herein;

FIG. 2 is a schematic flow chart diagram illustrating one embodiment of a component management method provided herein;

FIG. 3 is a schematic overall flow chart of the inspection of a third-party component provided in the present specification;

FIG. 4 is a schematic diagram of a specific inspection process performed on a third-party component corresponding to the dependence of a jar package file/jar package provided by the present specification;

FIG. 5 is a schematic flow chart of checking whether a file/package dependency of a jar package is in a white list or a black list;

FIG. 6 is a block diagram of an embodiment of an apparatus for managing and controlling components provided herein;

fig. 7 is a hardware configuration block diagram of an embodiment of a component management server provided in the present specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments in the present specification, and not all of the embodiments. All other embodiments that can be obtained by a person skilled in the art on the basis of one or more embodiments of the present description without inventive step shall fall within the scope of protection of the embodiments of the present description.

As shown in fig. 1, fig. 1 is a schematic view of a scenario of a component management method provided in this specification. In the implementation scenario, the system may include a version control system, a persistent integration platform, and a third-party component information base. Specifically, after completing code writing of a certain function of an application in a local environment, one or more developers can submit written content to a remote version control system through a Git client, and after receiving the content submitted by a user, the version control system can send a component checking request to the persistent integration platform. Further, after receiving the component inspection request, the persistent integration platform can download the latest submitted content of the target application from the version control system, then determine the component to be inspected included in the latest submitted content based on the latest submitted content and the last submitted content, and finally develop a construction process for the component to be inspected according to information in the third-party component information base. Further, after the construction process is completed, the result can be fed back to the developer through mails and the like.

Among other things, the version control system may be used to store all data assets related to an application, such as: source code files, configuration files, database scripts, build scripts, etc. of the application. In some implementations, the versioning system can be a Git-based distributed versioning system, such as: gerrit, GitHub, GitLab, and the like. The version control system may not only provide version control capabilities, but also support restoration to any particular version. The version control capability may be understood as recording which modified contents each version corresponds to respectively. In some implementations, the version control system may be configured with a mechanism for submitting notifications, i.e., sending a real-time notification to the persistent integration platform whenever a request is received from a user to submit a code.

The continuous integration is a quality guarantee mechanism in the software development process, project group members can frequently submit codes to a version control system, a continuous integration platform integrates the content submitted each time, and an automatic construction process is used for verifying whether the integrated system is available, so that problems can be found and repaired as early as possible, and the application is ensured to be in a normal state all the time. In some implementation scenarios, the continuous integration platform can be a Jenkins platform, which has perfect functions, can provide rich plug-in systems, and supports docking with a plurality of tools in the field of DevOps.

Since it is important to trigger the mechanism for automated build when the persistent integration platform interfaces with the version control system. Therefore, in some implementation scenarios, the persistent integration platform may provide two triggering modes: the first is a timed build, i.e., supporting the periodic execution of build operations at an hourly/daily/weekly frequency; the second is build-on-the-fly, i.e., a change in the version control system triggers the build.

In some implementation scenarios, the automated building process of the persistent integration platform may include four steps: code compilation, static code scanning, custom checking, and unit testing processes. In some implementation scenarios, the custom inspection phase may allow for the configuration of user-defined inspection flows.

The third-party component information base may store information of all third-party components that are introduced, evaluated and registered by each application in the enterprise in advance, and may also store a white list table, a black list table and the like of the third-party components in advance. In this way, certain components to be inspected can be directly cleared or blocked during inspection based on information in the third party component information base.

The following describes an embodiment of the present disclosure with a specific application scenario as an example. Specifically, fig. 2 is a schematic flow chart of an embodiment of a component management and control method provided in this specification. Although the present specification provides the method steps or apparatus structures as shown in the following examples or figures, more or less steps or modules may be included in the method or apparatus structures based on conventional or non-inventive efforts.

One embodiment provided by the present specification can be applied to a client, a server, and the like. The client may include a terminal device, such as a smart phone, a tablet computer, and the like. The server may include a single computer device, or may include a server cluster formed by a plurality of servers, or a server structure of a distributed system, and the like.

It should be noted that the following description of the embodiments does not limit the technical solutions in other extensible application scenarios based on the present specification. In an embodiment of a component management method provided herein, which may be applied to a persistent integration platform, as shown in fig. 2, the method may include the following steps.

S0: receiving a component checking request sent by a version control system; the component check request includes identification information of the target application.

In some embodiments, after the local environment completes the code writing of a certain function of the application, the user may submit the written content to a remote version control system.

In some embodiments, the version control system may send a component check request to the persistent integration platform after receiving the authoring content submitted by the user. Wherein, the component checking request may include identification information of the target application. The identification information may be used to identify the target application. The identification information may be obtained by one or more combinations of numbers, letters, characters, etc., and this specification does not limit this.

In some implementation scenarios, the version control system may send a component checking request to the persistent integration platform whenever it detects a submission request initiated by a user, and the persistent integration platform may perform a build process on the code of the application after receiving the component checking request. In some implementation scenarios, the persistent integration platform may allow for the embedding of user-defined code inspection logic in the build flow.

In the embodiment of the description, based on the component inspection request sent by the version control system, the continuous integrated pipeline operation inspection flow can be automatically triggered, so that the component management and control efficiency can be effectively improved.

S2: and acquiring the latest submitted content of the target application from the version control system according to the identification information.

In this embodiment of the present specification, after receiving the component checking request, the persistent integration platform may obtain the latest submission content of the target application from the version control system according to the identification information.

In some embodiments, to develop the inspection of the third-party component, the persistent integration platform may download the latest submitted content of the application from the version control system after receiving the component inspection request, and store the latest submitted content in a local directory of the persistent integration platform, so as to analyze the third-party component in the persistent integration platform.

S4: determining a component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be inspected include third party components that are newly used and/or modified.

In this embodiment of the present specification, after the latest submission content of the target application is acquired from the version control system according to the identification information, the component to be checked included in the latest submission content may be determined based on the latest submission content and the last submission content. Wherein the component to be inspected may include a third party component for which new use and/or modification has occurred. In some implementation scenarios, the component to be inspected may include one or more. The third-party component can be understood as code which is written and packaged by a third-party organization, and can be conveniently introduced into a software project for direct reuse, such as: in the field of Java development, the Spring framework has developed into an indispensable "big tool" in the development process of daily projects. In some implementation scenarios, the third-party component is typically free open source software created and maintained by an open source organization, and may also be commercial software purchased on a fee by a business, or an underlying public component developed within a business, etc.

In some embodiments, in order to improve the checking efficiency of the third-party component, after the latest submitted content of the target application is obtained, an "incremental checking" mode may be adopted, that is, only the latest submitted content is compared with the last submitted content, and a third-party component that is newly used or modified in the current submitted content is obtained. Of course, the above description is only exemplary, the manner of determining the components to be inspected is not limited to the above examples, and other modifications are possible for those skilled in the art in light of the technical spirit of the present application, and the present application is intended to cover all the functions and effects of the components as long as the functions and effects are the same or similar to those of the present application.

S6: and inspecting the component to be inspected to obtain an inspection result.

In the embodiment of the present specification, after determining the component to be checked included in the latest submitted content, the component to be checked may be checked to obtain a check result. The inspection result may include pass and fail of inspection. Wherein failure to pass the check may result from a number of reasons, such as, for example, not using a registry, using unofficial media, not introducing an evaluation form, in a blacklist form, and the like. The check pass can indicate that the target application does not violate the use of the third-party component, and the check fail can indicate that the target application does not violate the use of the third-party component.

In some implementations, in order for the use of third party components to be non-violating, two tables need to be filled out: introduce the evaluation table, use the registration table. Wherein, an evaluation table is introduced: when a third-party component is introduced into an enterprise for the first time, detailed evaluation on the aspects of safety, performance, stability and the like of the component is required, and an introduction registry is filled in. The import evaluation table comprises corresponding jar package name, jar package version, jar package hash value, import organization name, import personnel name, import time and other field information. If a third-party component is directly used in the application without introducing evaluation, serious hidden danger is brought to an online business system. Using the registry: when an application under a certain project group in an enterprise first uses a third party component, a usage registry needs to be filled out. The use registration table comprises corresponding field information such as jar packet name, jar packet version, jar packet hash value, use organization name, use application name, use time and the like. If a third-party component is directly used in the application without using the registration, the application cannot be informed to perform necessary upgrading or replacing operation when the component is subsequently discovered to have a bug or the version is out of date. It should be noted that, the introduction of the evaluation table is filled when the enterprise firstly introduces a third-party component, and each component needs to be filled only once. The usage registry is filled in when the application first uses a third party component, and since a component is used by different sets of items, different applications, it is filled in multiple times.

In the embodiment of the specification, by checking the component to be checked, the code of the illegal component can be prevented from being deployed in a production environment, and an individual can avoid bringing potential risks to an enterprise.

In some embodiments, the inspecting the component to be inspected to obtain an inspection result may include: acquiring third-party component information corresponding to the target application; the third-party component information comprises an introduction evaluation table, a black list table, a white list table and a use registration table; acquiring a reference file corresponding to the component to be checked; the quote file comprises jar package file and/or pom file; and checking the component to be checked based on the third-party component information and the reference file to obtain a checking result.

In the process of checking the use condition of the third-party component, an evaluation table, a blacklist table, a white list table and a third-party component information table (use registration table) registered and used by the application need to be used, and in some implementation scenes, data of the four tables can be read from a third-party component information base to a memory, and then third-party component information corresponding to the target application is obtained for comparing the component to be checked in the checking process.

In a Java language application, the third party component exists in the form of a jar package file. In some implementation scenarios, two ways of referencing jar package files are applied: the first is to add the required jar packs directly to the code base and reference them into the compilation path of the program; the second method is to indirectly manage the jar packages through a maven tool, a pom file containing the unique identification information of the needed jar packages is added into a code base, and the maven tool automatically downloads the jar package files into a local warehouse of the maven (independent of the code base of the application) and quotes the jar package files into a compiling path of the program.

In some implementation scenarios, in order to achieve the effect of "incremental inspection", all jar package files and pom files corresponding to components to be inspected that are newly used or modified in the present submission content (i.e., the latest submission content) may be acquired. In some implementation scenarios, the reference file corresponding to the component to be checked may be obtained by sending a specific command to the version control system. Such as: for the Git-based version control system, a Git diff HEAD-1 HEAD-name-status-no-details command can be run to obtain a change file list, and then a reference file corresponding to a component to be checked is screened from the change file list.

In some embodiments, the checking the component to be checked based on the third-party component information and the reference file to obtain a checking result may include: taking a first file from the reference file; judging whether the first file is a jar package file or not; and under the condition that the first file is a jar package file, checking the component to be checked based on the third party component information and the jar package file to obtain a checking result.

Since each jar package file directly corresponds to one third-party component, and each pom file may contain dependence on a plurality of jar package files, namely, corresponds to a plurality of third-party components, there are some differences in the checking processes of the jar package file and the pom file.

In some implementations, a file may be fetched from the reference file and then a determination may be made as to whether the file is a jar package file. If the file is a jar package file, a specific checking process can be operated based on the third-party component information and the jar package file, namely, a white list and a black list are sequentially developed for the jar package file, and whether the white list and the black list are subjected to introduction evaluation or not and whether the jar package file is subjected to check of use registration or not.

In some embodiments, when the first file is not a jar package file, a jar package dependency corresponding to the component to be inspected in the first file may be obtained; and checking the component to be checked based on the third-party component information and the jar package dependence to obtain a checking result.

In some implementation scenarios, a file fetched from a reference file may be determined to be a pom file if it is not a jar package file. Because each pom file contains the jar package dependence information of the project, the difference between the project dependence part in the present submitted content and the project dependence part in the last submitted content needs to be compared, and the jar package dependence which is newly used or modified in the present submitted content is distinguished.

In some embodiments, the obtaining of the jar package dependency corresponding to the component to be checked in the first file may include: acquiring a first effective model structure and a second effective model structure corresponding to the first file; the first valid model structure is determined based on the current submission and the second valid model structure is determined based on the last submission; and comparing the first effective model structure with the second effective model structure to obtain the jar package dependence corresponding to the component to be inspected in the first file.

In some implementation scenarios, obtaining jar package dependencies corresponding to components to be checked in the pom file may include the following steps:

a) and acquiring the corresponding effective model structure of the pom file in the submission. Because the pom file omits the dependency information inherited from the parent pom file, in order to obtain the complete dependency information, the current effective model structure of the pom file needs to be obtained first. For the maven tool, the "mvn-f < pom _ dir >/pom. xml help: effective-pom" command can be run to get. Pom the effective model structure of the file may contain information such as project dependency, project plug-in, project execution target, project construction Profile, developer list, etc., and may be used to declare the dependency of the project, describe how the project is constructed, and other explanatory information.

b) And acquiring the last submission content of the pom file. Wherein, for the Git-based version control system, the Git show HEAD-1: < pom _ dir >/pom. Then, the obtained content is written into a temporary file (such as pom.

c) And acquiring the corresponding effective model structure of the pom file in the last submission. Similarly, the "mvn-f < pom _ dir >/pom.prev.xml help: effective-pom" command can be run to obtain, i.e., the command in a) is run against the temporary file in b).

d) And comparing the difference between the corresponding item dependency information parts of the pom file in the effective model structure submitted this time and the effective model structure submitted last time, and analyzing the jar package dependency corresponding to the component to be inspected in the pom file in the content submitted this time.

Of course, the above description is only exemplary, and the manner of obtaining jar package dependency corresponding to the component to be inspected in the pom file is not limited to the above examples, and other modifications are possible for those skilled in the art in light of the technical spirit of the present application, but all that can be achieved by the method and the device are intended to be covered by the scope of the present application as long as the functions and effects achieved by the method and the device are the same or similar to the present application.

In some implementation scenarios, after the jar package dependency corresponding to the component to be checked in the first file is obtained, a specific checking process may be run based on the third-party component information and the jar package dependency, that is, a white list and a black list are sequentially developed for the jar package dependency, and whether the white list and the black list are subjected to introduction evaluation or not and whether the jar package dependency is subjected to checking of using registration or not are sequentially developed.

In some implementation scenarios, the reference file may include multiple files, so that one file may be sequentially retrieved from the reference file for inspection until all files are inspected.

Fig. 3 is a schematic overall flow chart of checking a third-party component provided in this specification, as shown in fig. 3. Specifically, the following steps may be included.

S301, acquiring an introduction evaluation table, a black list table, a white list table and an application use registration table of the third-party component.

S302, a jar package file and a pom file list 1 corresponding to a third party component which is newly used or modified in the submitted content are obtained.

The list composed of jar package files and pom files corresponding to all newly used or modified third-party components in the submitted content is called as "list 1".

S303, taking out one file from the list 1.

And sequentially taking out a jar package file or a pom file from the list, and carrying out formal inspection processes on the jar package file or the pom file.

S304, judging whether the file is a jar package file.

If the file is a jar package file, go to step S305, otherwise go to step S306.

S305, specific checking flow is operated aiming at the jar package file.

The specific checking process comprises the steps of sequentially developing a white list and a black list for the third-party component corresponding to the jar package file, and checking whether the white list and the black list are subjected to introduction evaluation and use registration. Further, go to step S309.

S306, obtaining a jar package dependency list 2 corresponding to the newly added used or modified third-party component in the pom file.

A list composed of jar package dependencies corresponding to all newly used or modified third-party components in the pom file in the submitted content is referred to as a "list 2".

S307, taking out a jar packet dependence from the list 2, and running a specific checking flow.

The specific checking process comprises the steps of sequentially developing a white list and a black list for the jar packet depending on the corresponding third-party component, and checking whether the white list and the black list are subjected to introduction evaluation and use registration.

S308, judging whether the dependence of the jar packet in the list 2 is checked.

If the dependence check of the jar packet in the list 2 is finished, the step goes to step S309, otherwise, the step goes to step S307, and the check of the dependence of the next jar packet is continued.

S309, judging whether the files in the list 1 are checked.

And judging whether jar package files and pom files corresponding to all newly used or modified third-party components in the submitted content are checked, if so, finishing the whole checking process, otherwise, turning to the step S303, and continuing to check the next file.

In some embodiments, the checking the component to be checked based on the third-party component information and the jar package file or checking the component to be checked based on the third-party component information and the jar package dependency to obtain the checking result may include: checking whether the jar package file or the jar package dependency is in a white list table included in the third-party component information; when the third party component information is determined not to be in the white list table, checking whether the jar package file or the jar package dependency is in a black list table included in the third party component information; when the hash value is determined not to be in the blacklist table, calculating the jar package file or the hash value on which the jar package depends; checking whether the jar packet file or the jar packet dependency is in an introduction evaluation table included in the third-party component information according to the hash value; and when the judgment result is determined to be introduced into the evaluation table, checking whether the jar packet file or the jar packet dependency is in a use registration table included in the third-party component information according to the hash value to obtain a checking result.

In some implementation scenarios, when a jar package file/dependency is confirmed in the white list table, it may be stated that the component is safe and reliable (e.g., an underlying common component developed inside an enterprise, etc.), and the inspection result obtained at this time is a pass, which may be directly passed.

In some implementation scenarios, when it is confirmed that a jar package file/dependency is not in the white list table but in the black list table, it can be said that the component is a security risk (e.g., a component that has been eliminated in the industry or a component with a known bug, etc.), and the obtained check result is that the component does not pass and can be directly intercepted. In some implementations, when the obtained check result is a fail, the reason for the fail may be output, such as in a blacklist table.

In some implementations, when it is determined that a jar packet file/dependency is not in the white list table and not in the black list table, a hash value of the jar packet file or jar packet dependency may be calculated. Since the introduction evaluation table indexes the hash value field, it can be checked whether it is in the introduction evaluation table by the hash value. It should be noted that, after the project group completes import evaluation of a third-party component, basic information (such as a corresponding jar package name, jar package version, jar package hash value, import organization name, import personnel name, import time, etc.) of the project group is added to an import evaluation table in the third-party component information base.

In some implementation scenarios, when determining that the jar packet file/dependency is in the import evaluation table through the hash value check, it may further check whether the jar packet file/dependency is in the usage registry of the application according to the hash value, and when determining that the usage registry is in the import evaluation table, it indicates that the corresponding component to be checked passes through two flows of import evaluation and usage registration, and the check result obtained at this time is pass. It should be noted that, when a third-party component is used in an application by a project group, basic information (such as a corresponding jar package name, jar package version, jar package hash value, use organization name, use application name, use time, etc.) of the third-party component is usually added to a use registry in a third-party component library.

In some implementation scenarios, after determining that the jar package file/dependency is in the import evaluation table, and further checking whether the jar package file/dependency is in the use registry of the application, if the jar package file/dependency is determined not to be in the use registry, it indicates that the corresponding component to be checked has passed the import evaluation flow, but the application does not perform use registration, and the obtained check result does not pass. Accordingly, it is possible to output a message that the reason for the non-passing is not registered for use.

In some embodiments, the checking whether the jar packet file or the jar packet dependency is in an import evaluation table included in the third party component information according to the hash value may further include: and when the component to be checked is determined not to be in the import evaluation table, checking whether the jar package file or the jar package dependency is in the import evaluation table included in the third-party component information according to the file name of the component to be checked to obtain a checking result.

Since in some cases the application may acquire third party components from an unofficial channel, there may be cases of malicious tampering or implantation of a virus. In some implementation scenarios, in order to effectively distinguish between the scenarios, the presence of the component in the incoming evaluation table may be checked again based on the file name of the third party component.

In some implementation scenarios, when determining that the jar package file/dependency is not in the import evaluation table through hash value check, whether the jar package file/dependency is in the import evaluation table may be further checked according to the file name of the component to be checked, and when determining that the jar package file/dependency is in the import evaluation table according to the file name of the component to be checked, it may be stated that the component used by the application is obtained from an unofficial channel, and at this time, the check result may be obtained as not passing. Accordingly, the non-passing reason can be output because the unofficial medium is used.

In some implementation scenarios, when determining that jar package file/dependency is not in the import evaluation table according to the file name of the component to be checked, it may be indicated that the component has never been subjected to import evaluation, and the check result may be obtained as not passing. Accordingly, the non-passing reason can be outputted without introducing the evaluation.

As shown in fig. 4, fig. 4 is a schematic diagram of a specific inspection process performed on a third-party component corresponding to a dependence of a jar package file/jar package provided in this specification. Specifically, the following steps may be included.

S401, checking whether jar package file/dependency is in a white list table.

Wherein, when the jar package file/dependency is confirmed in the white list table, which indicates that the jar package file/dependency is safe and reliable, S406 may be executed. Otherwise, S402 is executed.

S402, checking whether jar package file/dependency is in a black list table.

Wherein, when the jar package file/dependency is confirmed in the blacklist table, it is indicated that the jar package file/dependency has a security risk, and at this time, S403 may be executed. Otherwise, S404 is performed.

S403, output "check not passed (in blacklist)".

Wherein when a third party component is added to the blacklist table, it is directly intercepted and outputs "check not passed (in blacklist)".

S404, calculating a hash value of the jar packet file/dependency, and checking whether the jar packet file/dependency is introduced into the evaluation table according to the hash value.

After the project group completes the import evaluation of a third-party component, the basic information of the project group is added into an import evaluation table in a third-party component information base. Here, the hash value of the jar packet file/dependency may be calculated first, and then whether the jar packet file/dependency is in the import evaluation table may be checked by the hash value. If so, S405 is performed. Otherwise, S408 is performed.

S405, whether jar package files/dependencies are in the use registry of the application is checked according to the hash values.

When a project group uses a third-party component in an application, basic information of the project group is added into a use registration table in a third-party component library. Here, it may be checked whether the jar package file/dependency is in a third party component usage registry belonging to the application. If so, then S406 is performed. Otherwise, S407 is performed.

S406, outputting 'check pass'.

Wherein when a third party component is added to the whitelist table, it passes directly and outputs a "check pass". If a third party component goes through both the process of introducing an assessment and using a registration, a "check pass" is output.

S407, output "check not passed (unregistered use)".

Wherein if a third party component has undergone the introduction evaluation flow but the application has not performed the usage registration, the output "check-out (unregistered usage)".

S408, checking whether jar package files/dependencies are in the import evaluation table according to the file names.

In some cases, the application may obtain the third-party component from an unofficial channel, and there may be cases of malicious tampering or virus implantation. In order to effectively distinguish the scene, it is necessary to retrieve again whether the component exists in the import evaluation table according to the file name of the third party component. If yes, S409 is performed. Otherwise, S410 is performed.

S409, output "check not passed (use unofficial medium)".

If a certain third-party component cannot be checked in the import evaluation table through the hash value, but the corresponding record is checked through the file name, the component used by the application is acquired from an unofficial channel, and the output of 'checking not passed (unofficial medium used)'.

S410, output "check not passed (not introduced evaluation)".

If the corresponding record is not checked in the import evaluation table through the hash value and the file name, the component is indicated to be never subjected to import evaluation, and the component outputs 'check failed (un-import evaluation)'.

In some embodiments, the checking whether the jar package file or the jar package dependency is in a white list table or a black list table included in the third party component information may include: acquiring the jar package file or coordinate information on which the jar package depends; matching the coordinate information with the rule information in the white name list table or the black name list table in sequence; under the condition of failed matching, judging whether unmatched rule information still exists in the white list table or the black list table; determining that the jar package file or the jar package is not dependent on the white list table in the absence of unmatched rule information.

In some implementation scenarios, in order to check whether the jar package file or jar package dependency is in the white list or the black list, the coordinate information of the jar package file or jar package dependency may be obtained first. Wherein the coordinate information may include unique coordinates.

In some implementation scenarios, the unique coordinates may be a triplet locator in maven that identifies exactly one component identity, i.e., < groupId, artifactId, versionId >. Wherein, groupId represents the organization name to which the component belongs, artifactId represents the component name, and versionId represents the component version number.

For jar package files and jar package dependencies, there is a certain difference in the way of obtaining unique coordinates. In some implementation scenarios, for jar package dependencies, its unique coordinates can be directly obtained from the pom file.

In some implementation scenarios, for jar package files, the unique coordinates thereof can be obtained by the following steps:

a) and calculating the hash value of the jar packet file, accessing the HTTP API of the maven remote warehouse through the hash value, and trying to acquire the unique coordinate of the maven remote warehouse. And if the acquisition is successful, ending. Otherwise, step b) is executed.

b) And searching a pom file built in the jar package file, and analyzing the unique coordinate from the pom file. And if the acquisition is successful, ending. Otherwise, step c) is executed. The pom files built in the jar package files are generally in a plurality of layers of subordinate subdirectories of the META-INF/maven/directory.

c) And analyzing the name of the jar package file, taking the "- [0-9 ]" typeface as a regular expression to split the file name, and trying to obtain a unique coordinate. Such as: for a common-dbcp-1.4. jar file, the unique coordinates obtained by splitting are < common-dbcp, 1.4 >. And if the acquisition is successful, ending.

It should be noted that the unique coordinates must be obtained through the above steps a) to c).

In some implementations, a rule may be retrieved from the white/black list after obtaining the unique coordinates on which the jar package file or jar package depends. Wherein, the white/black list table may include one or more pieces of rule information. Each piece of rule information may be referred to as a rule, and each rule has the ability to match multiple target objects.

In some implementations, for a white list table, each rule may contain two fields, type and content. Wherein, the type field indicates the type of the rule, and three dictionary values of g, a and g/a are allowed to be filled in. The content field indicates the content of the rule, and the specific meaning and action range of the rule are determined according to the value of the type field. In some implementation scenarios, during the matching logic, when the type field takes the value of g, the content field is used for matching the groupId value in the unique coordinate, and all third-party components matched with the groupId value are released; when the type field is a, the content field is used for matching the artifactId value in the unique coordinate and representing that all third-party components matched with the artifactId are released; when the type field is in a value of g/a, the content field is used for matching the joint value of groupId + artifact in the unique coordinate, and all third-party components matched with the groupId + artifactId are released. The joint value of the groupId and artifact can be understood as the content after splicing the groupId field and the artifactId field.

In some implementations, for a blacklist, each rule may contain three fields, type, version, and content. Wherein the type field and the content field have the same meaning as the same name field in the white list, and the version field indicates the version of the rule. In some implementation scenarios, when performing the matching logic, in addition to matching the type field and the content field according to the white list, the version field is also used to match the version id. Specifically, when the version field takes a word of ═ x.y.z ", it means that on the basis of matching of groupId, artifactId or groupId + artifactId, it is necessary to satisfy that the version id is equal to x.y.z, all the third-party components matched therewith will be rejected; when the version field takes a word of "> x.y.z", it means that all the third-party components matched with the version id are rejected only when the version id is larger than x.y.z on the basis of matching of groupId, artifactId or groupId + artifactId; when the version field takes a word of "< x.y.z", it means that all the third-party components matched with the version id are rejected only if the version id is smaller than x.y.z on the basis of matching of groupId, artifactId or groupId + artifactId.

In some implementation scenarios, after obtaining the unique coordinates on which the jar package file or jar package depends and taking out a rule from the white/black list, the content of the rule may be matched with the unique coordinates according to the type of the rule. Specifically, the content field of a rule can be selected to match the unique coordinate of the third-party component according to the type field value of the rule, and the component is selected to be released/rejected according to the matching result.

In some implementations, if the rule match is successful, the output is "in white/blacklist". If the rule matching fails, further, whether an unmatched rule exists in the white/black list table or not can be judged, if yes, the matching is continued until all the rules are matched and the matching is not successful, and 'not in the white/black list' is output.

Fig. 5 is a schematic flow chart for checking whether a file/package dependency of a jar package is in a white list or a black list, as shown in fig. 5. Specifically, the following steps may be included.

S501, obtaining the unique coordinates of the currently checked jar package file/jar package dependence.

S502, a rule is taken out from the white/black list.

And S503, matching the rule content with the unique coordinate according to the type of the rule.

S504, whether the matching is successful is judged.

If the matching is successful, S505 is executed. Otherwise, S506 is performed.

S505, outputting 'in white/black list'.

S506, judging whether the white/black name list table has any unchecked rules.

If yes, the process returns to S502. Otherwise, S507 is executed.

S507, output "not in white/black list".

Wherein if all rules fail to match, output "not in the white/black list".

S8: determining whether to submit the latest submission into a library based on the checking result.

In this embodiment of the present specification, after obtaining the check result, it may be determined whether to submit the latest submission content into the library based on the check result.

In some embodiments, when the check result is that the third-party component newly used or modified in the content submitted this time does not have violations such as non-introduced evaluation or use registration, at this time, the content submitted this time may be submitted to storage.

In some embodiments, when the check result is that the version library does not pass, it may be indicated that an illegal condition that evaluation or use registration is not introduced exists in a third-party component newly used or modified in the submitted content, and at this time, the submitted content may be rejected to be put in storage, that is, the submitted content is rejected to be merged into a trunk branch of the version library.

In some implementation scenarios, after the content submitted this time is rejected to be put in storage, the inspection result and the reason causing the inspection result may be sent to the application responsible person, the developer submitted this time, and the like in a preset manner, so as to take corrective measures in time and prevent the code of the application from being deployed in the production environment and bringing potential risks to enterprises. The preset mode may include a telephone call, a mail, a short message, and the like, which is not limited in this specification.

The embodiment of the specification can trigger a corresponding checking process when the application code is submitted to the warehouse, check whether violation conditions such as non-introduced evaluation or use registration exist in all newly used or modified third-party components in the submitted content, reject the submitted content to be warehoused once the violation conditions are found, and send the problem details to a related person in charge so that the person can take automatic mandatory measures to prevent the application code from being deployed in a production environment, thereby remarkably improving the efficiency of using and controlling the third-party components and thoroughly radically treating the condition of using the third-party components in violation.

It is to be understood that the foregoing is only exemplary, and the embodiments of the present disclosure are not limited to the above examples, and other modifications may be made by those skilled in the art within the spirit of the present disclosure, and the scope of the present disclosure is intended to be covered by the claims as long as the functions and effects achieved by the embodiments are the same as or similar to the present disclosure.

From the above description, it can be seen that in the embodiment of the present application, a component check request sent by a version control system may be received, where the component check request includes identification information of a target application, a latest submission content of the target application is obtained from the version control system according to the identification information, and then a component to be checked included in the latest submission content is determined based on the latest submission content and a last submission content, where the component to be checked includes a third-party component that is newly used and/or modified. Further, the component to be checked can be checked, and whether the latest submitted content is submitted into a warehouse or not can be determined based on the checking result. The embodiment of the specification can trigger a corresponding checking process when the application code is submitted to the warehouse, check whether violation conditions such as non-introduced evaluation or use registration exist in all newly used or modified third-party components in the submitted content, and reject the submitted code to be warehoused once the violation conditions are found, so that the efficiency of using and controlling the third-party components can be obviously improved, and the condition that the third-party components are illegally used is effectively reduced.

In the present specification, each embodiment of the method is described in a progressive manner, and the same and similar parts in each embodiment may be joined together, and each embodiment focuses on the differences from the other embodiments. Reference is made to the description of the method embodiments.

Based on the above component management and control method, one or more embodiments of the present specification further provide a component management and control device. The apparatus may include systems (including distributed systems), software (applications), modules, components, servers, clients, etc. that use the methods described in the embodiments of the present specification in conjunction with any necessary apparatus to implement the hardware. Based on the same innovative conception, embodiments of the present specification provide an apparatus as described in the following embodiments. Since the implementation scheme of the apparatus for solving the problem is similar to that of the method, the specific implementation of the apparatus in the embodiment of the present specification may refer to the implementation of the foregoing method, and repeated details are not repeated. As used hereinafter, the term "unit" or "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Specifically, fig. 6 is a schematic block diagram of an embodiment of a component management and control apparatus provided in this specification, and as shown in fig. 6, the component management and control apparatus provided in this specification may include: the system comprises a receiving module 120, an obtaining module 122, a determining module 124, a checking module 126 and a managing module 128.

A receiving module 120, configured to receive a component check request sent by a version control system; the component checking request comprises identification information of a target application;

an obtaining module 122, configured to obtain, according to the identification information, latest submission content of the target application from the version control system;

a determining module 124, which can be used for determining the component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified;

the inspection module 126 may be configured to inspect the component to be inspected to obtain an inspection result;

and a managing module 128, configured to determine whether to submit the latest submission into a warehouse based on the checking result.

It should be noted that the above-mentioned description of the apparatus according to the method embodiment may also include other embodiments, and specific implementation manners may refer to the description of the related method embodiment, which is not described herein again.

The present specification also provides an embodiment of an assembly management and control device, comprising a processor and a memory for storing processor-executable instructions, which when executed by the processor, implement steps comprising: receiving a component checking request sent by a version control system; the component checking request comprises identification information of a target application; acquiring the latest submitted content of the target application from the version control system according to the identification information; determining a component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified; inspecting the component to be inspected to obtain an inspection result; determining whether to submit the latest submission into a library based on the checking result.

It should be noted that the above-mentioned apparatuses may also include other embodiments according to the description of the method or apparatus embodiments. The specific implementation manner may refer to the description of the related method embodiment, and is not described in detail herein.

The method embodiments provided in the present specification may be executed in a mobile terminal, a computer terminal, a server or a similar computing device. Taking an example of the application to a server, fig. 7 is a block diagram of a hardware structure of an embodiment of a component management and control server provided in this specification, where the server may be a component management and control apparatus or a component management and control device in the above embodiment. As shown in fig. 7, the server 10 may include one or more (only one shown) processors 100 (the processors 100 may include, but are not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 200 for storing data, and a transmission module 300 for communication functions. It will be understood by those skilled in the art that the structure shown in fig. 7 is only an illustration and is not intended to limit the structure of the electronic device. For example, the server 10 may also include more or fewer components than shown in FIG. 7, and may also include other processing hardware, such as a database or multi-level cache, a GPU, or have a different configuration than shown in FIG. 7, for example.

The memory 200 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the component management method in the embodiment of the present specification, and the processor 100 executes various functional applications and data processing by executing the software programs and modules stored in the memory 200. Memory 200 may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 200 may further include memory located remotely from processor 100, which may be connected to a computer terminal through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission module 300 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal. In one example, the transmission module 300 includes a Network adapter (NIC) that can be connected to other Network devices through a base station so as to communicate with the internet. In one example, the transmission module 300 may be a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The method or apparatus provided by the present specification and described in the foregoing embodiments may implement service logic through a computer program and record the service logic on a storage medium, where the storage medium may be read and executed by a computer, so as to implement the effect of the solution described in the embodiments of the present specification. The storage medium may include a physical device for storing information, and typically, the information is digitized and then stored using an electrical, magnetic, or optical media. The storage medium may include: devices that store information using electrical energy, such as various types of memory, e.g., RAM, ROM, etc.; devices that store information using magnetic energy, such as hard disks, floppy disks, tapes, core memories, bubble memories, and usb disks; devices that store information optically, such as CDs or DVDs. Of course, there are other ways of storing media that can be read, such as quantum memory, graphene memory, and so forth.

The embodiment of the method or the apparatus for managing and controlling the components provided in this specification may be implemented in a computer by a processor executing corresponding program instructions, for example, implemented in a PC end using a c + + language of a windows operating system, implemented in a linux system, or implemented in an intelligent terminal using android, iOS system programming languages, implemented in processing logic based on a quantum computer, or the like.

It should be noted that descriptions of the apparatus, the device, and the system described above according to the related method embodiments may also include other embodiments, and specific implementations may refer to descriptions of corresponding method embodiments, which are not described in detail herein.

The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the hardware + program class embodiment, since it is substantially similar to the method embodiment, the description is simple, and the relevant points can be referred to the partial description of the method embodiment.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of some modules may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a plurality of sub-modules or sub-units, etc.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus, devices, systems according to embodiments of the invention. It will be understood that the implementation can be by computer program instructions which can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims.

Claims

1. A component management method applied to a persistent integration platform, the method comprising:

receiving a component checking request sent by a version control system; the component checking request comprises identification information of a target application;

acquiring the latest submitted content of the target application from the version control system according to the identification information;

determining a component to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified;

inspecting the component to be inspected to obtain an inspection result;

determining whether to submit the latest submission into a library based on the checking result.

2. The method of claim 1, wherein the inspecting the component to be inspected to obtain an inspection result comprises:

acquiring third-party component information corresponding to the target application; the third-party component information comprises an introduction evaluation table, a black list table, a white list table and a use registration table;

acquiring a reference file corresponding to the component to be checked; the quote file comprises jar package file and/or pom file;

and checking the component to be checked based on the third-party component information and the reference file to obtain a checking result.

3. The method according to claim 2, wherein the inspecting the component to be inspected based on the third-party component information and the reference file to obtain an inspection result comprises:

taking a first file from the reference file;

judging whether the first file is a jar package file or not;

and under the condition that the first file is a jar package file, checking the component to be checked based on the third party component information and the jar package file to obtain a checking result.

4. The method of claim 3, further comprising:

under the condition that the first file is not a jar package file, obtaining jar package dependencies corresponding to the component to be inspected in the first file;

and checking the component to be checked based on the third-party component information and the jar package dependence to obtain a checking result.

5. The method according to claim 4, wherein the obtaining jar package dependencies in the first file corresponding to the component to be checked comprises:

acquiring a first effective model structure and a second effective model structure corresponding to the first file; the first valid model structure is determined based on the current submission and the second valid model structure is determined based on the last submission;

and comparing the first effective model structure with the second effective model structure to obtain the jar package dependence corresponding to the component to be inspected in the first file.

6. The method according to claim 3 or 4, wherein the inspecting the component to be inspected to obtain an inspection result comprises:

checking whether the jar package file or the jar package dependency is in a white list table included in the third-party component information;

when the third party component information is determined not to be in the white list table, checking whether the jar package file or the jar package dependency is in a black list table included in the third party component information;

when the hash value is determined not to be in the blacklist table, calculating the jar package file or the hash value on which the jar package depends;

checking whether the jar packet file or the jar packet dependency is in an introduction evaluation table included in the third-party component information according to the hash value;

and when the judgment result is determined to be introduced into the evaluation table, checking whether the jar packet file or the jar packet dependency is in a use registration table included in the third-party component information according to the hash value to obtain a checking result.

7. The method according to claim 6, wherein the checking whether the jar packet file or the jar packet dependency is in an import evaluation table included in the third party component information according to the hash value further comprises:

and when the component to be checked is determined not to be in the import evaluation table, checking whether the jar package file or the jar package dependency is in the import evaluation table included in the third-party component information according to the file name of the component to be checked to obtain a checking result.

8. The method of claim 6, wherein the checking whether the jar package file or jar package dependency is in a whitelist table or a blacklist table included in the third party component information comprises:

acquiring the jar package file or coordinate information on which the jar package depends;

matching the coordinate information with the rule information in the white name list table or the black name list table in sequence;

under the condition of failed matching, judging whether unmatched rule information still exists in the white list table or the black list table;

determining that the jar package file or the jar package is not dependent on the white list table in the absence of unmatched rule information.

9. An assembly management and control device, comprising:

the receiving module is used for receiving a component checking request sent by the version control system; the component checking request comprises identification information of a target application;

the acquisition module is used for acquiring the latest submitted content of the target application from the version control system according to the identification information;

the determining module is used for determining the components to be checked included in the latest submitted content based on the latest submitted content and the last submitted content; the components to be checked comprise third-party components which are newly used and/or modified;

the inspection module is used for inspecting the component to be inspected to obtain an inspection result;

and the management and control module is used for determining whether to submit the latest submitted content into a warehouse or not based on the check result.

10. An assembly management apparatus comprising at least one processor and a memory storing computer-executable instructions that, when executed by the processor, implement the steps of the method of any one of claims 1-8.

11. A computer-readable storage medium having stored thereon computer instructions which, when executed, implement the steps of the method of any one of claims 1 to 8.