Open source component governance method, mec service node, application, medium and system

CN115730315BActive Publication Date: 2026-09-11CHINA UNITED NETWORK COMM GRP CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202211455093.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-11-21
Publication Date
2026-09-11
Estimated Expiration
2042-11-21

AI Technical Summary

Technical Problem

[0003]本发明所要解决的技术问题是针对现有技术的上述不足,提供一种开源组件治理方法、MEC服务节点、应用终端、介质及系统,以解决现有技术在应用端直接调用开源组件,导致大量的应用均需要各自下载相同的开源组件,造成资源和时间的浪费的问题

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115730315B_ABST
    Figure CN115730315B_ABST
Patent Text Reader

Abstract

The application provides an open source component management method, an MEC service node, an application, a medium and a system, relates to the technical field of software, and is used for solving the problem that a large number of applications need to download the same open source component in the prior art when the open source component is directly called at the application end. The method comprises the following steps: when receiving a calling requirement of a subordinate application for an open source component, allocating memory for the open source component called by the subordinate application according to the calling requirement; storing the open source component called by the subordinate application in the allocated memory to form an application open source component library, so that the subordinate application remotely calls the open source component in the application open source component library. According to the application, the MEC service node establishes an application open source component library according to the requirement of the application for calling the open source component, and the application remotely calls the open source component from the application open source component library, so that the open source component does not need to be downloaded to the local for calling, and the downloading time and the local resource are saved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to an open-source component governance method, MEC service node, application terminal, medium, and system. Background Technology

[0002] Open-source component packages provide a wealth of foundational code, reducing the burden on developers. Referencing open-source components is a common practice during the software supply chain coding phase. Currently, the common method for invoking open-source components is for development tools to automatically download component packages from internet component libraries or pull them from a company-built component library. The drawback of this approach is that directly calling open-source components on the application side results in numerous applications needing to download the same open-source components, wasting resources and time, and hindering real-time updates and security protection of open-source components. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to address the above-mentioned shortcomings of the prior art by providing an open source component governance method, MEC service node, application terminal, medium and system, so as to solve the problem that the prior art directly calls open source components at the application end, which leads to a large number of applications having to download the same open source components, resulting in a waste of resources and time.

[0004] In a first aspect, the present invention provides an open-source component governance method applied to edge computing MEC service nodes, the method comprising:

[0005] When a subordinate application requests an open-source component, memory is allocated to the open-source component that the subordinate application needs to call, based on the request.

[0006] The allocated memory stores the open-source components that the subordinate applications need to call, forming an application open-source component library, so that the subordinate applications can remotely call the open-source components in the application open-source component library.

[0007] Optionally, before receiving a request from a subordinate application to invoke the open-source component, the method further includes:

[0008] Synchronize the latest versions of the open-source components required for the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service node;

[0009] The latest version of the open-source component is synchronized from the official website of the open-source component by the MEC management terminal and stored in the open-source component general library of the MEC management terminal.

[0010] Optionally, the provision for the subordinate application to remotely invoke open-source components in the application's open-source component library specifically includes:

[0011] When a remote call request for an open-source component is received from the subordinate application, the open-source component vulnerability is detected by using pre-stored detection rules on the parameters carried in the remote call request.

[0012] If the vulnerability detection of the open-source component is passed, the subordinate application is allowed to remotely call the open-source component from the application's open-source component library through the parameters carried in the remote call request, and send the running result after calling the open-source component to the subordinate application.

[0013] Optionally, before receiving a remote call request from the subordinate application for a pre-stored open-source component, the method further includes:

[0014] Synchronize the detection rules of the open-source components required for MEC services from the MEC management terminal to form the pre-stored detection rules;

[0015] The detection rules for open-source components are obtained by security personnel based on the attack or vulnerability after the open-source component is attacked or a vulnerability is discovered, and then uploaded to the detection rule library of the MEC management terminal.

[0016] Optionally, after synchronizing the detection rules for the open-source components required for the MEC service from the MEC management console, the method further includes:

[0017] If the latest version of a certain open-source component is received, and the previously stored version of the open-source component is replaced with the latest version of the open-source component, then the pre-stored detection rule corresponding to the open-source component is deleted from the MEC service node itself.

[0018] Secondly, this invention provides an open-source component governance method applied to subordinate applications of edge computing MEC service nodes, the method comprising:

[0019] Send a request for calling open-source components to the MEC service node, so that the MEC service node allocates memory for the open-source components to be called by the subordinate application according to the request, and stores the open-source components to be called by the subordinate application in the allocated memory to form an application open-source component library;

[0020] Remotely invoke open-source components in the application's open-source component library to the MEC service node.

[0021] Optionally, the step of remotely invoking open-source components in the application open-source component library to the MEC service node specifically includes:

[0022] Send a remote call request for an open-source component to the MEC service node. The remote call request carries parameters so that the MEC service node can use pre-stored detection rules to perform open-source component vulnerability detection on the parameters.

[0023] The system receives the execution result of calling the open-source component sent by the MEC service node. The execution result is obtained by remotely calling the open-source component from the application open-source component library through the parameters carried in the remote call request after passing the vulnerability detection of the open-source component.

[0024] Thirdly, the present invention provides an edge computing MEC service node, comprising:

[0025] The allocation module is used to allocate memory for the open source components that the subordinate application needs to call, based on the call request, when it receives a call request for open source components from a subordinate application.

[0026] The library creation module, connected to the allocation module, is used to store the open-source components required by the subordinate application in the allocated memory to form an application open-source component library, so that the subordinate application can remotely call the open-source components in the application open-source component library.

[0027] Fourthly, the present invention provides a terminal on which subordinate applications of an edge computing (MEC) service node are installed, including:

[0028] The demand module is used to send the subordinate application's call request for open source components to the MEC service node, so that the MEC service node allocates memory for the open source components to be called by the subordinate application according to the call request, and stores the open source components to be called by the subordinate application in the allocated memory to form an application open source component library.

[0029] The calling module, connected to the demand module, is used by the subordinate application to remotely call open-source components in the application's open-source component library to the MEC service node.

[0030] Fifthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when run by a processor, implements the open-source component governance method described above.

[0031] Sixthly, the present invention provides an open-source component governance system, comprising:

[0032] Edge computing MEC service nodes are used to implement the open-source component governance methods described above;

[0033] The application, which belongs to the MEC service node, is used to implement the open-source component governance method described above.

[0034] Optionally, the system further includes:

[0035] The MEC management terminal connects to the MEC service node and is used to synchronize the latest versions of the open-source components required for the MEC service to the MEC service node.

[0036] This invention provides an open-source component governance method, an MEC service node, an application terminal, a medium, and a system. The MEC service node establishes an application open-source component library based on the needs of downstream applications to call open-source components. Applications can call open-source components from the application open-source component library of the MEC service node through remote calls. Applications do not need to download open-source components to their local machines for calling, saving download time and local resources. Attached Figure Description

[0037] Figure 1 This is a flowchart of an open-source component governance method according to an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of the structure of an open-source component governance system according to an embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the structure of an open source component vulnerability detection system in an open source component governance system according to an embodiment of the present invention;

[0040] Figure 4 This is a flowchart of another open-source component governance method according to an embodiment of the present invention;

[0041] Figure 5 This is a schematic diagram of the structure of an MEC service node according to an embodiment of the present invention;

[0042] Figure 6 This is a schematic diagram of the structure of a terminal according to an embodiment of the present invention. Detailed Implementation

[0043] To enable those skilled in the art to better understand the technical solution of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0044] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining the invention and are not intended to limit the invention.

[0045] It is understood that, without conflict, the various embodiments and features in the embodiments of the present invention can be combined with each other.

[0046] It is understood that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, while the parts unrelated to the present invention are not shown in the drawings.

[0047] It is understood that each unit or module involved in the embodiments of the present invention may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.

[0048] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this invention may occur in a different order than that marked in the accompanying drawings.

[0049] It is understood that the flowcharts and block diagrams of this invention illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of the invention. Each block in the flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagram and flowchart can be implemented using a hardware-based system to achieve the specified function, or using a combination of hardware and computer instructions.

[0050] It is understood that the units and modules involved in the embodiments of the present invention can be implemented by software or by hardware. For example, the units and modules can be located in a processor.

[0051] To better understand this invention, we will first introduce the open-source component calling architecture.

[0052] Developing software using open-source components is a very common software development approach. Some frequently used open-source components are called by a large amount of software code. The calling methods vary: some involve writing the component version number in a configuration file, which the programming tool then pulls it from the internet; others involve software companies building their own open-source component libraries and pulling the packages from the official websites of various open-source components. For example, in programming tools like IntelliJ IDEA (an integrated development environment for Java), when a certain open-source component is referenced in the code, it is automatically downloaded to the local machine and called within the code project. This undoubtedly wastes local resources and download time.

[0053] Another issue is that the discovery of vulnerabilities in commonly used open-source components poses a significant security threat to a large number of applications, essentially a nuclear-level attack. Currently, the method for protecting open-source component vulnerabilities is to pull the latest version of the component and replace it with the vulnerabilities found through open-source component detection systems or the internet, then repackage and release the application to fix the vulnerabilities. For widely deployed applications and numerous referenced open-source components, upgrading all software packages is a massive undertaking and prone to omissions. There are also methods to deploy application protection systems such as RASP (a new application security protection technology) to monitor and defend against attacks on open-source components, but introducing security measures for every single application is prohibitively costly.

[0054] In view of this, this invention proposes managing open-source component packages through MEC (Multi-access Edge Computing). A portion of memory is allocated to different applications to store the open-source software packages required by those applications, and the methods are introduced into the applications via remote invocation. When an application detects an attack targeting an open-source component, the attack rules are analyzed and extracted, synchronized to the remote MEC management side, and simultaneously distributed to various local MEC service nodes for security protection. When an open-source component is upgraded after patching vulnerabilities, the open-source component is synchronized to the local MEC service nodes through the remote MEC management side. Then, the corresponding open-source component in each application's open-source component library on the MEC service nodes is upgraded. After the upgrade, the attack rules targeting that component are deleted. The application only needs to restart to complete the component upgrade, thereby patching the vulnerability.

[0055] Example 1:

[0056] like Figure 1 As shown, Embodiment 1 of the present invention provides an open-source component governance method, applicable to, for example... Figure 2 Edge computing MEC service node, the method includes:

[0057] S11. Upon receiving a request from a subordinate application to call an open-source component, allocate memory for the open-source component to be called by the subordinate application according to the request.

[0058] S12. Store the open-source components required by the subordinate application in the allocated memory to form an application open-source component library, so that the subordinate application can remotely call the open-source components in the application open-source component library.

[0059] Specifically, in this embodiment, as Figure 2 As shown, when an application needs to call an open-source component package, it sends a request to the MEC service node it connects to. The corresponding MEC service node allocates a block of memory to store the open-source software package required by the application, establishing an application open-source component library. The application code calls the open-source component remotely. When the component is no longer referenced in the code, it is downloaded to the local machine and called in the code project. It can be understood that the application, as a program, is usually installed on the terminal, and the terminal, as the application's carrier, provides the hardware device foundation for the application to implement the above functions. Figure 2The terminal is not shown. The method involves the MEC service node allocating a memory block to store the open-source component packages called by the application according to the needs of the downstream application to call open-source components, and establishing an application open-source component library for the application to call. The application calls the open-source components from the application open-source component library of the MEC service node through remote calling. The application does not need to download the open-source components to the local machine (i.e., the terminal) before calling them. The data transmission speed is fast and the latency is low, saving download time and local resources.

[0060] Optionally, before receiving a request from a subordinate application to invoke the open-source component, the method further includes:

[0061] Synchronize the latest versions of the open-source components required for the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service node;

[0062] The latest version of the open-source component is synchronized from the official website of the open-source component by the MEC management terminal and stored in the open-source component general library of the MEC management terminal.

[0063] Specifically, in this embodiment, in such Figure 2 In the illustrated structure, the MEC service of the open-source component governance system is deployed in two tiers. The first tier is the remote MEC management console, which houses the central open-source component repository. This repository synchronizes all open-source component packages from the official website and keeps them up-to-date. The MEC management console collects these components according to preset criteria. The second tier is the local MEC service nodes, which pull and save commonly used components from the MEC management console for their various subordinate applications. These components are stored in their own node open-source component repositories, and their versions are kept synchronized with the MEC management console. Open-source components are synchronized to the MEC service nodes via the MEC management console. Application code invokes these components remotely. A single MEC service node can provide component services to multiple subordinate applications, ensuring unified management and real-time updates of open-source components within the applications.

[0064] Optionally, the provision for the subordinate application to remotely invoke open-source components in the application's open-source component library specifically includes:

[0065] When a remote call request for an open-source component is received from the subordinate application, the open-source component vulnerability is detected by using pre-stored detection rules on the parameters carried in the remote call request.

[0066] If the vulnerability detection of the open-source component is passed, the subordinate application is allowed to remotely call the open-source component from the application's open-source component library through the parameters carried in the remote call request, and send the running result after calling the open-source component to the subordinate application.

[0067] Specifically, in this embodiment, in such Figure 2and 3 As shown, when an application calls an open-source component, the open-source component vulnerability detection function of the MEC service node will check the parameters carried in the call request according to its own pre-stored detection rules. If an attack is detected (such as the parameters containing attack parameters), the call will be blocked directly. If the call parameters are confirmed to be safe, the application will be allowed to call the required component and the running result after the component call will be returned to the application, thus successfully calling the component. Figure 2 and 3 The open-source component vulnerability detection function can obtain every parameter value during code execution and synchronize the parameter rules of the vulnerable components on its own MEC service node. When an application calls a function of a component in the component library, it carries input parameters. By hooking this function in the application, the input parameter values ​​of the function can be obtained. Then, the parameter rules are used to detect the input parameter values ​​to determine whether the call request is a normal call or a disguised call containing an attack. Currently, open-source component vulnerability detection is basically based on matching version numbers and vulnerability database data, without reaching the code level. This solution delves into the code of the open-source component and uses protection technologies such as RASP to obtain every parameter value during code execution. It realizes centralized detection of open-source component vulnerabilities at the MEC service node, and can check the call parameters according to preset rules, achieving fine-grained security checks while reducing protection costs.

[0068] Optionally, before receiving a remote call request from the subordinate application for a pre-stored open-source component, the method further includes:

[0069] Synchronize the detection rules of the open-source components required for MEC services from the MEC management terminal to form the pre-stored detection rules;

[0070] The detection rules for open-source components are obtained by security personnel based on the attack or vulnerability after the open-source component is attacked or a vulnerability is discovered, and then uploaded to the detection rule library of the MEC management terminal.

[0071] Specifically, in this embodiment, in such Figure 2In the illustrated structure, when an application is attacked targeting a specific component, or when a component is found to have a vulnerability (e.g., discovered through existing technical detection methods), security personnel analyze the attack methods targeting that component (including potential attack methods), extract the attack patterns into detection rules, and report them to the remote MEC management console's detection rule library. The remote MEC management console's detection rule library then synchronizes the detection rules to the open-source component vulnerability detection functions of all MEC service nodes with corresponding component requirements. Attack method analysis can be done online; for example, a log4j vulnerability, once exposed, spreads rapidly, including its attack methods. At this point, most applications are not yet attacked, requiring security personnel to further analyze, extract the attack methods, and implement remediation. For attacks targeting a specific component, the attack packet contains attack parameters. These parameters have certain characteristics; for example, in deserialization attacks, they may contain parentheses, numbers, etc. These characteristics can be used to initially determine that the disguised call request is actually an attack on a specific component. Security personnel then need to further confirm these parameters and extract attack parameter rules, such as regular expressions for specific attack parameters. Because the MEC node network is fully interconnected, when an application (e.g., application X) is attacked, the attack can be identified through a vulnerability discovery mechanism. Security personnel analyze the characteristics of the attack to extract detection rules, which are then synchronized to the MEC management end via the connected MEC service node, and subsequently to all MEC nodes, thus providing security protection for all applications calling that component.

[0072] Optionally, after synchronizing the detection rules for the open-source components required for the MEC service from the MEC management console, the method further includes:

[0073] If the latest version of a certain open-source component is received, and the previously stored version of the open-source component is replaced with the latest version of the open-source component, then the pre-stored detection rule corresponding to the open-source component is deleted from the MEC service node itself.

[0074] Specifically, in this embodiment, in such Figure 2 In the structure shown, the MEC management terminal synchronizes the new version to each MEC service node. When the open-source component of the near-end MEC service node is upgraded and no longer contains the component with such vulnerability, the detection rule corresponding to the component is deleted. After restarting the application package (such as refreshing or rerunning the application), the component vulnerability upgrade and repair can be completed, thus synchronizing the new version to each application. It is not necessary to change the component version in the code configuration file and repackage it into an application to send to the terminal for upgrade. The upgrade method is simple and fast. When the component is upgraded, the corresponding vulnerability detection rule can be deleted, reducing resource overhead.

[0075] Example 2:

[0076] like Figure 4 As shown, Embodiment 2 of the present invention provides an open-source component governance method, applicable to, for example... Figure 2 The method for the subordinate applications of the edge computing MEC service node shown includes:

[0077] S21. Send a call request for open source components to the MEC service node, so that the MEC service node allocates memory for the open source components to be called by the subordinate application according to the call request, and stores the open source components to be called by the subordinate application in the allocated memory to form an application open source component library.

[0078] S22. Remotely invoke the open-source components in the application open-source component library to the MEC service node.

[0079] Optionally, the step of remotely invoking open-source components in the application open-source component library to the MEC service node specifically includes:

[0080] Send a remote call request for an open-source component to the MEC service node. The remote call request carries parameters so that the MEC service node can use pre-stored detection rules to perform open-source component vulnerability detection on the parameters.

[0081] The system receives the execution result of calling the open-source component sent by the MEC service node. The execution result is obtained by remotely calling the open-source component from the application open-source component library through the parameters carried in the remote call request after passing the vulnerability detection of the open-source component.

[0082] Embodiment 2 of the present invention is a process of governing open source components in interaction with Embodiment 1. The detailed interaction process has been described in Embodiment 1 and will not be repeated here.

[0083] Embodiment 2 of the present invention provides an open source component governance method, which is applied to applications that need to call open source components. The application only needs to send a request to call the open source component to the MEC service node, and then remotely call the open source component through the application open source component library established by the MEC service node. There is no need to download the open source component to the local machine for calling, which saves download time and local resources.

[0084] Example 3:

[0085] like Figure 5 As shown, Embodiment 3 of the present invention provides an edge computing MEC service node, comprising:

[0086] The allocation module 11 is used to allocate memory for the open source component to be called by the subordinate application according to the call request when it receives the call request for the open source component.

[0087] The library creation module 12 is connected to the allocation module 11 and is used to store the open-source components that the subordinate application needs to call in the allocated memory to form an application open-source component library, so that the subordinate application can remotely call the open-source components in the application open-source component library.

[0088] Optionally, the MEC service node further includes:

[0089] The synchronization module is used to synchronize the latest versions of the open-source components required for the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service node.

[0090] The latest version of the open-source component is synchronized from the official website of the open-source component by the MEC management terminal and stored in the open-source component general library of the MEC management terminal.

[0091] Optionally, the MEC service node further includes:

[0092] The detection unit is used to perform open-source component vulnerability detection on the parameters carried in the remote call request using pre-stored detection rules when it receives a remote call request for an open-source component from the subordinate application.

[0093] The execution unit, connected to the detection unit, is configured to, if the vulnerability detection of the open-source component is passed, allow the subordinate application to remotely invoke the open-source component from the application's open-source component library through the parameters carried in the remote call request, and send the execution result after invoking the open-source component to the subordinate application.

[0094] Optionally, the synchronization module is further configured to:

[0095] Synchronize the detection rules of the open-source components required for MEC services from the MEC management terminal to form the pre-stored detection rules;

[0096] The detection rules for open-source components are obtained by security personnel based on the attack or vulnerability after the open-source component is attacked or a vulnerability is discovered, and then uploaded to the detection rule library of the MEC management terminal.

[0097] Optionally, the synchronization module is further configured to:

[0098] If the latest version of a certain open-source component is received, and the previously stored version of the open-source component is replaced with the latest version of the open-source component, then the pre-stored detection rule corresponding to the open-source component is deleted from the MEC service node itself.

[0099] Example 4:

[0100] like Figure 6As shown, Embodiment 4 of the present invention provides a terminal, on which subordinate applications of an edge computing MEC service node are installed, including:

[0101] The demand module 21 is used to send the subordinate application's call request for open source components to the MEC service node, so that the MEC service node allocates memory for the open source components to be called by the subordinate application according to the call request, and stores the open source components to be called by the subordinate application in the allocated memory to form an application open source component library.

[0102] The calling module 22 is connected to the demand module 21 and is used by the subordinate application to remotely call the open source components in the application open source component library to the MEC service node.

[0103] Optionally, the calling module 22 specifically includes:

[0104] The request unit is used to send a remote call request for an open-source component to the MEC service node. The remote call request carries parameters so that the MEC service node can use pre-stored detection rules to perform open-source component vulnerability detection on the parameters.

[0105] The result unit is used to receive the running result after calling the open source component sent by the MEC service node. The running result is obtained by remotely calling the open source component from the application open source component library through the parameters carried in the remote call request after passing the vulnerability detection of the open source component.

[0106] Example 5:

[0107] Embodiment 5 of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is run by a processor, it implements the open-source component governance method as described in Embodiment 1 or Embodiment 2.

[0108] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0109] Example 6:

[0110] like Figure 2 As shown, Embodiment 6 of the present invention provides an open-source component governance system, including:

[0111] Edge computing MEC service nodes are used to implement the open-source component governance method as described in Example 1;

[0112] The application, belonging to the MEC service node, is used to implement the open-source component governance method as described in Example 2.

[0113] Optionally, the system further includes:

[0114] The MEC management terminal connects to the MEC service node and is used to synchronize the latest versions of the open-source components required for the MEC service to the MEC service node.

[0115] Meanwhile, the MEC management terminal also synchronizes the detection rules for vulnerability detection of open-source components to the MEC service nodes. Other features of the MEC management terminal, MEC service nodes and applications have been described in detail in Example 1, and will not be repeated here.

[0116] Embodiments 1-6 of this invention provide an open-source component governance method, an MEC service node, an application terminal, a medium, and a system. The MEC service node establishes an application open-source component library based on the needs of downstream applications to call open-source components. The application calls the open-source components from the application open-source component library of the MEC service node through remote invocation. The application does not need to download the open-source components to the local machine for invocation, saving download time and local resources.

[0117] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. An open-source component governance method, characterized in that, The method, applied to edge computing MEC service nodes, includes: The latest versions of the open-source components required for the MEC service are synchronized from the MEC management terminal and stored in the node open-source component library of the MEC service node. The latest versions of the open-source components are synchronized from the official website of the open-source components by the MEC management terminal and stored in the open-source component general library of the MEC management terminal. The detection rules for the open-source components required for MEC services are synchronized from the MEC management terminal to form pre-stored detection rules. The detection rules for open-source components are extracted by security personnel based on the attack or vulnerability and uploaded to the detection rule library of the MEC management terminal after the open-source component is attacked or a vulnerability is discovered. When a subordinate application requests an open-source component, memory is allocated to the open-source component that the subordinate application needs to call, based on the request. The subordinate application stores the open-source components that it needs to call in the allocated memory to form the application open-source component library of the subordinate application, so that the subordinate application can remotely call the open-source components in the application open-source component library of the subordinate application. When a remote call request for an open-source component is received from the subordinate application, the parameters carried in the remote call request are used to perform open-source component vulnerability detection using pre-stored detection rules. The parameters are obtained by hooking a function of an open-source component in the application's open-source component library in the subordinate application. If the parameters contain attack parameters, the call is directly blocked. If the latest version of a certain open source component is received, and the previously stored version of the certain open source component is replaced with the latest version of the certain open source component, then the pre-stored detection rule corresponding to the certain open source component is deleted from the MEC service node itself. The MEC management terminal connects to multiple MEC service nodes, and each MEC service node connects to multiple subordinate applications. Pre-stored detection rules are extracted based on the characteristics of the attack parameters when any application is attacked, and uploaded to the MEC management terminal, and synchronized from the MEC management terminal to all MEC service nodes.

2. The method according to claim 1, characterized in that, The provision allowing the subordinate applications to remotely invoke open-source components in the application's open-source component library specifically includes: If the vulnerability detection of the open-source component is passed, the subordinate application is allowed to remotely call the open-source component from the application's open-source component library through the parameters carried in the remote call request, and send the running result after calling the open-source component to the subordinate application.

3. An open-source component governance method, characterized in that, The method, applied to subordinate applications of edge computing MEC service nodes, includes: The MEC service node sends a request to invoke open-source components, so that the MEC service node allocates memory for the open-source components required by the subordinate application according to the request, and stores the open-source components required by the subordinate application in the allocated memory to form the application's application open-source component library. The MEC service nodes synchronize the latest versions of the open-source components required for the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service nodes. The latest versions of the open-source components are synchronized by the MEC management terminal from the official website of the open-source components and stored in the general open-source component library of the MEC management terminal. The MEC service node synchronizes the detection rules of the open-source components required by the MEC service from the MEC management terminal to form pre-stored detection rules. The detection rules of the open-source components are extracted by security personnel based on the attack or vulnerability and uploaded to the detection rule library of the MEC management terminal after the open-source component is attacked or a vulnerability is discovered. Remotely invoke open-source components from the application open-source component library of the subordinate application to the MEC service node; A remote call request for an open-source component is sent to the MEC service node. The remote call request carries parameters, which are obtained by hooking a function of an open-source component in the application's open-source component library in the subordinate application. This allows the MEC service node to perform open-source component vulnerability detection on the parameters using pre-stored detection rules. If the parameters contain attack parameters, the call is directly blocked. If the MEC service node receives the latest version of an open-source component and replaces the previously stored version of the open-source component with the latest version, the pre-stored detection rule corresponding to the open-source component is deleted from the MEC service node itself. The MEC management terminal connects to multiple MEC service nodes, and each MEC service node connects to multiple subordinate applications. Pre-stored detection rules are extracted based on the characteristics of the attack parameters when any application is attacked, and uploaded to the MEC management terminal, and synchronized from the MEC management terminal to all MEC service nodes.

4. The method according to claim 3, characterized in that, The step of remotely invoking open-source components from the application's open-source component library to the MEC service node specifically includes: The system receives the execution result of calling the open-source component sent by the MEC service node. The execution result is obtained by remotely calling the open-source component from the application open-source component library through the parameters carried in the remote call request after passing the vulnerability detection of the open-source component.

5. An edge computing MEC service node, characterized in that, include: The synchronization module is used to synchronize the latest versions of the open-source components required by the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service node. The latest versions of the open-source components are synchronized by the MEC management terminal from the official website of the open-source components and stored in the open-source component general library of the MEC management terminal. The synchronization module is also used to: synchronize the detection rules of the open source components required by the MEC service from the MEC management terminal to form pre-stored detection rules. The detection rules of the open source components are extracted and uploaded to the detection rule library of the MEC management terminal by security personnel based on the attack or the vulnerability after the open source component is attacked or a vulnerability is discovered. The allocation module is used to allocate memory for the open source components that the subordinate application needs to call, based on the call request, when it receives a call request for open source components from a subordinate application. The library creation module, connected to the allocation module, is used to store the open-source components required by the subordinate application in the allocated memory to form the application open-source component library of the subordinate application, so that the subordinate application can remotely call the open-source components in the application open-source component library of the subordinate application. The detection unit is used to detect open source component vulnerabilities in the parameters carried by the remote call request when it receives a remote call request for an open source component from the subordinate application. The parameters are obtained by hooking a function of an open source component in the application's open source component library in the subordinate application. If the parameters contain attack parameters, the call is directly blocked. The synchronization module is also used to: if it receives the latest version of a certain open source component and replaces the previously stored certain open source component with the latest version of the certain open source component, then delete the pre-stored detection rule corresponding to the certain open source component from the MEC service node itself. The MEC management terminal connects to multiple MEC service nodes, and each MEC service node connects to multiple subordinate applications. Pre-stored detection rules are extracted based on the characteristics of the attack parameters when any application is attacked, and uploaded to the MEC management terminal, and synchronized from the MEC management terminal to all MEC service nodes.

6. A terminal, characterized in that, The terminal has subordinate applications installed on the edge computing MEC service node, including: The demand module is used to send the subordinate application's call request for open-source components to the MEC service node, so that the MEC service node allocates memory for the open-source components required by the subordinate application according to the call request, and stores the open-source components required by the subordinate application in the allocated memory to form the application's application open-source component library. The MEC service nodes synchronize the latest versions of the open-source components required for the MEC service from the MEC management terminal and store them in the node open-source component library of the MEC service nodes. The latest versions of the open-source components are synchronized by the MEC management terminal from the official website of the open-source components and stored in the general open-source component library of the MEC management terminal. The MEC service node synchronizes the detection rules of the open-source components required by the MEC service from the MEC management terminal to form pre-stored detection rules. The detection rules of the open-source components are extracted by security personnel based on the attack or vulnerability and uploaded to the detection rule library of the MEC management terminal after the open-source component is attacked or a vulnerability is discovered. The calling module, connected to the demand module, is used for the subordinate application to remotely call open-source components in the application open-source component library of the subordinate application to the MEC service node, including: The request unit is used to send a remote call request to the MEC service node for an open-source component. The remote call request carries parameters, which are obtained by hooking a function of an open-source component in the application's open-source component library in the subordinate application. This allows the MEC service node to perform open-source component vulnerability detection on the parameters using pre-stored detection rules. If the parameters contain attack parameters, the call is directly blocked. If the MEC service node receives the latest version of an open-source component and replaces the previously stored version of the open-source component with the latest version, the pre-stored detection rule corresponding to the open-source component is deleted from the MEC service node itself. The MEC management terminal connects to multiple MEC service nodes, and each MEC service node connects to multiple subordinate applications. Pre-stored detection rules are extracted based on the characteristics of the attack parameters when any application is attacked, and uploaded to the MEC management terminal, and synchronized from the MEC management terminal to all MEC service nodes.

7. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the open-source component governance method as described in any one of claims 1-2 or 3-4.

8. An open-source component governance system, characterized in that, include: Edge computing MEC service nodes are used to implement the open-source component governance method as described in any one of claims 1-2; The application, belonging to the MEC service node, is used to implement the open-source component governance method as described in any one of claims 3-4.

Citation Information

Patent Citations

  • Method, system, server and client for calling remote component

    CN101631033A

  • Resource scheduling method and device, edge cloud network, program product and storage medium

    CN113301102A

  • Call management and control method and device for remote procedure call, equipment and storage medium

    CN114466053A