CN119743472A - Interface metadata processing method, device, electronic device and storage medium - Google Patents

Abstract

The present invention discloses an interface metadata processing method, device, electronic device and storage medium, including: collecting business project information according to a mirror file, determining the specific path of the business project in the mirror file; performing security risk detection on the content of the mirror file, detecting whether there is a duplicate packaged file, and uploading the detection result to a server; searching the interface file path in the mirror file through a decompilation technology according to the specific path of the project, and decompressing the corresponding interface belonging file and configuration file to a temporary directory; searching the context configuration of the business project from the configuration file, and searching the corresponding interface address, request method and access resource list from the interface belonging file; uploading the context configuration, interface address, request method and access resource list as the interface metadata of the business project to the server. The present invention improves the accuracy and comprehensiveness of the collection and analysis of interface metadata, and can be applied to the field of information technology.

Description

Interface metadata processing method and device, electronic equipment and storage medium

Technical Field

The present invention relates to the field of information technologies, and in particular, to a method and an apparatus for processing interface metadata, an electronic device, and a storage medium.

Background

The interface is a set of software functions packaged from the server side software facing the external demands of the software, and the functions are often directly used for serving end service users or external other systems, and the problem and risk of the visible interface and the items to which the visible interface belongs are important to timely identification and repair before formally deploying to the production environment.

The automatic discovery and analysis of the interface metadata have positive significance for analyzing the quality and security risk of the mirror image file of the item to which the interface belongs and deeply quantifying and analyzing the resource consumption of the service from the dimension of the interface. The acquisition and analysis result of the interface metadata can provide deep quantized data, can help discover and solve possible risks and operation quality information of service items and interfaces thereof as early as possible before the service is deployed in a production environment, can effectively reduce labor cost in related work, and improves the effect and efficiency of works such as internet software operation and resource management. However, the collection and analysis of the interface metadata in the prior art have defects in accuracy and comprehensiveness, are not easy to expand, and cannot fully exert the value of the interface metadata.

Term interpretation:

The interface, also called API, refers to an abstraction of a set of software functions that a server application opens up for access by different forms of software, such as web pages, mobile clients, or other server applications, typically some predefined functions, in order to provide the application and developer the ability to access a set of routines based on certain software or hardware without having to access the source code or understand the details of the internal operating mechanisms. In the description of the invention, the interface refers in particular to an interface that is open via the HTTP/HTTPs protocol.

Interface metadata refers to information of the interface itself, items to which the interface belongs, release (to be deployed) files of the items, and information of various resources required to be called by the interface operation.

LoRA (Low-Rank Adaptation of Large Language Models) is a plug-in network capable of training out a drawing/IP/character by using a small amount of data on the premise of not modifying the SD (Stable Diffusion) model, and capable of reducing the GPU requirement for training the large language model to about one third of the original one, thereby being beneficial to training the private large language model on the basis of the large language model.

Disclosure of Invention

The present invention aims to solve at least one of the technical problems existing in the prior art to a certain extent.

Therefore, an object of the embodiments of the present invention is to provide an interface metadata processing method, which realizes automatic discovery and collection and analysis of interface metadata, and improves accuracy and comprehensiveness of collection and analysis of interface metadata.

Another object of an embodiment of the present invention is to provide an interface metadata processing apparatus.

In order to achieve the technical purpose, the technical scheme adopted by the embodiment of the invention comprises the following steps:

in one aspect, an embodiment of the present invention provides a method for processing interface metadata, including the following steps:

reading an image file of a service item, acquiring service item information according to the image file, and determining an item specific path of the service item in the image file;

detecting the security risk of the content of the mirror image file, detecting whether a repeated package file exists or not, and uploading a detection result to a server;

Searching an interface file path in the mirror image file through a decompilation technology according to the project specific path, and decompressing a file and a configuration file which correspond to the interface to a temporary directory;

Searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

and uploading the context configuration, the interface address, the request method and the access resource list to a server as interface metadata of the service item.

Further, in one embodiment of the present invention, the interface metadata processing method further includes the steps of:

updating a software security information base of a server according to the interface metadata, and carrying out project early warning according to the interface metadata and the detection result;

generating a function description corresponding to each interface according to the interface metadata;

Filtering invalid access logs according to the interface metadata, performing abnormal access analysis, further calculating effective access quantity and access quality of each interface, and determining invalid/low-efficiency interfaces according to the effective access quantity and the access quality;

classifying each interface according to the function description to obtain a plurality of interface categories, and further determining the interface number, the interface distribution position and the total effective access quantity of each interface category;

And constructing an interface access topology according to the access resource list, and providing the interface access topology for the client through the server.

Further, in one embodiment of the present invention, the collecting service item information according to the image file, and determining an item specific path of the service item in the image file specifically includes:

Searching a preset file name field in a first layer of the mirror image file to obtain a target JSON file;

Analyzing the target JOSN file to obtain the service item information, wherein the service item information comprises an item maintainer, a service item file working path, a service application file name, mirror image construction time, a mirror image file size, a mirror image file MD5 code, an operation environment requirement, an externally exposed port number and basic mirror image data;

Reading compressed files of all folders in the mirror image file layer by layer, and judging whether the compressed files contain the service project file working paths and the service application file names;

if yes, determining the project specific path according to the file path of the compressed file.

Further, in one embodiment of the present invention, the searching the interface file path in the image file according to the project specific path through decompilation technology, and decompressing the corresponding interface belonging file and configuration file to the temporary directory specifically includes:

Searching the compiled class file in the mirror image file according to the project specific path;

decompiling the class file to obtain class definition information, determining an interface corresponding to the class file according to the class definition information, and further determining the interface file path;

Creating a temporary directory, determining a corresponding file to which the interface belongs and the configuration file according to the interface file path, and decompressing the file to which the interface belongs and the configuration file to the temporary directory.

Further, in an embodiment of the present invention, the performing item pre-warning according to the interface metadata and the detection result specifically includes:

determining whether the image file has safety risk or not and whether the image file has repeated package files or not according to the detection result;

When the mirror image file has security risk and/or the file is repeatedly packaged, determining a project maintainer according to the interface metadata, and sending the project early warning to the project maintainer;

the project early warning is used for reminding the project maintainer to formally deploy the mirror image file after repairing the mirror image file.

Further, in one embodiment of the present invention, the filtering the invalid access log according to the interface metadata, and performing abnormal access analysis, so as to calculate an effective access amount and an access quality of each interface, and determine an invalid/inefficient interface according to the effective access amount and the access quality, which specifically includes:

Determining the interface address, the request method and the access resource list according to the interface metadata;

Determining a corresponding target service according to the access resource list, inquiring an access log of the target service according to the interface address and the request method to obtain an effective access log, and taking the access log which does not belong to the effective access log as the invalid access log;

Counting an abnormal access source IP and a geographical area to which the abnormal access source IP belongs according to the invalid access log, and determining an interface actually accessed by the abnormal access source IP and a corresponding abnormal access amount;

Counting the effective access quantity, the access error times and the access performance data of each interface according to the effective access log, and determining the access quality of the corresponding interface according to the abnormal access quantity, the access error times and the access performance data;

And judging whether each interface is an invalid/low-efficiency interface according to the effective access quantity, the access quality and a preset threshold value.

Further, in one embodiment of the present invention, the constructing an interface access topology according to the access resource list specifically includes:

Determining the calling relation between each interface and the external resource instance according to the access resource list;

taking each interface and a plurality of external resource instances as nodes, and determining the topological connection relation and the actual calling direction between each node according to the calling relation;

And connecting each node according to the topology connection relation and the actual calling direction to obtain the interface access topology.

In another aspect, an embodiment of the present invention provides an interface metadata processing apparatus, including:

the system comprises a project path determining module, a service project processing module and a service project processing module, wherein the project path determining module is used for reading an image file of a service project, collecting service project information according to the image file and determining a project specific path of the service project in the image file;

The image file content detection module is used for carrying out security risk detection on the content of the image file, detecting whether a repeated package file exists or not, and uploading a detection result to the server;

The interface file searching module is used for searching an interface file path in the mirror image file through a decompilation technology according to the project specific path, and decompressing the corresponding interface belonging file and the configuration file to a temporary directory;

The interface metadata searching module is used for searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

and the interface metadata uploading module is used for uploading the context configuration, the interface address, the request method and the access resource list to a server as the interface metadata of the service item.

In another aspect, an embodiment of the present invention provides an electronic device, where the electronic device includes a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for implementing a connection communication between the processor and the memory, where the program, when executed by the processor, implements an interface metadata processing method as described above.

In another aspect, an embodiment of the present invention further provides a storage medium, where the storage medium is a computer readable storage medium, and the storage medium stores one or more programs, and the one or more programs are executable by one or more processors to implement an interface metadata processing method as described above.

The advantages and benefits of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

The embodiment of the invention reads the image file of the service item, acquires the service item information according to the image file, determines the item specific path of the service item in the image file, carries out security risk detection on the content of the image file, detects whether a repeated package file exists or not, uploads the detection result to a server, searches the interface file path in the image file according to the item specific path through decompilation technology, decompresses the corresponding interface belonging file and configuration file to a temporary directory, searches context configuration of the service item from the configuration file, searches the corresponding interface address, request method and access resource list from the interface belonging file, and uploads the context configuration, the interface address, the request method and the access resource list as interface metadata of the service item to the server. The embodiment of the invention realizes the automatic discovery and collection analysis of the interface metadata, and improves the accuracy and the comprehensiveness of the collection and analysis of the interface metadata.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following description will refer to the drawings that are needed in the embodiments of the present invention, and it should be understood that the drawings in the following description are only for convenience and clarity to describe some embodiments in the technical solutions of the present invention, and other drawings may be obtained according to these drawings without any inventive effort for those skilled in the art.

FIG. 1 is a flowchart illustrating steps of a method for processing interface metadata according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of an implementation framework of an interface metadata processing method according to an embodiment of the present invention;

FIG. 3 is a flowchart illustrating another step of the method for processing interface metadata according to an embodiment of the present invention;

Fig. 4 is a step flowchart of step S101 provided in the embodiment of the present invention;

fig. 5 is a step flowchart of step S103 provided in the embodiment of the present invention;

fig. 6 is a step flowchart of step S201 provided in the embodiment of the present invention;

fig. 7 is a step flowchart of step S203 provided in the embodiment of the present invention;

FIG. 8 is a flowchart illustrating a step of step S205 according to an embodiment of the present invention;

FIG. 9 is a schematic diagram of an interface metadata processing apparatus according to an embodiment of the present invention;

fig. 10 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present invention;

Fig. 11 is a schematic structural diagram of a storage medium according to an embodiment of the present invention.

Detailed Description

Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative only and are not to be construed as limiting the application. It should be noted that although functional block division is performed in a system diagram and a logic sequence is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the block division in the system diagram or the sequence in the flowchart. The step numbers in the following embodiments are set for convenience of illustration only, and the order between the steps is not limited in any way, and the execution order of the steps in the embodiments may be adaptively adjusted according to the understanding of those skilled in the art.

In the description of the present application, the plurality means two or more, and if the description is made to the first and second for the purpose of distinguishing technical features, it should not be construed as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the precedence of the indicated technical features. Furthermore, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the application only and is not intended to be limiting of the application.

The related art discloses a private warehouse Docker mirror image information acquisition system and an acquisition method thereof, wherein a mirror image to be acquired is obtained from a local private mirror image warehouse and a mirror image layer for information acquisition is added to the local private mirror image warehouse to construct a new mirror image, then a container of the new mirror image is started, mirror image content is read based on Docker service, and a target compressed file in the mirror image is supported to be sent to a mirror image acquisition center through a network. The mirror image information acquired by the scheme only comprises a mirror image id, a label, a warehouse and an acquisition result, interface information contained in a service system in the mirror image can not be acquired, and a new dock mirror image needs to be packed and operated, and when the mirror image of the service system is considered to be about 500MB and partially exceeds 1GB, a large amount of information of a project needs to be acquired, the scheme wastes magnetic discs, networks and computing resources.

The related art also discloses a difference analysis method, a device, a storage medium and a device, which can extract jar packets from a dock mirror image file, and then obtain interface information from the jar file by using a preset class loader. The scheme has the defects that 1) accurate information needs to be manually configured in advance, the acquisition of the information is cumbersome, partial information is difficult or even cannot be accurately acquired in advance due to technical thresholds, for example, a class loader which can be truly available (can load classes without exception and can acquire information such as notes of the classes) is required to be specially developed for partial projects, the scheme does not provide a technical method for automatically acquiring all preset information, and 2) the acquired interface information is limited, and important information related to practical application such as interface dependence and potential safety risks cannot be found out.

It has been proposed in the industry to extract interface metadata from source code. The method means that tools for analyzing information such as different code branches of edition control services such as Git, SVN and the like are required to be developed, otherwise, manual configuration is required, all interface information cannot be accurately analyzed due to different code styles, so that development, design difficulty and workload of a source code analysis tool are increased, and in addition, information which can be found by the scheme is limited or even useless due to the fact that current network deployment environment information is lacked in a development stage, design and implementation of the development stage are possibly repeatedly changed and the like.

In summary, the collection and analysis of the interface metadata in the prior art have defects in accuracy and comprehensiveness, are not easy to expand, and cannot fully play the value of the interface metadata.

The invention provides an interface metadata processing method, an interface metadata processing device, electronic equipment and a storage medium, so as to achieve the following purposes:

1) Collecting information of projects from deployment (release) files of the service projects to form project metadata, searching paths of compression projects containing defined interfaces from the deployment files, decompressing corresponding files from the deployment files according to the paths, and decompiling the files to obtain code files with uniform styles;

2) The method comprises the steps of automatically acquiring and analyzing deployment files and code files to obtain rich information, wherein one class comprises interfaces (APIs), a complete method signature of each interface, whether one interface calls other interfaces, information such as external resources and versions thereof used by each interface respectively, a mode of using resources by each interface, library files relied by each interface, security configuration of each interface, data validity verification conditions, abnormal processing conditions and other business items and interface metadata sets thereof;

3) A series of analysis and verification are supported from interface dimensions, wherein the analysis and verification comprises ① of constructing an interface access topology according to discovered interface metadata, ② of comparing and analyzing specific security risks and wrong mirror image packaging behaviors of project mirror images according to disclosed software security hole data and verifying repair conditions, ③ of analyzing service access logs according to interface addresses and eliminating logs of actual access link errors of external access behaviors, so that the access quality and actual effective access quantity of each interface are accurately calculated, further supporting real consumption of cloud network resources and the like of the interfaces and the service dimensions at any time, improving service guarantee and service alarm convergence, analysis efficiency and effect, and assisting quantitative analysis and optimization of cloud network resource cost.

The interface metadata processing method provided by the embodiment of the application can be applied to a terminal, a server and software running in the terminal or the server. In some embodiments, the terminal may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a set-top box, etc., the server may be configured as an independent physical server, may be configured as a server cluster or a distributed system formed by a plurality of physical servers, and may be configured to provide cloud services, a cloud database, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and cloud servers for basic cloud computing services such as big data and artificial intelligent platforms, and the software may be an application for implementing the interface metadata processing method, but is not limited to the above form.

The application is operational with numerous general purpose or special purpose computer system environments or configurations. Such as a personal computer, a server computer, a hand-held or portable device, a tablet device, a multiprocessor system, a microprocessor-based system, a set top box, a programmable consumer electronics, a network PC, a minicomputer, a mainframe computer, a distributed computing environment that includes any of the above systems or devices, and the like. The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In the embodiments of the present application, when related processing is performed according to user information, user behavior data, user history data, user location information, and other data related to user identity or characteristics, permission or consent of the user is obtained first, and the collection, use, processing, and the like of the data comply with related laws and regulations and standards of related countries and regions. In addition, when the embodiment of the application needs to acquire the sensitive personal information of the user, the independent permission or independent consent of the user is acquired through popup or jump to a confirmation page and the like, and after the independent permission or independent consent of the user is definitely acquired, the necessary relevant data of the user for enabling the embodiment of the application to normally operate is acquired.

Firstly, an implementation framework of the interface metadata processing method in the embodiment of the invention is described, as shown in fig. 2, which is a schematic diagram of an implementation framework of the interface metadata processing method provided in the embodiment of the invention, and the implementation framework comprises a server, a client and a service project, wherein the client is focused on publishing (deploying) files from the service project to automatically analyze and obtain metadata of the project and interfaces thereof, the client can be conveniently deployed and used in professional companies under groups, the server is more responsible for integrating, processing, storing and analyzing various data reported by different clients, including forming a calling relationship and resource access topology between a series of interfaces, the server is intensively deployed as a cluster service, the metadata automatically discovered by the client can be saved in a relational database or a NoSQL database, the server provides a database respectively containing tables of saved projects, interface metadata and software security risk information disclosed by the industry, and interface calling relationship topology data can be saved in a graph database. In addition, the client is also responsible for detecting the security risk of the service project release file, verifying the solution, analyzing the service access log according to the interface metadata, forming access/call topology among projects (release files) based on the interface call topology, and interface operation quality topology, and providing management and audit functions of abnormal information such as inactive interfaces, unofficially enabled domain names, not found configured domain names, abnormal interface addresses and the like based on the service access log.

The embodiment of the invention can read wide interface metadata from the release file of the service program, comprises interface addresses, request methods, complete method signature and request parameters which the interface belongs to, which resources are used (called) by the interface, error and exception handling mechanisms of the interface, safety configuration, development frameworks of the interface and third party dependency libraries (which jar files are used for Java programs) and version information thereof, can analyze and obtain information of how many times the database is accessed inside one interface, middleware, whether sensitive data are safely stored, whether necessary data verification and cleaning are carried out or not, and the like, can conveniently find out the problem of service deployment files (especially mirror image files), for example, repeatedly package partial files, is favorable for conveniently integrating other programming languages for joint development based on a Linux system through a Bash script, can reduce development workload, improve development efficiency, and can also be combined with practical and flexible adjustment of partial details.

The following describes the process of realizing the collection of interface metadata, i.e. parsing the project from the dock image file of the service project, by the client and the interface metadata thereof.

Referring to fig. 1, a flowchart illustrating steps of an interface metadata processing method provided by an embodiment of the present invention is provided, and referring to fig. 1, the embodiment of the present invention provides an interface metadata processing method, which specifically includes the following steps:

S101, reading an image file of a service item, acquiring service item information according to the image file, and determining an item specific path of the service item in the image file;

S102, carrying out security risk detection on the content of the mirror image file, detecting whether a repeated package file exists or not, and uploading a detection result to a server;

s103, searching an interface file path in the mirror image file through a decompilation technology according to the project specific path, and decompressing the corresponding file and configuration file of the interface to a temporary directory;

S104, searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

s105, uploading context configuration, interface address, request method and access resource list as interface metadata of service items to a server.

Referring to fig. 4, a step flow chart of step S101 provided by the embodiment of the present invention is shown, and referring to fig. 4, further as an alternative implementation manner, the method includes collecting service item information according to an image file, and determining an item specific path of a service item in the image file, where the method specifically includes:

S1011, searching a preset file name field in a first layer of the mirror image file to obtain a target JSON file;

S1012, analyzing a target JOSN file to obtain service item information, wherein the service item information comprises an item maintainer, a service item file working path, a service application file name, mirror image construction time, mirror image file size, mirror image file MD5 code, running environment requirements, externally exposed port number and basic mirror image data;

s1013, reading compressed files of all folders in the mirror image file layer by layer, and judging whether the compressed files contain service project file working paths and service application file names;

S1014, if yes, determining a project specific path according to the file path of the compressed file.

Referring to fig. 5, further as an alternative implementation manner, according to a step flow chart of step S103 provided by the embodiment of the present invention, referring to fig. 5, an interface file path in an image file is searched by a decompilation technology according to a project specific path, and a file and a configuration file to which a corresponding interface belongs are decompressed to a temporary directory, which specifically includes:

S1031, searching the compiled class file in the mirror image file according to the project specific path;

s1032, decompiling the class file to obtain class definition information, determining an interface corresponding to the class file according to the class definition information, and further determining an interface file path;

s1033, creating a temporary directory, determining the corresponding files and configuration files of the interface according to the interface file path, and decompressing the files and configuration files of the interface to the temporary directory.

Specifically, the procedure for parsing the project and its interface metadata from the dock image file of the service project is as follows:

1) Before a service item is newly online or updated to a production environment, an image file to be deployed to the production environment for running of the service item deployed to the production environment can be obtained from an image warehouse or CI/CD service at any time, the file is actually a file with an extension name tar, and the content of the compressed file in the archiving format is read through a file input stream;

2) The first layer of the compressed file inquires a file like 8ba 95110 c899046f56b0ec 819a4d06fb 2f 526098825688b 880 bee.json according to the length of the file NAME and the range of characters forming the file NAME, reads and analyzes the content in the file according to the JSON format after finding, obtains a maintainer (corresponding to maintainer fields in the file) of a corresponding item, a Working path (corresponding to Working Dir fields) of a file of an embedded actual service item, the file NAME (corresponding to APP_HOME and APP_NAME fields respectively) of a service application in the compressed file, the image construction time (final created), the size of an image file, the md5 code of the image file, the running environment requirement (JDK/JRE, language requirement), the externally exposed port number, the used basic image and the like, and can be expanded according to the actual Working requirement and the enterprise self-specification;

3) Further reading the compressed files in each folder in the mirror image file layer by layer, reading the content in each newly found compressed file based on the content, checking whether the compressed file in the inner layer contains the path of the service application obtained in the last step and the service file name, if so, finding the path of the file packed after compiling the service system (only one compressed file) in the mirror image, recording the path, otherwise, checking according to the conventional/standard path of enterprises about the file;

4) And according to the format of the corresponding file, continuing to read the packaged file of the service item found from the innermost layer of the mirror image based on the memory completely. The key points include:

a. According to the current situation that projects developed by different software platforms are always a compressed file after being released, according to the layout/distribution specifications of various contents in the corresponding type of files, for example, the projects developed by Java language are always files with extension names of jar, war or ear, the dependency library of the projects developed based on Spring Boot is always under the BOOT-INF/lib path of jar files, the early Java WEB project is always under the WEB-INF/classes path, and the names of the compressed items under the catalogue where the project dependency is located in the compressed files are the file names corresponding to the dependency.

B. for the situation that the software release file is directly packed into the docker mirror image without packing compression, compared with a method of packing and then packing the software release file into the mirror image according to a technical platform and a framework selected by a service project, the method is actually simplified, because required file information can be directly read according to the same file filtering and positioning rules, the application compression file does not need to be read, and other analysis processing logics are unchanged. In this case, it should be noted that in parsing compressed stream data, for folders (e.g., business dependencies) packed under a part of the technical platform, it is necessary to iteratively parse the compressed items thereof in a folder manner.

C. according to the characteristics of the path and the file name of the file and in combination with the specification of the enterprise about the related name, the compression item which really needs to be processed can be positioned, so that various business items which are designed according to the MVC mode, the DDD mode and other architecture modes can be correctly processed. The names of all base library and third party library files on which the business project depends can be obtained by deeply searching the content of the file to obtain the names of each compression term, the common file names simultaneously contain file version numbers, if the dependent library file names do not contain the version numbers, the corresponding compression files are continuously read, and the dependent version numbers are read from the MANIFEST.MF files under the META-INF directory;

5) The client-side inquires the service-side of which software and library are confirmed to have security hole information in the last period of time (the information is often disclosed in time on the network). Comparing the results, searching whether each dependence of the obtained business project has a security risk or loophole, if so, recording a concrete file with the risk and a repair suggestion obtained according to industry public information;

6) And continuously checking other parts of the mirror image based on the memory, including compressing file names contained in the files, comparing the file names with the disclosed security information in the previous step, and if vulnerabilities or security risks are found for other files outside the project dependence, recording the corresponding files and paths, risks and related project information thereof in the mirror image and reporting the files and the risks and the related project information to a server. The data obtained up to this point is used as project metadata to be uploaded to a server for storage;

7) Aiming at the situation that the image is compressed file, and multiple layers of compressed files with different formats are nested in the compressed file, so that the same file is easily compressed by different image layers, checking if the value of the size of the project image file exceeds a certain threshold (configurable), checking if the rest content of the image contains service projects with the same name or dependent files thereof, if the corresponding file is found to be repeatedly packed, recording the repeated file, the path of the repeated file and the information of related projects, and reporting the repeated file and the path to a server;

8) Reading 3) obtaining the content in the service project release file, finding the compiled class file, decompiling the content of the class file line by line based on the memory until confirming that the corresponding class defines a service interface according to the class definition information;

9) A random folder is newly built in the temporary file directory of the system, each interface class found above and the Service class called by the interface class are decompiled, and the whole content of the decompiled result is written under the random folder. The control of only decompiling the byte codes of the needed class or interface can be realized through the black list and the white list of the class or interface;

10 Finding the configuration of the service built-in according to the relative path of the class file in the service release file, and decompressing all configuration files under the newly built file according to the same relative path;

11 Using operating system command and tool to find the possible value of context-path configuration item in properties, yml, yaml format configuration file, using the found content as context configuration of service item;

12 Checking the configuration files of the project according to the naming rules of the configuration files of the project, the naming rules of enterprises on the files, and the like (extensible) such as application-dev. Yml, application-prod. Yml, application-test. Yml, and the like, checking which configuration files exist, whether dead IP addresses are written, passwords are written directly, and information such as types, instances, connection, authentication, namespaces and the like of external services such as configuration files which are unnecessary for formal deployment and are not used, configuration centers used by the project, and the like;

13 From the project configuration, a project third party checking some built-in HTTP interface services should only be used in non-production environments such as development, testing, etc. and should not be deployed as part of the business system to the production environment, e.g., JDBC driver druid, project code document service swagger, etc., check to see if its corresponding configuration item d.stat.http.enable already exists and set to false, and for the latter, check to see if either the relevant jar (not in the production environment) is included or if its start-up service is disabled by a specific configuration. Reporting the problems found here to a server for processing;

14 For the current situation that different programming languages and development platforms commonly use annotation definition interfaces, for example, a Spring framework mainly uses RestController, requestMapping, getMapping, postMapping, putMapping, deleteMapping annotation development interfaces, and some annotations can be written on a method only, so that it is necessary to analyze corresponding interface data under various purposes of the annotations according to the class or the method of the annotations, otherwise, missing interface information or inaccurate data can be caused. The method comprises the steps of assembling and searching the code files obtained above according to the sequence of find, grep and a custom program through a pipeline, searching the content of any one of target notes and the next row of the target notes from the code files respectively, so that a query result always consists of two rows in pairs, wherein the two rows of the content are the file in which ① found information is located and the actual definition of any note in the code, the file in which ② found information is located and the actual definition of the class or method corresponding to the note obtained in the last row, the method comprises all parameters supported by the corresponding interface, and query result information in the format is transmitted to the next step through the pipeline;

15 Analyzing every two lines as a processing unit to obtain a file path containing file names, notes and whether the content below the file path is an object list of class definition, and then circularly processing each element in the object list, wherein if one object does not contain the class definition (the object is described to contain the definition of a class method, so that a complete method signature containing method names, parameters of the method and possible ejection exception can be obtained) and the notes contain interface address information, the object is a new interface, if the object is a class definition and the notes contain interface address information, the path defined by the class is recorded, if the object is not the class definition and the object processed by the last time belongs to the same file, a new interface is also found, and the context obtained above and the path information obtained here in such a way are combined to obtain an interface path (the core part of complete interface link under the production environment), and the accurate and complete information of each interface in the code can be ensured through the scheme according to each interface note;

16 The specific codes of the interface method signature obtained from the above can be obtained, and then the information of other interfaces, databases, caches, message queues and other resources which can be accessed by each interface when being executed is searched from the interface implementation codes through middleware or database client tool class information of different protocols, wherein the information comprises the actual addresses, ports, access modes, access triggering conditions and the access times of one interface call to each resource. The information can define the access and corresponding relation between the interface and the external resource;

17 Similarly, it can automatically find out which interface processes the exception and error and its mode (e.g. whether to directly throw Exception exception, record log and complete recorded information, etc.), and respond to the processing mode, then check out whether there is IP address and other domain name outside service from the implementing code of interface, find out whether there is password according to the need of accessing external resource, check the length, complexity, commonality and repeated item of the password content after finding out the password, thereby find out the weak password information and record the purpose of password. It is also possible to find out here whether the value settings of some of the annotations, including enterprise custom annotations, are reasonable, e.g. whether the annotations controlling the environment to which swagger applies exclude the production environment, whether the annotations controlling the excluded startup class are configured properly, etc. The problem found here can be similarly checked again, compared after the project is updated to confirm whether it has been repaired;

18 Uploading the information obtained above as items and interface metadata to a server for storage, and then deleting the temporary files and folders generated in the process from the client.

It should be noted that if the release file of the service item is not a mirror image, for example, jar or war file, the technical scheme in this case is actually a subset of the above scheme, namely, firstly, the uniform resource descriptor object corresponding to the file is obtained, and then, the content of the release file is similarly analyzed and processed according to the above scheme by adopting a targeted compressed file mode.

Compared with the scheme of obtaining interface addresses and service call topology information based on logs, injecting byte codes into a process of a service system in a running process, directly modifying research and development codes and the like, the scheme is simple to realize, the corresponding client tool has low resource consumption in running, can be flexibly deployed on any server (including non-production servers), does not need to have any influence on codes in the developing process and the service system in the running process, can obtain the extensive metadata of interfaces and service projects to which the interfaces belong, does not need to use originally developed codes, can avoid cross-department coordination and code security problems, can timely discover and process security risks such as loopholes possibly existing in the service system before the projects are on line, and can obtain deeper data which cannot be obtained by other schemes such as the specific times of calling external resources by the interfaces and the characteristics on the interfaces from the interfaces, such as a finer granularity of the interfaces.

The process of the server to implement the interface metadata analysis is described below.

The common service access log analysis service has the defects that a large number of static files (css, js, pictures and the like) and logs of abnormal access behaviors are contained outside an actual access log of an interface, whether the logs of normal service access behaviors are logs of normal service access behaviors or not is difficult to judge only by data of the abnormal logs, and the interfaces with low inactivity or activity rate are easily ignored only based on the logs for a period of time, so that the efficiency, quality and operation efficiency of the research and development of the interfaces cannot be evaluated by using log data.

In order to solve the problems, the embodiment of the invention combines the actual access log of the service item to calculate the link information of the interface including the accessed (normal and abnormal access) condition and the error interface, and further can obtain the information of real access quantity, few or never accessed interfaces and the like after the service item is deployed on line.

In addition, the related art discloses a vulnerability restoration method, a vulnerability restoration device and a container cluster management system, which can also find vulnerabilities in images, wherein the vulnerabilities need to be extracted from deployment configuration files of items, or after the images are decompressed on a disk, the decompressed files are read/traversed to find out an operating system of the images, software packages and version numbers thereof, and whether the vulnerabilities exist or not is judged according to the information. The scheme has the defects that ① needs to rely on other files except the project deployment file, ② does not have a scheme for successfully mirroring compressed files in different formats, ③ cannot detect vulnerabilities of software packages which are not installed to a mirror image operating system and cannot detect vulnerabilities of software packages which do not contain version numbers in file names, if the software vulnerabilities are located in the files packaged by the project and then embedded into the mirror image, the scheme does not indicate whether processing is possible, ④ has low performance, and considering that the mirror image files often have hundreds of MB or more, decompressing a large number of mirror image files also has requirements on disk space. The embodiments of the present invention can also overcome the above-described problems.

Referring to fig. 3, which is a flowchart illustrating another step of the interface metadata processing method provided by the embodiment of the present invention, further as an alternative implementation manner, the interface metadata processing method further includes the following steps:

S201, updating a software security information base of a server according to interface metadata, and carrying out project early warning according to the interface metadata and a detection result;

S202, generating a function description corresponding to each interface according to the interface metadata;

S203, filtering an invalid access log according to the interface metadata, performing abnormal access analysis, further calculating the effective access quantity and the access quality of each interface, and determining an invalid/low-efficiency interface according to the effective access quantity and the access quality;

S204, classifying each interface according to the function description to obtain a plurality of interface categories, and further determining the interface number, the interface distribution position and the total effective access quantity of each interface category;

s205, constructing an interface access topology according to the access resource list, and providing the interface access topology for the client through the server.

Referring to fig. 6, a step flow chart of step S201 provided by the embodiment of the present invention is shown in fig. 6, and further as an alternative implementation, item early warning is performed according to interface metadata and a detection result, which specifically includes:

S2011, determining whether the image file has a safety risk or not and whether the image file has repeated packaging files or not according to a detection result;

s2012, when the mirror image file has security risk and/or the file is repeatedly packaged, determining an item maintainer according to the interface metadata, and giving an item early warning to the item maintainer;

the project early warning is used for reminding a project maintainer to formally deploy the image file after repairing the image file.

Referring to fig. 7, a step flow chart of step S203 provided by the embodiment of the present invention is shown, and referring to fig. 7, further as an alternative implementation manner, an invalid access log is filtered according to interface metadata, and abnormal access analysis is performed, so as to calculate an effective access amount and an access quality of each interface, and determine an invalid/inefficient interface according to the effective access amount and the access quality, which specifically includes:

s2031, determining an interface address, a request method and an access resource list according to the interface metadata;

s2032, determining a corresponding target service according to the access resource list, inquiring an access log of the target service according to the interface address and the request method to obtain an effective access log, and taking the access log which does not belong to the effective access log as an invalid access log;

S2033, counting an abnormal access source IP and a geographical area to which the abnormal access source IP belongs according to the invalid access log, and determining an interface actually accessed by the abnormal access source IP and a corresponding abnormal access amount;

S2034, counting the effective access quantity, the access error times and the access performance data of each interface according to the effective access log, and determining the access quality of the corresponding interface according to the abnormal access quantity, the access error times and the access performance data;

s2035, judging whether each interface is an invalid/low-efficiency interface according to the effective access quantity, the access quality and a preset threshold value.

Referring to fig. 8, which is a step flowchart of step S205 provided by the embodiment of the present invention, further as an alternative implementation manner, an interface access topology is constructed according to an access resource list, which specifically includes:

s2051, determining the calling relation between each interface and an external resource instance according to the access resource list;

S2052, using each interface and a plurality of external resource instances as nodes, and determining the topological connection relation and the actual calling direction between each node according to the calling relation;

s2053, connecting all nodes according to the topological connection relation and the actual calling direction to obtain the interface access topology.

Specifically, the process of the server for realizing the interface metadata analysis is as follows:

1) The service end stores the interface metadata of the service items obtained above, including which image files, items and interfaces thereof are analyzed. In addition, a local software security information base is established and continuously updated according to the latest security vulnerability information of the industry disclosed software and public base;

2) The server gathers all the loopholes and the security risk information discovered above, alarms to maintenance persons of related projects by taking the projects as units, and reminds that the problems should be formally deployed after the problems are repaired. And then after the new mirror image is constructed, automatically checking whether the corresponding file in the service mirror image is updated and the problem is repaired according to the steps, if so, recording the problem solving time according to the 'modification time' field in the corresponding compressed file, otherwise, recording unrepaired file and warning the user.

3) The method can be used for obtaining the code of the interface address and the interface implementation method, can be used for adding simple introduction of project business, adopts LoRA to train and fine tune the functional description of the interface based on thousands of questions or other large language models, can obtain a private large language model which is suitable for the research and development specifications and habits of an enterprise and can accurately judge the purpose of the interface by adopting the method, and then adopts LoRA to combine the trained model data and the original model data to obtain new large model data. Generating the functional and usage descriptions of the interfaces found above based on the addresses, codes and item information of the interfaces using the new large language model as part of the metadata of each interface;

4) Inquiring the access log of the corresponding service according to the automatically discovered accurate interface address, all the request parameters supported by the interface and the request method supported by the interface, wherein the log with the same combination of the actual access address, the request method and the request parameters as a certain interface link is the effective access log, and excluding the invalid access log from the public network (such as the interface and the data scanning thereof, the attack business system and the like), and excluding the access log of other project static files;

5) The abnormal access judgment and analysis are carried out, namely, an abnormal access source IP and a geographical area to which the abnormal access source IP belongs are searched according to the information obtained in the last part, the access log of the correct interface address actually accessed by each access source is checked, and the interface concerned by abnormal behaviors and the abnormal access quantity of the corresponding interface are calculated;

6) According to the rest effective access log, calculating the access quantity, the last access time and the access quality (the number of access errors, the number of abnormal access times, the access performance and the like) data of each interface in a certain time, and calculating the average, the maximum, the minimum, the variance and the like of each index;

7) According to interface lists of actual project modules, micro-services, projects and product dimensions, which interfaces are specifically contained in the lists of each dimension are supported to be adjusted according to actual work requirements, and the access quantity and the access/operation quality of each dimension of the modules, the micro-services, the projects and the products are calculated. Further classifying all interfaces into different grades according to the access quantity and the access quality, highlighting all interfaces with higher grades, worse grades, no access quantity or access quantity lower than a certain threshold, and providing decompiled codes of the corresponding interfaces for viewing at any time through a UI according to the project release file;

8) According to the access quantity and the access quality, the access quantity, the access quality and the corresponding code quantity of each type of interface are calculated and analyzed by combining the interface code quantity obtained by decompiling the files compiled by the interfaces or the interface code quantity obtained by calculating from the actual source codes, the interface with the access quantity lower than a certain threshold value can be used as an invalid or low-efficiency interface, and the data can be used for analyzing and comparing the application efficiency of the actually developed codes and combining the interfaces with the actual setting of different efficiency levels, and the interfaces with different code efficiency levels, related projects and even developers are highlighted by quantizing the data. Synchronously labeling the data obtained in the steps on an interface topology, and recording interface addresses where access records cannot be found as inactive interfaces;

9) Removing parameters from all actual interface links, extracting the part behind the rightmost diagonal, then word embedding, text classification model or large language model finding out other interfaces with the same or similar functions to any interfaces, classifying the functions of all interfaces according to the meaning in such a way, recording the similarity of functions among interfaces, calculating the specific interface number contained in each type of interface class, the specific interface number distributed in each type of interface, the total access quantity of each type of interface, further using the history problems of the interfaces as classification standard and using the obtained result class as the label reflecting the characteristics of the interfaces, and finding out the functions or function class even the code similarity of the interfaces with little access quantity and high access quantity;

10 According to the resource (including other interfaces) which an interface needs to access, drawing the calling topological relation and the service of each external resource (other interfaces called by the interface, middleware and database) example from the interface, adopting nodes with different shapes to respectively represent the interface and the external resources with different types, showing the access address for each node, further adding the topological relation of other interfaces on the topology, and connecting the interfaces with actual calling relation on the topology according to the actual calling direction, so that the hierarchy of the topology can be increased, and the multi-level interface calling topology diagram for any interface and the external middleware and database with different types called by the interface can be provided on the UI of the server. Marking the interface access quality data obtained above on the corresponding topological nodes and connecting lines according to the one-to-one correspondence between the log source and the destination and the corresponding topological nodes and connecting lines, and drawing the access times of the corresponding external resources according to the interface access log on the topological graph according to the access times of the external resources corresponding to the one-time call of the interface obtained above and the access trigger condition;

11 The service end can also integrate the interface metadata of all business projects to provide a series of services with actual value, for example ① visually displays all interfaces, databases and middleware resources on each interface call chain to a user through a UI (user interface), ② conveniently finds out the interface at the bottommost layer on the call chain or analyzes the alarm of one interface, the influence range of the fault and whether the running problem of the interface is influenced by the interface called by the interface when finding out that one interface has an alarm or fault and the external resources relied on by the interface based on the call relation between the interfaces, ③ realizes the effects of converging the alarm and controlling the alarm number notified to the user by combining the alarm data of each interface on the interface call joint call;

12 The server actually deployed by combining the project to which the interface belongs and the CPU and memory configuration thereof analyze the interface access quantity which can be served by each project unit computing resource (for example, 1-core CPU1GB memory) for a certain time (for example, each day), and the project flow which can be served by each unit computing resource and is obtained by calculation after the input and output flows of all the interfaces of the project are combined, and the server is used as the interface resource utilization rate of the project, and supports the quantitative analysis of specific functions, the resource utilization quantity and the utilization rate of the execution/access times in any time period according to the service and department service angles.

The method steps of the embodiment of the invention are explained above, and it can be realized that the embodiment of the invention realizes the automatic discovery and collection analysis of the interface metadata, and improves the accuracy and comprehensiveness of the collection and analysis of the interface metadata. The invention is further described with reference to a specific example.

In order to collect and report information of a series of interfaces of a service facing a public network and find out security risks of the interfaces, a certain internet enterprise A takes several months to mobilize staff to manually collect and summarize the information of the interfaces and access randomly generated interface links to service domain names, and the problems of incomplete reported data, incomplete interface links, data errors, irregular interfaces, repetition, large amount of junk data and the like are still encountered although long-time manpower research and development and a large amount of manual workload are input. Based on the interface metadata processing method provided by the invention, the automatic collection of the interface information facing the inward and outward networks can be realized, the accurate linking and requesting methods of all the interfaces opened facing the public network can be automatically obtained without manual intervention, and the result data is also helpful for taking the interfaces as the basis and objects of deep resource management and protection. The main implementation steps are as follows:

1) From CI/CD service or package mirror image plugins using maven and gradle, after the system to be serviced is packaged into mirror image or jar file, automatically calling the tool to analyze service release file;

2) Metadata of each item and the interface thereof reported by the client tool can be checked at any time from the server, the release files of which items are analyzed and processed can be seen, and whether all interface addresses and the implementation of the items meet the specification or not and whether risks exist can be further and accurately obtained;

3) The project dependence can be further seen, whether any project has any security hole according to the latest disclosed software security risk information, and specific information such as the existence of risks and whether the risks are repaired can be further known in detail;

4) The analysis result of the interface metadata is also helpful to analyze the resource consumption condition of the service from the interface dimension, and is helpful to find out which functions and interfaces the resources of the service are mainly consumed on, thereby promoting and adjusting the functional range of different projects and achieving the purpose of controlling the use of the resources.

It can be realized that the embodiment of the invention starts from the project release files for formal deployment after packaging, can directly automatically collect the metadata of the business project and the 'wide' interface thereof, including project and dependence, interface address and key realization features of the interface, and further supports the automatic inspection of the project dependence and the safety risk and repair situation realized by the interface thereof, does not need manual intervention or cross-department coordination, and also avoids the risk of source code safety. In addition, the embodiment of the invention integrates the client and the server, realizes the interface access resource and the call relation topology between interfaces based on the interface metadata, analyzes the service access log based on the interface metadata, evaluates and determines the actual access quantity, abnormal access quantity and access quality of the interfaces, modules, micro-services, items and product dimensions, synchronously provides specific interfaces with different access quantity and access quality grades, corresponding codes and corresponding quantized data of research and development efficiency and quality, and automatically provides the label reflecting the interface characteristics and the resource utilization rate of the service items of the interface dimensions based on the interface function semantics.

Compared with the prior art, the embodiment of the invention has the following advantages:

1) The scheme is simple to develop, convenient to use, flexible to deploy, capable of effectively reducing unnecessary cross-department communication collaboration, enabling the operation and maintenance department to independently complete gateway work, and capable of accurately finding out interfaces and wide metadata information of the business items to which the interfaces belong based on the release files of the business items;

2) Supporting the actual topology of calling relations among external middleware, databases and interfaces, which are called by drawing interfaces by taking the interfaces as centers from the interface metadata;

3) The interface address is supported to be used as an important resource, and the management of the business project and the resource thereof is deepened to the management based on the interface information, so that interfaces which are not active or are rarely accessed can be quickly and accurately found by combining with the interface topology, and the use of cloud network resources can be controlled by adjusting the functional range of different projects;

4) The interface topology data has wide application and high practical value, and comprises the quantity of alarm notices which can be compressed and sent to operation and maintenance personnel according to the interface call topology, the bottom factors which cause interface problems and the like.

Fig. 9 is a schematic structural diagram of an interface metadata processing device according to an embodiment of the present invention, and referring to fig. 9, an embodiment of the present invention provides an interface metadata processing device, including:

the project path determining module is used for reading the mirror image file of the service project, collecting service project information according to the mirror image file, and determining a project specific path of the service project in the mirror image file;

the image file content detection module is used for carrying out security risk detection on the content of the image file, detecting whether a repeated package file exists or not, and uploading a detection result to the server;

The interface file searching module is used for searching an interface file path in the mirror image file through a decompilation technology according to the project specific path and decompressing the corresponding interface belonging file and configuration file to the temporary directory;

The interface metadata searching module is used for searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

And the interface metadata uploading module is used for uploading context configuration, interface address, request method and access resource list as the interface metadata of the service item to the server.

The content in the method embodiment is applicable to the embodiment of the device, and the functions specifically realized by the embodiment of the device are the same as those of the method embodiment, and the obtained beneficial effects are the same as those of the method embodiment.

The embodiment of the invention also provides electronic equipment, which comprises a memory, a processor, a program stored on the memory and capable of running on the processor and a data bus for realizing connection communication between the processor and the memory, wherein the program is executed by the processor to realize the interface metadata processing method. The electronic equipment can be any intelligent terminal including a tablet personal computer, a vehicle-mounted computer and the like.

Referring to fig. 10, a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present invention is shown in fig. 10, where the embodiment of the present invention provides an electronic device, including:

The processor 1001 may be implemented by using a general purpose CPU (Central Processing Unit ), a microprocessor, an Application SPECIFIC INTEGRATED Circuit (ASIC), or one or more integrated circuits, etc. to execute related programs to implement the technical solution provided by the embodiments of the present invention;

The Memory 1002 may be implemented in the form of a Read Only Memory (ROM), a static storage device, a dynamic storage device, or a random access Memory (Random Access Memory, RAM). The memory 1002 may store an operating system and other application programs, and when the technical solutions provided in the embodiments of the present disclosure are implemented by software or firmware, relevant program codes are stored in the memory 1002, and the processor 1001 invokes an interface metadata processing method for executing the embodiments of the present disclosure;

An input/output interface 1003 for implementing information input and output;

The communication interface 1004 is configured to implement communication interaction between the present device and other devices, and may implement communication in a wired manner (e.g. USB, network cable, etc.), or may implement communication in a wireless manner (e.g. mobile network, WIFI, bluetooth, etc.);

A bus 1005 for transferring information between the various components of the device (e.g., the processor 1001, memory 1002, input/output interface 1003, and communication interface 1004);

Wherein the processor 1001, the memory 1002, the input/output interface 1003, and the communication interface 1004 realize communication connection between each other inside the device through the bus 1005.

Referring to fig. 11, the storage medium is a computer readable storage medium, and the storage medium is used for computer readable storage, and the storage medium stores one or more programs 1101, and the one or more programs 1101 may be executed by one or more processors to implement the above-mentioned interface metadata processing method.

The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor 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.

Embodiments of the present invention also disclose a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions may be read from a computer-readable storage medium by a processor of a computer device, and executed by the processor, to cause the computer device to perform the method shown in fig. 1.

In some alternative embodiments, the functions/acts noted in the block diagrams may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Furthermore, the embodiments presented and described in the flowcharts of the present invention are provided by way of example in order to provide a more thorough understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed, and in which sub-operations described as part of a larger operation are performed independently.

Furthermore, while the present invention has been described in the context of functional modules, it should be appreciated that, unless otherwise indicated, one or more of the functions and/or features described above may be integrated in a single physical device and/or software module or one or more of the functions and/or features may be implemented in separate physical devices or software modules. It will also be appreciated that a detailed discussion of the actual implementation of each module is not necessary to an understanding of the present invention. Rather, the actual implementation of the various functional modules in the apparatus disclosed herein will be apparent to those skilled in the art from consideration of their attributes, functions and internal relationships. Accordingly, one of ordinary skill in the art can implement the invention as set forth in the claims without undue experimentation. It is also to be understood that the specific concepts disclosed are merely illustrative and are not intended to be limiting upon the scope of the invention, which is to be defined in the appended claims and their full scope of equivalents.

The above functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied in essence or a part contributing to the prior art or a part of the technical solution in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the above-described method of the various embodiments of the present invention. The storage medium includes a U disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, an optical disk, or other various media capable of storing program codes.

Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

More specific examples (a non-exhaustive list) of the computer-readable medium would include an electrical connection (an electronic device) having one or more wires, a portable computer diskette (a magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium upon which the program described above is printed, as the program described above may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

It is to be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, may be implemented using any one or combination of techniques known in the art, discrete logic circuits with logic gates for implementing logic functions on data signals, application specific integrated circuits with appropriate combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.

In the foregoing description of the present specification, reference has been made to the terms "one embodiment/example", "another embodiment/example", "certain embodiments/examples", and the like, means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the spirit and scope of the invention as defined by the appended claims and their equivalents.

While the preferred embodiment of the present application has been described in detail, the present application is not limited to the above embodiments, and various equivalent modifications and substitutions can be made by those skilled in the art without departing from the spirit of the present application, and these equivalent modifications and substitutions are intended to be included in the scope of the present application as defined in the appended claims.

Claims (10)

1. An interface metadata processing method, comprising the steps of:

reading an image file of a service item, acquiring service item information according to the image file, and determining an item specific path of the service item in the image file;

detecting the security risk of the content of the mirror image file, detecting whether a repeated package file exists or not, and uploading a detection result to a server;

Searching an interface file path in the mirror image file through a decompilation technology according to the project specific path, and decompressing a file and a configuration file which correspond to the interface to a temporary directory;

Searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

and uploading the context configuration, the interface address, the request method and the access resource list to a server as interface metadata of the service item.

2. An interface metadata processing method according to claim 1, characterized in that the interface metadata processing method further comprises the steps of:

updating a software security information base of a server according to the interface metadata, and carrying out project early warning according to the interface metadata and the detection result;

generating a function description corresponding to each interface according to the interface metadata;

Filtering invalid access logs according to the interface metadata, performing abnormal access analysis, further calculating effective access quantity and access quality of each interface, and determining invalid/low-efficiency interfaces according to the effective access quantity and the access quality;

classifying each interface according to the function description to obtain a plurality of interface categories, and further determining the interface number, the interface distribution position and the total effective access quantity of each interface category;

And constructing an interface access topology according to the access resource list, and providing the interface access topology for the client through the server.

3. The method according to claim 1, wherein the collecting service item information according to the image file and determining an item specific path of the service item in the image file specifically includes:

Searching a preset file name field in a first layer of the mirror image file to obtain a target JSON file;

Analyzing the target JOSN file to obtain the service item information, wherein the service item information comprises an item maintainer, a service item file working path, a service application file name, mirror image construction time, a mirror image file size, a mirror image file MD5 code, an operation environment requirement, an externally exposed port number and basic mirror image data;

Reading compressed files of all folders in the mirror image file layer by layer, and judging whether the compressed files contain the service project file working paths and the service application file names;

if yes, determining the project specific path according to the file path of the compressed file.

4. The method according to claim 1, wherein searching the path of the interface file in the image file according to the project specific path by decompilation technology, and decompressing the corresponding file and configuration file of the interface to a temporary directory, specifically comprises:

Searching the compiled class file in the mirror image file according to the project specific path;

decompiling the class file to obtain class definition information, determining an interface corresponding to the class file according to the class definition information, and further determining the interface file path;

Creating a temporary directory, determining a corresponding file to which the interface belongs and the configuration file according to the interface file path, and decompressing the file to which the interface belongs and the configuration file to the temporary directory.

5. The method for processing interface metadata according to claim 2, wherein the performing item pre-warning according to the interface metadata and the detection result specifically comprises:

determining whether the image file has safety risk or not and whether the image file has repeated package files or not according to the detection result;

When the mirror image file has security risk and/or the file is repeatedly packaged, determining a project maintainer according to the interface metadata, and sending the project early warning to the project maintainer;

the project early warning is used for reminding the project maintainer to formally deploy the mirror image file after repairing the mirror image file.

6. The method according to claim 2, wherein the filtering the invalid access log according to the interface metadata, and performing abnormal access analysis, further calculating an effective access amount and an access quality of each interface, and determining an invalid/inefficient interface according to the effective access amount and the access quality, specifically comprises:

Determining the interface address, the request method and the access resource list according to the interface metadata;

Determining a corresponding target service according to the access resource list, inquiring an access log of the target service according to the interface address and the request method to obtain an effective access log, and taking the access log which does not belong to the effective access log as the invalid access log;

Counting an abnormal access source IP and a geographical area to which the abnormal access source IP belongs according to the invalid access log, and determining an interface actually accessed by the abnormal access source IP and a corresponding abnormal access amount;

Counting the effective access quantity, the access error times and the access performance data of each interface according to the effective access log, and determining the access quality of the corresponding interface according to the abnormal access quantity, the access error times and the access performance data;

And judging whether each interface is an invalid/low-efficiency interface according to the effective access quantity, the access quality and a preset threshold value.

7. The method for processing interface metadata according to claim 2, wherein the constructing an interface access topology according to the access resource list specifically includes:

Determining the calling relation between each interface and the external resource instance according to the access resource list;

taking each interface and a plurality of external resource instances as nodes, and determining the topological connection relation and the actual calling direction between each node according to the calling relation;

And connecting each node according to the topology connection relation and the actual calling direction to obtain the interface access topology.

8. An interface metadata processing apparatus, comprising:

the system comprises a project path determining module, a service project processing module and a service project processing module, wherein the project path determining module is used for reading an image file of a service project, collecting service project information according to the image file and determining a project specific path of the service project in the image file;

The image file content detection module is used for carrying out security risk detection on the content of the image file, detecting whether a repeated package file exists or not, and uploading a detection result to the server;

The interface file searching module is used for searching an interface file path in the mirror image file through a decompilation technology according to the project specific path, and decompressing the corresponding interface belonging file and the configuration file to a temporary directory;

The interface metadata searching module is used for searching context configuration of the service item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from the file to which the interface belongs;

and the interface metadata uploading module is used for uploading the context configuration, the interface address, the request method and the access resource list to a server as the interface metadata of the service item.

9. An electronic device comprising a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for enabling a connection communication between the processor and the memory, the program when executed by the processor implementing the steps of the interface metadata processing method according to any of claims 1 to 7.

10. A storage medium, which is a computer-readable storage medium, for computer-readable storage, characterized in that the storage medium stores one or more programs executable by one or more processors to implement the steps of the interface metadata processing method according to any one of claims 1 to 7.