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

Abstract

The invention discloses an interface metadata processing method and device, electronic equipment and a storage medium, and the method comprises the steps: collecting business item information according to a mirror image file, and determining a specific item path of a business item in the mirror image file; performing security risk detection on the content of the mirror image file, detecting whether a repeatedly packaged 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 a project specific path, and decompressing a file to which a corresponding interface belongs and a configuration file to a temporary directory; searching context configuration of the business item from the configuration file, and searching a corresponding interface address, a request method and an access resource list from a 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 business item. The method improves the accuracy and comprehensiveness of collection and analysis of the interface metadata, and can be applied to the technical field of information.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to an interface metadata processing method, device, electronic equipment and storage medium. Background Art

[0002] An interface is a set of software functions encapsulated from the server-side software to meet the external needs of the software. These functions are often used directly to serve end business users or other external systems. It can be seen that it is important to identify and repair problems and risks of the interface and its projects in a timely manner before they are officially deployed to the production environment.

[0003] The automatic discovery and analysis of interface metadata are of positive significance for analyzing the quality and security risks of the image files of the projects to which the interfaces belong, as well as for in-depth quantitative analysis of the resource consumption of the business from the interface dimension. The collection and analysis results of interface metadata can provide in-depth quantitative data, which can help to discover and resolve possible risks and operational quality information of business projects and their interfaces as early as possible before the business is deployed to the production environment. It can also effectively reduce the manpower cost of related work and improve the effectiveness and efficiency of Internet software operation and maintenance and resource management. However, the collection and analysis of interface metadata in the existing technical solutions are insufficient in accuracy and comprehensiveness, and are not easy to expand, and cannot give full play to the value of interface metadata.

[0004] Terminology explanation:

[0005] Interface: Also known as API, it refers to an abstract set of software functions that a server application opens to different forms of software such as web pages, mobile clients or other server applications. It is usually a set of pre-defined functions. The purpose is to provide application and developers with the ability to access a set of routines based on certain software or hardware without accessing the source code or understanding the details of the internal working mechanism. In the description of the present invention, the interface specifically refers to the interface opened through the HTTP / HTTPS protocol.

[0006] Interface metadata: refers to the information of the interface itself, the project to which the interface belongs, the project's release (to be deployed) files, and the various resources that need to be called when the interface runs.

[0007] LoRA (Low-Rank Adaptation of Large Language Models): It is a plug-in network that can train a style / IP / character using a small amount of data without modifying the SD (Stable Diffusion) model. It can reduce the GPU requirement for training large language models to about one third of the original, thus helping to train private large language models based on public large language models. Summary of the invention

[0008] The purpose of the present invention is to solve one of the technical problems existing in the prior art to at least a certain extent.

[0009] To this end, an object of an embodiment of the present invention is to provide an interface metadata processing method, which realizes automatic discovery, collection and analysis of interface metadata, and improves the accuracy and comprehensiveness of the collection and analysis of interface metadata.

[0010] Another object of an embodiment of the present invention is to provide an interface metadata processing device.

[0011] In order to achieve the above technical objectives, the technical solutions adopted by the embodiments of the present invention include:

[0012] In one aspect, an embodiment of the present invention provides an interface metadata processing method, comprising the following steps:

[0013] Reading an image file of a business project, collecting business project information according to the image file, and determining a specific project path of the business project in the image file;

[0014] Perform security risk detection on the content of the image file, detect whether there are duplicate packaged files, and upload the detection results to the server;

[0015] According to the specific path of the project, the interface file path in the image file is found through decompilation technology, and the corresponding interface files and configuration files are decompressed into a temporary directory;

[0016] Searching for the context configuration of the business project from the configuration file, and searching for the corresponding interface address, request method and access resource list from the file to which the interface belongs;

[0017] The context configuration, the interface address, the request method and the access resource list are uploaded to the server as the interface metadata of the business project.

[0018] Furthermore, in one embodiment of the present invention, the interface metadata processing method further includes the following steps:

[0019] Updating the software security information base of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection result;

[0020] Generate a functional description corresponding to each interface according to the interface metadata;

[0021] Filter invalid access logs according to the interface metadata, perform abnormal access analysis, and then calculate the effective access volume and access quality of each interface, and determine invalid / inefficient interfaces according to the effective access volume and the access quality;

[0022] Classify each interface according to the functional description to obtain multiple interface categories, and then determine the number of interfaces, interface distribution location, and total effective access volume of each interface category;

[0023] An interface access topology is constructed according to the access resource list, and the interface access topology is provided to the client through the server.

[0024] Further, in one embodiment of the present invention, the collecting of business project information according to the image file and determining the specific project path of the business project in the image file specifically includes:

[0025] Search the preset file name field in the first layer of the image file to obtain the target JSON file;

[0026] Parse the target JOSN file to obtain the business project information, including the project maintainer, business project file working path, business application file name, image build time, image file size, image file MD5 code, operating environment requirements, externally exposed port number, and basic image data;

[0027] Read the compressed files of each folder inside the image file layer by layer, and determine whether the compressed files contain the working path of the business project file and the business application file name;

[0028] If so, determine the specific path of the project according to the file path of the compressed file.

[0029] Further, in one embodiment of the present invention, the interface file path in the image file is searched by decompilation technology according to the specific path of the project, and the corresponding interface belonging files and configuration files are decompressed to a temporary directory, which specifically includes:

[0030] Search the compiled class file in the image file according to the specific path of the project;

[0031] Decompiling the class file to obtain class definition information, and determining the interface corresponding to the class file according to the class definition information, and then determining the interface file path;

[0032] A temporary directory is created, and the corresponding interface-related files and configuration files are determined according to the interface file path, and the interface-related files and configuration files are decompressed into the temporary directory.

[0033] Further, in one embodiment of the present invention, the project early warning is performed according to the interface metadata and the detection result, which specifically includes:

[0034] Determine whether the image file has security risks and whether there are duplicate packaged files according to the detection result;

[0035] When the image file has security risks and / or duplicate packaged files, determine the project maintainer according to the interface metadata, and issue the project warning to the project maintainer;

[0036] The project warning is used to remind the project maintainer to repair the image file before formal deployment.

[0037] Further, in one embodiment of the present invention, filtering invalid access logs according to the interface metadata, and performing abnormal access analysis, thereby calculating the effective access volume and access quality of each interface, and determining invalid / inefficient interfaces according to the effective access volume and the access quality, specifically includes:

[0038] Determine the interface address, the request method, and the access resource list according to the interface metadata;

[0039] Determine the corresponding target service according to the access resource list, query the access log of the target service according to the interface address and the request method to obtain a valid access log, and use the access log that does not belong to the valid access log as the invalid access log;

[0040] According to the invalid access log, count the abnormal access source IP and the geographical area to which it belongs, and determine the interface actually accessed by the abnormal access source IP and the corresponding abnormal access volume;

[0041] Counting the effective access volume, the number of access errors 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 volume, the number of access errors and the access performance data;

[0042] Whether each interface is an invalid / inefficient interface is determined according to the effective access amount, the access quality and a preset threshold.

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

[0044] Determine the calling relationship between each interface and the external resource instance according to the access resource list;

[0045] Taking each interface and a plurality of the external resource instances as nodes, determining the topological connection relationship and the actual calling direction between the nodes according to the calling relationship;

[0046] The nodes are connected according to the topological connection relationship and the actual calling direction to obtain the interface access topology.

[0047] On the other hand, an embodiment of the present invention provides an interface metadata processing device, including:

[0048] A project path determination module, used to read the image file of the business project, collect business project information according to the image file, and determine the specific project path of the business project in the image file;

[0049] The image file content detection module is used to perform security risk detection on the content of the image file, detect whether there are duplicate packaged files, and upload the detection results to the server;

[0050] An interface file search module is used to search the interface file path in the image file through decompilation technology according to the specific path of the project, and decompress the corresponding interface files and configuration files into a temporary directory;

[0051] An interface metadata search module, used to search for the context configuration of the business project from the configuration file, and to search for the corresponding interface address, request method and access resource list from the file to which the interface belongs;

[0052] The interface metadata uploading module is used to upload the context configuration, the interface address, the request method and the access resource list as the interface metadata of the business project to the server.

[0053] On the other hand, an embodiment of the present invention provides an electronic device, comprising a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory, wherein the program, when executed by the processor, realizes the interface metadata processing method as described above.

[0054] On the other hand, an embodiment of the present invention further provides a storage medium, which is a computer-readable storage medium used for computer-readable storage, and the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the interface metadata processing method as described above.

[0055] The advantages and beneficial effects of the present invention will be partly given in the following description, partly become apparent from the following description, or be understood through the practice of the present invention:

[0056] The embodiment of the present invention reads the image file of the business project, collects the business project information according to the image file, determines the specific path of the business project in the image file, performs security risk detection on the content of the image file, detects whether there are duplicate packaged files, uploads the detection result to the server, searches for the interface file path in the image file through decompilation technology according to the specific path of the project, decompresses the corresponding interface belonging files and configuration files to a temporary directory, searches for the context configuration of the business project from the configuration file, searches for the corresponding interface address, request method and access resource list from the interface belonging files, and uploads the context configuration, interface address, request method and access resource list as interface metadata of the business project to the server. The embodiment of the present invention realizes the automatic discovery and collection and analysis of interface metadata, and improves the accuracy and comprehensiveness of the collection and analysis of interface metadata. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the technical solution in the embodiments of the present invention, the following introduction is made to the drawings required for use in the embodiments of the present invention. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solution of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0058] Figure 1 A flowchart of a method for processing interface metadata provided by an embodiment of the present invention;

[0059] Figure 2 A schematic diagram of an implementation framework of the interface metadata processing method provided by an embodiment of the present invention;

[0060] Figure 3 Another step flow chart of the interface metadata processing method provided by the embodiment of the present invention;

[0061] Figure 4 A step flow chart of step S101 provided in an embodiment of the present invention;

[0062] Figure 5 A step flow chart of step S103 provided in an embodiment of the present invention;

[0063] Figure 6 A step flow chart of step S201 provided in an embodiment of the present invention;

[0064] Figure 7 A step flow chart of step S203 provided in an embodiment of the present invention;

[0065] Figure 8 A step flow chart of step S205 provided in an embodiment of the present invention;

[0066] Fig. 9 A schematic diagram of the structure of an interface metadata processing device provided by an embodiment of the present invention;

[0067] Fig.10 A schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention;

[0068] Fig.11 A schematic diagram of the structure of a storage medium provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0069] Embodiments of the present invention are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limitations on the present application. It should be noted that, although the functional module division is performed in the system schematic diagram and the logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order from the module division in the system schematic diagram or the flow chart. For the step numbers in the following embodiments, they are only set for the convenience of explanation, and the order between the steps is not limited in any way. The execution order of each step in the embodiment can be adaptively adjusted according to the understanding of those skilled in the art.

[0070] In the description of the present invention, the meaning of "a plurality" is two or more. If there is a description of the first or the second, it is only for the purpose of distinguishing the technical features, and it cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features. In addition, unless otherwise defined, all technical and scientific terms used in this document have the same meaning as those commonly understood by technicians in the technical field of this application. The terms used in this document are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0071] The related art discloses a private warehouse Docker image information collection system and collection method thereof, which first obtains the image to be collected from the local private image warehouse and adds an image layer for information collection to build a new image, then starts the container of the new image, reads the image content based on the Docker service and supports sending the target compressed file in the image to the image collection center through the network. The image information collected by this solution only includes the image id, label, warehouse and whether the collection result is successful, and cannot collect the interface information contained in the business system inside the image, and needs to package and run the new docker image. Considering that the image of the business system is generally around 500MB, and some will exceed 1GB, when it is necessary to collect information on a large number of projects, this solution is relatively wasteful of disk, network and computing resources.

[0072] Related technologies also disclose difference analysis methods, equipment, storage media and devices, which can extract jar packages from docker image files, and then use a preset class loader to obtain interface information from the jar file. The shortcomings of this solution include: 1) It requires accurate information to be manually configured in advance, and the acquisition of this information is not only cumbersome, but also difficult or even impossible to obtain some information accurately in advance due to technical barriers. For example, it may be necessary to develop a class loader that is truly usable (capable of loading classes without exceptions and also able to obtain information such as annotations of the class itself) for some projects. This solution does not provide a technical method for automatically obtaining all preset information; 2) The interface information obtained is limited, and it is impossible to find important information related to practical applications such as interface dependencies and potential security risks.

[0073] Some people in the industry have suggested that interface metadata can be extracted from source code. This means that tools need to be developed to parse information such as different code branches of version control services such as Git and SVN, otherwise manual configuration is necessary; different code styles can easily lead to the inability to accurately parse all interface information, which will increase the development and design difficulty and workload of source code parsing tools; in addition, due to the lack of information on the current network deployment environment during the development phase and the fact that the design and implementation may change repeatedly during the development phase, it is easy for the solution to find limited or even useless information.

[0074] In summary, the collection and analysis of interface metadata in the existing technical solutions are insufficient in accuracy and comprehensiveness, and are not easy to expand, and cannot fully exert the value of interface metadata.

[0075] The present invention provides an interface metadata processing method, device, electronic device and storage medium to achieve the following objectives:

[0076] 1) Collect project information from the deployment (release) file of the business project to form project metadata, then find the path of the compressed item containing the defined interface from the deployment file, decompress the corresponding file from the deployment file according to this path, and then decompile these files to obtain code files with a unified style;

[0077] 2) Automatically collect and analyze the deployment files and the above code files to obtain rich information: which interfaces (APIs) a class contains, the complete method signature of each interface, whether an interface calls other interfaces, which external resources and their versions are used by each interface, how each interface uses resources, which library files each interface depends on, the security configuration of each interface, data validity verification and exception handling, and other business items and interface metadata sets;

[0078] 3) Support a series of analysis and verification from the interface dimension, including: ① Building interface access topology based on the discovered interface metadata; ② Comparing and analyzing the specific security risks of project image files and incorrect image packaging behaviors based on public software security vulnerability data and verifying the repair situation; ③ Analyzing business access logs based on interface addresses, excluding logs of actual access link errors of external access behaviors, so as to accurately calculate the access quality of each interface and the actual effective access volume, and further support the analysis and viewing of the actual consumption of cloud network resources in the interface and business dimensions at any time, etc., to improve the efficiency and effectiveness of business service assurance and business alarm convergence and analysis, and help quantify and optimize cloud network resource costs.

[0079] The interface metadata processing method provided in the embodiment of the present application can be applied to the terminal, can also be applied to the server side, and can also be software running in the terminal or the server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a set-top box, etc.; the server side can be configured as an independent physical server, or a server cluster or distributed system composed of multiple physical servers, and can also be configured as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the interface metadata processing method, etc., but is not limited to the above forms.

[0080] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0081] It should be noted that in each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of these data will comply with the relevant laws, regulations, and standards of the relevant countries and regions. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0082] First, the implementation framework of the interface metadata processing method of the embodiment of the present invention is described. Figure 2The schematic diagram of the implementation framework of the interface metadata processing method provided by the embodiment of the present invention is shown, including a server, a client and a business project. The client focuses on automatically parsing and obtaining the metadata of the project and its interface from the business project release (deployment) file. The client can be easily deployed and used in various professional companies under the group; the server is more responsible for the integration, processing, storage and analysis of various types of data reported by different clients, including forming a series of call relationships and resource access topologies between interfaces. The server is centrally 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 containing tables for saving project, interface metadata and software security risk information disclosed by the industry, and the interface call relationship topology data can be saved in a graph database. In addition, the client is also responsible for detecting the security risks of the business project release files and verifying the solution, analyzing the business access log according to the interface metadata, forming the access / call topology between projects (release files) based on the interface call topology, and the interface operation quality topology. It can also provide management and audit functions for abnormal information such as inactive interfaces, domain names that have not been officially enabled, domain names that cannot be found, and interface addresses that match abnormalities based on the business access log.

[0083] The embodiment of the present invention can read a wide range of interface metadata from the release file of the business project, including the interface address, request method, complete method signature and request parameters of the interface implementation, which resources are used (called) by the interface, the error and exception handling mechanism of the interface, security configuration, interface development framework and third-party dependent libraries (which jar files are used for Java projects) and their version information, and can even analyze how many times a database and middleware are accessed internally by an interface, whether sensitive data is stored securely, whether necessary data verification and cleaning are available, and other information; it can easily find problems with business deployment files (especially image files), such as repeated packaging of some files; it is conducive to conveniently integrating other programming languages ​​for joint development through Bash scripts based on the Linux system, which can reduce development workload, improve development efficiency, and can flexibly adjust some details based on actual conditions.

[0084] The following describes the process of implementing interface metadata collection on the client, that is, parsing the project and its interface metadata from the Docker image file of the business project.

[0085] like Figure 1 FIG. 1 is a flowchart of a method for processing interface metadata according to an embodiment of the present invention. Figure 1 The embodiment of the present invention provides an interface metadata processing method, which specifically includes the following steps:

[0086] S101, reading the image file of the business project, collecting the business project information according to the image file, and determining the specific project path of the business project in the image file;

[0087] S102, performing security risk detection on the content of the image file, detecting whether there are duplicate packaged files, and uploading the detection results to the server;

[0088] S103, searching the interface file path in the image file through decompilation technology according to the specific path of the project, and decompressing the corresponding interface files and configuration files into a temporary directory;

[0089] S104, searching for the context configuration of the business project from the configuration file, and searching for the corresponding interface address, request method, and access resource list from the interface-related file;

[0090] S105: Upload the context configuration, interface address, request method, and access resource list as interface metadata of the business project to the server.

[0091] like Figure 4 FIG. 1 is a flowchart of step S101 provided in an embodiment of the present invention, referring to FIG. Figure 4 As an optional implementation method, the business project information is collected according to the image file, and the specific path of the business project in the image file is determined, which specifically includes:

[0092] S1011, searching for a preset file name field in the first layer of the image file to obtain a target JSON file;

[0093] S1012. Parse the target JOSN file to obtain business project information, including project maintainer, business project file working path, business application file name, image build time, image file size, image file MD5 code, operating environment requirements, externally exposed port number, and basic image data;

[0094] S1013, reading the compressed files of each folder inside the image file layer by layer, and determining whether the compressed files contain the working path of the business project file and the business application file name;

[0095] S1014: If yes, determine the specific path of the project according to the file path of the compressed file.

[0096] like Figure 5 FIG. 1 is a flow chart of step S103 provided in an embodiment of the present invention, referring to FIG. Figure 5 As an optional implementation method, the interface file path in the image file is found through decompilation technology according to the specific path of the project, and the corresponding interface files and configuration files are decompressed to a temporary directory, which specifically includes:

[0097] S1031, searching the compiled class file in the image file according to the specific path of the project;

[0098] S1032, decompile the class file to obtain class definition information, and determine the interface corresponding to the class file according to the class definition information, and then determine the interface file path;

[0099] S1033. Create a temporary directory, determine the corresponding interface files and configuration files according to the interface file path, and decompress the interface files and configuration files to the temporary directory.

[0100] Specifically, the process of parsing the project and its interface metadata from the Docker image file of the business project is as follows:

[0101] 1) Before a business project is launched or updated to the production environment, you can obtain the image file of the business project to be deployed to the production environment from the image repository or CI / CD service at any time. This type of file is actually a file with a tar extension. The content of the compressed file in this archive format is read through the file input stream;

[0102] 2) In the first layer of the compressed file, search for files with names similar to 8ba951be20c899046f56b0ec64d819a4d06fbc2fa5260988256198b880beeee.json according to the length of the file name and the range of characters that constitute the file name. After finding the files, read and parse the contents in JSON format to obtain the maintainer of the corresponding project (corresponding to the maintainer field in the file), the built-in actual business project file working path (corresponding to the Working Dir field), the file name of the business application in the compressed file (corresponding to the APP_HOME and APP_NAME fields respectively), the image build time (the last created), the size of the image file and its md5 code, the operating environment requirements (JDK / JRE version, language requirements), the port number exposed to the outside, the basic image used, etc., which can be expanded according to actual work needs and the company's own specifications;

[0103] 3) Further read the compressed files in each folder inside the image file layer by layer, read the internal content of each newly discovered compressed file based on the content, check whether the inner compressed file contains the path and business file name of the business application obtained in the previous step, if it does, find the path of the file (also only one compressed file) packaged after the business system is compiled in the image, and record the path, otherwise, check according to the enterprise's conventional / standard path for such files;

[0104] 4) According to the format of the corresponding file, continue to read the packaged file of the business project found from the innermost layer of the image completely based on memory. The key points include:

[0105] a. Projects developed according to different software platforms are often actually some kind of compressed files after release. According to the layout / distribution specifications of various contents inside the corresponding type of files, for example, projects developed in Java language are often files with extensions of jar, war or ear. The dependency libraries of projects developed based on Spring Boot are often in the BOOT-INF / lib path of the jar file, and early Java web projects are often in the WEB-INF / classes path. The name of each compressed item in the directory where the project dependency is located in the compressed file is the file name of the corresponding dependency.

[0106] b. For the case where the software release files are directly packaged into the docker image without being compressed, it is actually a simplification compared to the method of first packaging according to the technical platform and framework selected by the business project and then packaging into an image, because the required file information can be directly read according to the same file filtering and positioning rules, and there is no need to read the compressed files of the application, and other parsing processing logic remains unchanged. In this case, it should be noted that when parsing compressed stream data, for the folders packaged under some technical platforms (such as business dependencies), their compressed items need to be iteratively parsed in the manner of folders.

[0107] c. Based on the characteristics of the file path and file name and combined with the enterprise's specifications on related names, the compressed items that really need to be processed can be located, so that various business projects designed according to architectural models such as the MVC model and the DDD model can be properly processed. In such a file, you can also search its content in depth to obtain the name of each compressed item, and you can get the names of all the basic libraries and third-party library files that the business project depends on. Generally, the file name will also include the file version number. If the version number is not included in the dependent library file name, continue to read the corresponding compressed file and read the dependent version number from the MANIFEST.MF file in its META-INF directory;

[0108] 5) The client queries the server for information about which software and libraries have been confirmed to have security vulnerabilities in the recent period (this type of information is often disclosed on the Internet in a timely manner). Compare the above results and find out whether there are security risks or vulnerabilities in the dependencies of the business projects obtained above. If found, record the specific files with risks and the repair suggestions obtained based on public industry information;

[0109] 6) Continue to check other parts of the image based on memory, including the file names contained in the compressed file, and compare them with the public security information in the same way as in the previous step. If vulnerabilities or security risks are found in other files outside the project dependencies, the corresponding files and their paths, risks and related project information in the image are also recorded and reported to the server. The data obtained so far is used as project metadata and uploaded to the server for storage;

[0110] 7) In view of the situation that the image is a compressed file with multiple layers of compressed files of different formats nested inside it, which makes it easy for the same file to be compressed by different image layers, when the size of the project image file exceeds a certain threshold (configurable), check whether the remaining content of the image contains business projects with the same name or their dependent files. If found, it means that the corresponding files are packaged repeatedly. Record the duplicate files and their paths, and the information of related projects and report them to the server;

[0111] 8) Read the contents of the business project release file obtained in step 3), find the compiled class file, and decompile the contents of the class file line by line based on the memory until it is confirmed that the corresponding class defines the business interface according to the class definition information;

[0112] 9) Create a new random folder in the system temporary file directory, decompile each interface class found above and the Service class it calls, and write all the decompiled results to the folder. Here, you can control the decompilation of only the bytecode of the required class or interface through the blacklist or whitelist of classes or interfaces;

[0113] 10) Find the built-in configuration of the business according to the relative path of the class file in the business release file, and unzip all configuration files under the newly created folder above according to the same relative path;

[0114] 11) Use operating system commands and tools to find the values ​​of context-path configuration items that may exist in configuration files in properties, yml, and yaml formats, and use the found contents as the context configuration of the business project;

[0115] 12) Check the project's configuration files, such as application-dev.yml, application-prod.yml, application-test.yml, etc., according to the naming rules of the project's configuration files and the company's naming rules for such files (which can be extended). Check which configuration files are available, whether there are hard-coded IP addresses, direct passwords, configuration files that are unnecessary and should not be used for formal deployment, and the types, instances, connections, authentication, namespaces, and related configuration files of external services such as the configuration center used by the project;

[0116] 13) Check from the project configuration whether some third-party dependencies of the project with built-in HTTP interface services have been explicitly configured to prohibit the startup of their HTTP services before going online or have been mistakenly packaged into the project release file. These services should only be used in non-production environments such as development and testing, and should not be deployed to the production environment as part of the business system, such as JDBC driver druid, project code documentation service swagger, etc. For the former, check whether the corresponding configuration item druid.stat.http.enable already exists and is set to false. For the latter, either check whether the relevant jar is included (it should not be included in the production environment), or check whether the startup of the service is prohibited through specific configuration. Report the problems found here to the server for processing;

[0117] 14) In view of the current situation that annotations are widely used to define interfaces in different programming languages ​​and development platforms, for example, the Spring framework mainly uses annotations such as RestController, RequestMapping, GetMapping, PostMapping, PutMapping, and DeleteMapping to develop interfaces, and some annotations can only be written on methods. Therefore, it is necessary to parse the corresponding interface data under various uses of annotations according to whether the annotations are used on classes or methods, otherwise it will lead to missing interface information or inaccurate data. Solution: Assemble and retrieve the code files obtained above through pipelines in the order of find, grep, and custom programs, and search the code files for the content of any one of the target annotations and its next adjacent line, so that the query results are always composed of pairs of two lines. The contents of these two lines are: ① The file where the found information is located and the actual definition of any of the above annotations in the code; ② The file where the found information is located and the actual definition of the class or method corresponding to the annotation obtained in the previous line, including all parameters supported by the method, that is, the corresponding interface. Pass the query result information in this format to the next step through the pipeline;

[0118] 15) First, take every two lines as a processing unit, parse to get an object list containing the file path of the file name, the annotation and whether the content below is a class definition; then loop through each element in the object list: if an object does not contain a class definition (it means that the object contains the definition of a class method, so that a complete method signature including the method name, method parameters, and possible thrown exceptions can be obtained) and the annotation contains the interface address information, then it is a new interface; if the object is a class definition and its annotation contains the interface address information, then the path of the class definition is recorded; if the object is not a class definition and belongs to the same file as the last processed object, then a new interface is also found. Combining the context obtained above with the path information obtained in this way here can get the interface path (the core part of the complete interface link in the production environment), and the request method can be obtained according to each interface annotation, so that the scheme here can ensure that accurate and complete information of each interface in the code is obtained;

[0119] 16) The specific code can be obtained from the interface method signature obtained above, and then through the middleware or database client tool class information of different protocols, the information of other interfaces, databases, caches, message queues and other resources that each interface may access during execution can be found from the interface implementation code, including the actual address, port, access method, access trigger condition, and the number of times each resource is accessed by one interface call. This information can clarify the access and correspondence between the interface and its external resources;

[0120] 17) Similarly, you can automatically find out from the method code of the interface which exceptions and errors the interface handles and how they are handled (for example, whether to directly throw an Exception, whether to log, and whether the recorded information is complete, etc.), and the response processing method. Then, check from the implementation code of the interface whether there are IP addresses and other domain names outside the business. Find out whether there is a password based on the need to access external resources. After finding the password, check the length, complexity, commonality and duplication of the password content to find out the weak password information and record the purpose of the password. You can also find out here whether the value settings of some annotations (including enterprise-defined annotations) are reasonable, such as whether the annotations that control the environment in which swagger is applicable exclude the production environment, and whether the annotations that control the excluded startup classes are properly configured. The problems found here can be checked and compared again after the project is updated to confirm whether they have been fixed;

[0121] 18) Upload the above information as project and interface metadata to the server for storage, and then delete the temporary files and folders generated in the above process from the client.

[0122] It should be noted that if the published file of the business project is not an image, such as a jar or war file, the technical solution in this case is actually a subset of the above solution: first obtain the uniform resource descriptor object corresponding to the file, and then use a targeted compressed file method to analyze and process the content of the published file in a similar manner to the above solution.

[0123] Compared with solutions based on logs, injecting bytecode into runtime business system processes, directly modifying R&D codes, etc. to obtain interface addresses and business call topology information, this solution is simple to implement, the corresponding client tool has low resource consumption during runtime, and can be flexibly deployed on any server (including non-production servers). It does not need to have any impact on the code in the development process or the business system at runtime. It can obtain extensive metadata of the interface and its business projects without the need to rely on the original development code, avoid cross-departmental coordination and code security issues, and promptly discover and handle security risks such as vulnerabilities that may exist in the business system before the project goes online. It can also obtain more in-depth data that other solutions cannot obtain, such as the topological relationship between business functions / interfaces and their dependencies (other interfaces, middleware, databases, etc.), the specific number of times the interface calls each external resource, and the characteristics of the interface implementation, from a finer granularity such as the interface.

[0124] The following describes the process of implementing interface metadata analysis on the server side.

[0125] Common deficiencies in business access log analysis services include: in addition to the actual access logs of the interfaces, they contain a large number of static files (css, js, images, etc.) and logs of abnormal access behaviors. It is difficult to determine whether the logs are normal business access behaviors based solely on the data in the abnormal logs themselves. In addition, logs based solely on a period of time are likely to overlook inactive or low-activity interfaces, resulting in the inability to use log data to evaluate the efficiency, quality, and operational performance of interface development.

[0126] To solve the above problems, the embodiments of the present invention combine the actual access logs of the business projects to calculate the interface access (normal and abnormal access) and error interface link information, and further obtain the actual access volume after the business project is deployed and launched, and the interfaces that are rarely or never accessed.

[0127] In addition, the related art discloses a vulnerability repair method, device and container cluster management system, which can also find vulnerabilities in the image. It needs to extract project dependencies from the project's deployment configuration file, or decompress the image to the disk, then read / traverse the decompressed file to find the image operating system and its installed software package and its version number, and then judge whether there is a vulnerability based on this information. The shortcomings of this solution: ① It needs to rely on other files outside the project deployment file; ② There is no solution for how to successfully image compressed files of different formats; ③ It cannot detect vulnerabilities in software packages that are not installed on the image operating system, nor can it detect vulnerabilities in software packages that do not contain version numbers in the file name. If the software vulnerability is located in the file after the project is packaged and then embedded in the image, the solution does not explain whether it can be processed; ④ The performance is low. Considering that the image file is often hundreds of MB or even larger, decompressing and processing a large number of image files also requires disk space. The embodiments of the present invention can also overcome the above problems.

[0128] like Figure 3 FIG. 1 is another flow chart of the steps of the interface metadata processing method provided by an embodiment of the present invention, referring to FIG. Figure 3 As an optional implementation, the interface metadata processing method further includes the following steps:

[0129] S201, updating the software security information base of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection results;

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

[0131] S203, filtering invalid access logs according to interface metadata, and performing abnormal access analysis, thereby calculating the effective access volume and access quality of each interface, and determining invalid / inefficient interfaces according to the effective access volume and access quality;

[0132] S204, classifying each interface according to the functional description to obtain multiple interface categories, and then determining the number of interfaces, interface distribution location, and total effective access volume of each interface category;

[0133] S205: construct an interface access topology according to the access resource list, and provide the interface access topology to the client through the server.

[0134] like Figure 6 FIG. 1 is a flow chart of step S201 provided in an embodiment of the present invention, referring to FIG. Figure 6 As an optional implementation, a project early warning is performed according to the interface metadata and the detection results, which specifically includes:

[0135] S2011. Determine whether the image file has security risks and whether there are duplicate packaged files according to the detection results;

[0136] S2012. When the image file has security risks and / or duplicate package files, determine the project maintainer based on the interface metadata and issue a project warning to the project maintainer;

[0137] Among them, project early warning is used to remind project maintainers to repair the image file before formal deployment.

[0138] like Figure 7 FIG. 1 is a flow chart of step S203 provided in an embodiment of the present invention, referring to FIG. Figure 7 As an optional implementation method, invalid access logs are filtered according to interface metadata, and abnormal access analysis is performed to calculate the effective access volume and access quality of each interface, and invalid / inefficient interfaces are determined according to the effective access volume and access quality, which specifically includes:

[0139] S2031, determining the interface address, request method, and access resource list according to the interface metadata;

[0140] S2032, determining the corresponding target service according to the access resource list, and querying the access log of the target service according to the interface address and the request method to obtain a valid access log, and treating the access log that does not belong to the valid access log as an invalid access log;

[0141] S2033, counting the abnormal access source IP and the geographical area according to the invalid access log, and determining the interface actually accessed by the abnormal access source IP and the corresponding abnormal access volume;

[0142] S2034, counting the effective access volume, access error number and 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 volume, access error number and access performance data;

[0143] S2035. Determine whether each interface is an invalid / inefficient interface based on the effective access volume, access quality, and a preset threshold.

[0144] like Figure 8 FIG. 1 is a flow chart of step S205 provided in an embodiment of the present invention, referring to FIG. Figure 8 As an optional implementation, an interface access topology is constructed according to the access resource list, which specifically includes:

[0145] S2051, determining the calling relationship between each interface and the external resource instance according to the access resource list;

[0146] S2052, taking each interface and multiple external resource instances as nodes, and determining the topological connection relationship and actual calling direction between each node according to the calling relationship;

[0147] S2053. Connect each node according to the topological connection relationship and the actual calling direction to obtain the interface access topology.

[0148] Specifically, the process of implementing interface metadata analysis on the server is as follows:

[0149] 1) The server stores the interface metadata of the business projects obtained above, including which image files, projects and their interfaces have been analyzed. In addition, based on the latest security vulnerability information of software and public libraries disclosed by the industry, a local software security information library is established and continuously updated;

[0150] 2) The server summarizes all the vulnerabilities and security risk information found above, and warns the maintainers of the relevant projects on a project-by-project basis, reminding them to fix the problems before formal deployment. Next, after the new image is constructed, it automatically checks whether the corresponding files in the business image have been updated and the problems have been fixed according to the above steps. If updated, the problem resolution time is recorded according to the "modification time" field in the corresponding compressed file. Otherwise, it is recorded as unfixed and the user is warned.

[0151] 3) Using the interface address and interface implementation code obtained above, you can also add a brief introduction to the project business, use LoRA based on Qianwen or other large language models to train and fine-tune the interface function description. In this way, you can get a private large language model that is suitable for the R&D specifications and habits of an enterprise and can more accurately determine the purpose of an interface; then use LoRA to merge the trained model data and the original model data to obtain new large model data. Use the new large language model to generate the function and purpose description of each interface found above based on the interface address, code and project information as part of the metadata of each interface;

[0152] 4) Query the access log of the corresponding service based on the accurate interface address, all request parameters supported by the interface, and the request method supported by the interface that are automatically discovered above. The logs with the same combination of actual access address, request method, and request parameters as those linked to a certain interface are valid access logs. Exclude invalid access logs from the public network (such as interface and data scanning, attack on business systems, etc.), and other access logs of static files of the project should also be excluded;

[0153] 5) Abnormal access judgment and analysis: Based on the information obtained in the previous part, find the source IP and geographical area of ​​abnormal access, check the access log of the correct interface address actually accessed by each access source, calculate the interface concerned by abnormal behavior and the abnormal access volume of the corresponding interface;

[0154] 6) Calculate the access volume, last access time, access quality (number of access errors and abnormal access times, access performance, etc.) of each interface within a certain period of time based on the remaining valid access logs. The average, maximum, minimum and variance of each indicator can be calculated;

[0155] 7) According to the interface list of the actual project module, microservice, project, and product dimensions, support adjusting the specific interfaces included in the list of each dimension according to actual work needs, and calculate the access volume and access / operation quality of each dimension of the module, microservice, project, and product. Further, all interfaces are divided into different levels according to the access volume and access quality, highlighting all interfaces with higher levels, lower levels, no access, or access below a certain threshold. According to the project release file, the decompiled code of the corresponding interface is provided through the UI for viewing at any time;

[0156] 8) According to the access volume and access quality, combined with the interface code volume obtained from the file compiled by decompiling the interface or the interface code volume calculated from the actual source code, calculate and analyze the access volume, access quality and corresponding code volume of each category of interface, highlight the access volume and access quality of the actually developed code, and treat the interface with access volume below a certain threshold as an invalid or inefficient interface. This part of the data can be used to analyze and compare the application efficiency of the actually developed code and set different efficiency levels based on the actual situation. Through quantitative data, highlight interfaces, related projects and even developers with different code efficiency levels. Synchronously mark the data obtained in the steps here on the interface topology, and record the interface address for which no access record can be found as an inactive interface;

[0157] 9) Remove parameters from all actual interface links and extract the part after the rightmost slash. Then, use word embedding, text classification model or large language model to find other interfaces with the same or similar functions for any interface. In this way, the functions of all interfaces are classified according to semantics, and the functional similarity between interfaces is recorded. The specific number of interfaces included in each interface category, the categories in which they are distributed, and the total number of visits to each category of interfaces are calculated. The historical problems that have occurred in the interface can be further used as a classification standard and the resulting category can be used as a label reflecting the characteristics of the interface. Then, find out the functions or functional categories of interfaces with very few visits or high code similarity;

[0158] 10) According to the resources that an interface needs to access (including other interfaces), draw the call topology relationship and the business from the interface to each external resource instance (other interfaces called by the interface, as well as middleware and database), use nodes of different shapes to represent interfaces and different types of external resources, display the access address for each node, further add this topology relationship of other interfaces to the topology, and connect the interfaces with actual call relationships on the topology map according to the actual call direction, which can increase the level of the topology, so that a multi-level interface call topology map for any interface and different types of external middleware and databases called by it can be provided on the server UI. According to the one-to-one correspondence between the log source, destination and the corresponding topological node and connection line, mark the interface access quality data obtained above to the corresponding topological node and connection line respectively, and draw the corresponding external resource access number and access trigger condition on the topology map according to the interface access log according to the number of external resource accesses corresponding to a call of the interface obtained above;

[0159] 11) The server can also integrate the interface metadata of all business projects to provide a series of practical services to the outside world, such as: ① Through the UI, all interfaces, databases, and middleware resources on each interface call chain are intuitively displayed to users; ② When an interface alarm or failure is found, based on the call relationship between interfaces and the external resources that the interface depends on, it is convenient to find the lowest interface on the call chain, or analyze the impact scope of an interface alarm or failure and whether the runtime problem of the interface is affected by the interface called by it; ③ By merging the alarm data of each interface in the interface call joint debugging, the effect of convergence alarm and control of the number of alarms notified to users can be achieved;

[0160] 12) Combined with the server actually deployed in the project to which the interface belongs and its CPU and memory configuration, analyze the interface access volume that can be served by each project unit computing resource (e.g. 1 core CPU 1GB memory) in a certain period of time (e.g. every day), and the project traffic that can be served by each unit computing resource calculated by merging the input and output traffic of all the project interfaces. This is used as the interface resource utilization rate of the project, and supports quantitative analysis of resource usage and utilization rate of specific functions, execution / access times in any time period from a business perspective by business and department.

[0161] The method steps of the embodiment of the present invention are described above, and it can be recognized that the embodiment of the present invention realizes the automatic discovery and collection and analysis of interface metadata, and improves the accuracy and comprehensiveness of the collection and analysis of interface metadata. The present invention is further described below in conjunction with a specific embodiment.

[0162] In order to collect and report information on interfaces open to the public network for a series of businesses and identify security risks of the interfaces, an Internet company A spent several months mobilizing employees to manually collect and summarize open interface information and access randomly generated interface links for business domain names. Although a long period of human research and development and a large amount of manual work were invested, problems still arose, including incomplete reported data, incomplete interface links, data errors and irregularities, duplications, and a large amount of junk data. Based on the interface metadata processing method provided by the present invention, automatic collection of interface information facing the internal and external networks can be achieved, and accurate links and request methods of all interfaces open to the public network can be automatically obtained without manual intervention. The resulting data also helps to use interfaces as the basis and object for in-depth resource management and protection. The main implementation steps are as follows:

[0163] 1) After the business system is packaged as an image or jar file from the CI / CD service or the image packaging plug-in of Maven or Gradle, the tool here is automatically called to analyze the business release file;

[0164] 2) The server can view the metadata of each project and its interface reported by the client tool at any time, and can see which project's release files have been analyzed and processed. It can also accurately obtain all the project's interface addresses and whether their implementations comply with the specifications and whether there are any risks.

[0165] 3) You can further see the project dependencies and whether any project has any security vulnerabilities based on the latest public software security risk information. You can also learn specific information such as the risks that exist and whether the risks have been fixed;

[0166] 4) The results of interface metadata analysis can also help analyze the resource consumption of the business from the interface dimension, and help to find out which functions and interfaces the business resources are mainly consumed on, thereby promoting the adjustment of the functional scope of different projects to achieve the purpose of controlling resource usage.

[0167] It can be recognized that the embodiment of the present invention starts with the project release files that are packaged for formal deployment, and can automatically collect "extensive" metadata of business projects and their interfaces from these files before the project goes online, including projects and their dependencies, interface addresses, and key implementation features of interfaces, and further supports automatic inspection of project dependencies and security risks and repair situations of interface implementations, without the need for manual intervention or cross-departmental coordination, and also avoids the risk of source code security. In addition, the embodiment of the present invention integrates the client and the server, and implements the topology of interface access resources and call relationships between interfaces based on interface metadata, and further analyzes business access logs based on interface metadata, evaluates and determines the actual access volume, abnormal access volume, and access quality of interfaces, modules, microservices, projects, and products, and simultaneously provides specific interfaces and corresponding codes with different access volume and access quality levels and corresponding quantitative data on R&D efficiency and quality, and automatically provides labels reflecting interface features and resource utilization of business projects in interface dimensions based on interface functional semantics.

[0168] Compared with the prior art, the embodiments of the present invention also have the following advantages:

[0169] 1) The solution is simple to develop, easy to use, and can be flexibly deployed. It can effectively reduce unnecessary cross-departmental communication and collaboration, allowing the operation and maintenance department to independently complete the gateway work and accurately find the extensive metadata information of the interface and the business project to which it belongs based on the release documents of the business project;

[0170] 2) Support drawing the actual topology of external middleware, database and calling relationship between interfaces based on interface metadata and with interface as the center;

[0171] 3) Supporting the use of interface addresses as important resources, the management of business projects and their resources is deepened to management based on interface information, which helps to quickly and accurately discover inactive or rarely accessed interfaces in combination with interface topology, and helps to control the use of cloud network resources by adjusting the functional scope of different projects;

[0172] 4) Interface topology data is widely used and has great practical value. It can compress the number of alarm notifications sent to operation and maintenance personnel based on the interface call topology, and is helpful in finding the underlying factors that cause interface problems.

[0173] like Fig. 9 FIG. 1 is a schematic diagram of the structure of the interface metadata processing device provided by an embodiment of the present invention, referring to FIG. Fig. 9 , an embodiment of the present invention provides an interface metadata processing device, comprising:

[0174] A project path determination module is used to read the image file of the business project, collect business project information according to the image file, and determine the specific project path of the business project in the image file;

[0175] The image file content detection module is used to perform security risk detection on the content of the image file, detect whether there are duplicate packaged files, and upload the detection results to the server;

[0176] The interface file search module is used to find the interface file path in the image file through decompilation technology according to the specific path of the project, and decompress the corresponding interface files and configuration files to a temporary directory;

[0177] The interface metadata search module is used to search for the context configuration of the business project from the configuration file, and to search for the corresponding interface address, request method, and access resource list from the file to which the interface belongs;

[0178] The interface metadata upload module is used to upload the context configuration, interface address, request method, and access resource list as the interface metadata of the business project to the server.

[0179] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0180] The embodiment of the present invention further provides an electronic device, the electronic device comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory, wherein the program is executed by the processor to realize the above-mentioned interface metadata processing method. The electronic device may be any intelligent terminal including a tablet computer, a vehicle-mounted computer, etc.

[0181] like Fig.10 FIG. 1 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention, referring to FIG. Fig.10 , an embodiment of the present invention provides an electronic device, including:

[0182] The processor 1001 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention.

[0183] 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 (RAM). The memory 1002 may store an operating system and other application programs. When the technical solution provided in the embodiments of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1002, and the processor 1001 calls and executes the interface metadata processing method of the embodiment of the present invention;

[0184] Input / output interface 1003, used to implement information input and output;

[0185] The communication interface 1004 is used to realize the communication interaction between the device and other devices. The communication can be realized through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WIFI, Bluetooth, etc.);

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

[0187] The processor 1001 , the memory 1002 , the input / output interface 1003 and the communication interface 1004 are connected to each other in communication within the device via the bus 1005 .

[0188] like Fig.11 FIG. 1 is a schematic diagram of the structure of a storage medium provided in an embodiment of the present invention, referring to FIG. Fig.11 The embodiment of the present invention further provides a storage medium, which is a computer-readable storage medium used for computer-readable storage. The storage medium stores one or more programs 1101, and the one or more programs 1101 can be executed by one or more processors to implement the above-mentioned interface metadata processing method.

[0189] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0190] The embodiment of the present invention also discloses a computer program product or a computer program, wherein the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes Figure 1 The method shown.

[0191] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the above-mentioned boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.

[0192] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise specified to the contrary, one or more of the above-mentioned functions and / or features can be integrated into a single physical device and / or software module, or one or more functions and / or features can be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the conventional skills of the engineer. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0193] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the above methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0194] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in conjunction with such instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in conjunction with such instruction execution systems, devices or apparatuses.

[0195] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and editable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the above-mentioned program is printed, since the above-mentioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or processing in other suitable ways as necessary, and then stored in a computer memory.

[0196] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0197] In the above description of this specification, the description with reference to the terms "one embodiment / example", "another embodiment / example" or "certain embodiments / examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0198] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

[0199] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A method for processing interface metadata, characterized in that: The following steps are involved: Reading an image file of a business project, collecting business project information according to the image file, and determining a specific project path of the business project in the image file; Perform security risk detection on the content of the image file, detect whether there are duplicate packaged files, and upload the detection results to the server; According to the specific path of the project, the interface file path in the image file is found through decompilation technology, and the corresponding interface files and configuration files are decompressed into a temporary directory; Searching for the context configuration of the business project from the configuration file, and searching for the corresponding interface address, request method and access resource list from the file to which the interface belongs; The context configuration, the interface address, the request method and the access resource list are uploaded to the server as the interface metadata of the business project.

2. The method for processing interface metadata according to claim 1, characterized in that: The interface metadata processing method further comprises the following steps: Updating the software security information base of the server according to the interface metadata, and performing project early warning according to the interface metadata and the detection result; Generate a functional description corresponding to each interface according to the interface metadata; Filter invalid access logs according to the interface metadata, perform abnormal access analysis, and then calculate the effective access volume and access quality of each interface, and determine invalid / inefficient interfaces according to the effective access volume and the access quality; Classify each interface according to the functional description to obtain multiple interface categories, and then determine the number of interfaces, interface distribution location, and total effective access volume of each interface category; An interface access topology is constructed according to the access resource list, and the interface access topology is provided to the client through the server.

3. The method for processing interface metadata according to claim 1, characterized in that: The collecting of the business project information according to the image file and determining the specific project path of the business project in the image file specifically includes: Search the preset file name field in the first layer of the image file to obtain the target JSON file; Parse the target JOSN file to obtain the business project information, including the project maintainer, business project file working path, business application file name, image build time, image file size, image file MD5 code, operating environment requirements, externally exposed port number, and basic image data; Read the compressed files of each folder inside the image file layer by layer, and determine whether the compressed files contain the working path of the business project file and the business application file name; If so, determine the specific path of the project according to the file path of the compressed file.

4. The method for processing interface metadata according to claim 1, characterized in that: The method of searching the interface file path in the image file by decompiling technology according to the specific path of the project, and decompressing the corresponding interface files and configuration files to a temporary directory specifically includes: Search the compiled class file in the image file according to the specific path of the project; Decompiling the class file to obtain class definition information, and determining the interface corresponding to the class file according to the class definition information, and then determining the interface file path; A temporary directory is created, and the corresponding interface-related files and configuration files are determined according to the interface file path, and the interface-related files and configuration files are decompressed into the temporary directory.

5. The method for processing interface metadata according to claim 2, characterized in that: The project early warning is performed according to the interface metadata and the detection result, which specifically includes: Determine whether the image file has security risks and whether there are duplicate packaged files according to the detection result; When the image file has security risks and / or duplicate packaged files, determine the project maintainer according to the interface metadata, and issue the project warning to the project maintainer; The project warning is used to remind the project maintainer to repair the image file before formal deployment.

6. The method for processing interface metadata according to claim 2, characterized in that: The filtering of invalid access logs according to the interface metadata, and performing abnormal access analysis, thereby calculating the effective access volume and access quality of each interface, and determining invalid / inefficient interfaces according to the effective access volume and the access quality, specifically includes: Determine the interface address, the request method, and the access resource list according to the interface metadata; Determine the corresponding target service according to the access resource list, query the access log of the target service according to the interface address and the request method to obtain a valid access log, and use the access log that does not belong to the valid access log as the invalid access log; According to the invalid access log, count the abnormal access source IP and the geographical area to which it belongs, and determine the interface actually accessed by the abnormal access source IP and the corresponding abnormal access volume; Counting the effective access volume, the number of access errors 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 volume, the number of access errors and the access performance data; Whether each interface is an invalid / inefficient interface is determined according to the effective access amount, the access quality and a preset threshold.

7. The method for processing interface metadata according to claim 2, characterized in that: The step of constructing an interface access topology according to the access resource list specifically includes: Determine the calling relationship between each interface and the external resource instance according to the access resource list; Taking each interface and a plurality of the external resource instances as nodes, determining the topological connection relationship and the actual calling direction between the nodes according to the calling relationship; The nodes are connected according to the topological connection relationship and the actual calling direction to obtain the interface access topology.

8. An interface metadata processing device, characterized in that: include: A project path determination module, used to read the image file of the business project, collect business project information according to the image file, and determine the specific project path of the business project in the image file; The image file content detection module is used to perform security risk detection on the content of the image file, detect whether there are duplicate packaged files, and upload the detection results to the server; An interface file search module is used to search the interface file path in the image file through decompilation technology according to the specific path of the project, and decompress the corresponding interface files and configuration files into a temporary directory; An interface metadata search module, used to search for the context configuration of the business project from the configuration file, and to search for the corresponding interface address, request method and access resource list from the file to which the interface belongs; The interface metadata uploading module is used to upload the context configuration, the interface address, the request method and the access resource list as the interface metadata of the business project to the server.

9. An electronic device, characterized in that: The electronic device includes a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory. When the program is executed by the processor, the steps of the interface metadata processing method as described in any one of claims 1 to 7 are realized.

10. A storage medium, the storage medium being a computer-readable storage medium, used for computer-readable storage, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the interface metadata processing method as described in any one of claims 1 to 7.

Images