A JAR vulnerability detection method, system, storage medium and computer facing a container management platform

Abstract

The application relates to the technical field of computers, in particular to a JAR vulnerability detection method and system for a container management platform, a storage medium and a computer, the method comprises the following steps: compiling and packaging JAVA services, building an image, listening to a container creation event, listening to a container change event, listening to a container stop event and locating JAR, wherein the locating JAR comprises the following steps: traversing a runtime container set, checking an image version of each container ID, checking JAR dependence from the image; the application maintains the image version and JAR dependence and the runtime container ID condition, can realize real-time query of JAR dependence conditions of all currently running containers, facilitates rapid positioning of a container set associated with each JAR, provides rapid and accurate positioning of the container set containing the specific JAR in a non-intrusive mode, and facilitates rapid intervention when a security vulnerability or the like occurs.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a method, system, storage medium, and computer for detecting JAR vulnerabilities in a container management platform. Background Technology

[0002] Containers: Containers are a virtualization technology based on server resource sharing and isolation mechanisms. They facilitate application deployment, enable elastic scaling, and improve operational efficiency. Common container technologies such as Docker allow applications developed in different programming languages ​​to be deployed in containers.

[0003] Image: Such as Docker Image, an image is a template for running containers. An image is the build artifact, while a container is the runtime manifestation of it; different containers can load the same image.

[0004] Container management platform: Supports lifecycle management of images and containers. Common application methods include building images based on code repositories, creating and starting containers based on images, and managing the runtime state of containers.

[0005] JAR: A software package file format used to aggregate a large number of Java class files. Java program development generally relies on several open-source or custom-developed JARs.

[0006] MAVEN: A Java project management and build tool used to manage the JAR files and versions that Java projects depend on, and provides build tools such as compilation and packaging.

[0007] Application deployment methods: Common deployment methods include server deployment and container deployment. Server deployment refers to the application being deployed directly on the server's operating system, which may have exclusive resources or share resources with other services. Container deployment refers to building an image based on the service and loading and running it as a container. Container deployment is beneficial for resource sharing and isolation, and facilitates elastic scaling and operation and maintenance management of service capabilities. Container deployment is commonly found on different PaaS platforms such as public cloud, private cloud, and hybrid cloud, and is one of the main service models for cloud services.

[0008] Java application development model: Java service development widely relies on open-source JARs, commonly including application and database frameworks such as Spring, Hibernate, and iBatis; logging frameworks such as log4j and logback; middleware clients such as Redis and ElasticSearch; and tools for processing network, file, and string data. Generally, a Java service often depends on dozens of JARs.

[0009] JAR dependency detection: JAR dependencies are in a tree structure. A Java service depends on multiple first-level JARs, and each first-level JAR depends on multiple second-level JARs. Different first-level JARs can depend on the same second-level JARs. First-level JAR packages can also be dependencies of other first-level JAR packages. MAVEN provides a solution to avoid introducing different versions of the same JAR.

[0010] Dependency detection has multiple applications, such as static analysis, used to check for JAR version conflicts. This application discusses a JAR dependency detection method for container management platforms, emphasizing runtime checks, primarily for vulnerability detection. As containerization is currently the most popular deployment method, providing a method to detect vulnerabilities in services on the current container platform is particularly necessary.

[0011] Existing technologies use the following methods to detect whether a service on a current container has a JAR vulnerability: Option 1: Most companies have internal Maven repositories that maintain their existing Java service versions. Dependencies can be checked based on the historical versions of each Java service.

[0012] Option 2: Utilize cybersecurity or vulnerability detection tools to set up vulnerability attack methods and check all services on the container platform.

[0013] However, the existing technology has the following drawbacks: Option 1: The Maven repository does not record all currently running versions of services, and vulnerabilities in historical versions do not affect the actual operation of services. However, if management practices or actual implementation are not standardized, online services may not be published in the Maven repository.

[0014] Option 2: Requires professional security personnel and technical support. Each vulnerability discovery requires maintenance or the addition of new attack methods, and attacks on online services may have an adverse impact on the production environment. Summary of the Invention

[0015] The technical problem to be solved by this invention is to provide a method, system, storage medium, and computer for detecting JAR vulnerabilities in container management platforms, which maintains runtime JAR dependency information of JAVA services running on container management platforms and provides a detection method to quickly locate service sets that depend on specific JAR versions.

[0016] To solve the above-mentioned technical problems, the first technical solution adopted by the present invention is as follows: A method for detecting JAR vulnerabilities for container management platforms, including Compile and package the Java service, and obtain the JAR dependency information of the current Java service; Build the image and generate a unique identifier for it; Listen for container creation events. When a container is created, specify the image version. Based on the image version, query the JAR dependency information associated with the currently running container, record the relationship between the current container ID and the image version, and maintain the current container ID in the runtime container set. Listen for container change events. Only when the image version changes, record the relationship between the container ID and the image version, cancel the relationship with the original image version, and maintain the current container ID in the runtime container set. Listen for container stop events and remove the current container ID from the runtime container collection; Locate the JAR, traverse the collection of runtime containers, check its image version for each container ID, and then check the JAR dependencies from its image.

[0017] Preferably, obtaining the JAR dependency information of the current JAVA service includes To view or wait for the Java project to finish compiling and packaging, use Maven commands to check the list of JAR files in the lib directory.

[0018] Preferably, the association between the image identifier and JAR dependency information is recorded and maintained when building the image, and can be persistently stored in a database.

[0019] Preferably, the JAR information includes name and version.

[0020] Preferably, the positioning JAR further includes Iterate through the collection of runtime containers, check the image version for each container ID, check the JAR dependencies of the image, and if the target version JAR exists, record the current container ID and image version in the return value.

[0021] Preferably, the Java service is built using one of Maven, Ant, or Gradle.

[0022] Preferably, if the container management platform can directly query the currently running container set, then there is no need to listen for container creation events, container change events, or container stop events.

[0023] To solve the above-mentioned technical problems, the second technical solution adopted by the present invention is as follows: A JAR vulnerability detection system for a container management platform includes a controller that operates according to the aforementioned JAR vulnerability detection method for a container management platform.

[0024] To solve the above-mentioned technical problems, the third technical solution adopted by the present invention is as follows: A storage medium storing a computer program that executes the above-described JAR vulnerability detection method for a container management platform.

[0025] To solve the above-mentioned technical problems, the fourth technical solution adopted by the present invention is as follows: A computer includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the aforementioned JAR vulnerability detection method for a container management platform.

[0026] The beneficial effects of this invention are as follows: This application maintains the image version, JAR dependencies, and runtime container ID information, and can query the JAR dependencies of all currently running containers in real time. This facilitates the rapid location of the container set associated with each JAR in a non-intrusive manner, providing quick and accurate location of the container set containing a specific JAR, and facilitating rapid intervention in scenarios such as security vulnerabilities. Detailed Implementation

[0027] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments. Example 1

[0028] A method for detecting JAR vulnerabilities for container management platforms, including Image Building: The Java service image building process includes two steps: compiling and packaging the Java service, and building the image. During the compilation and packaging of the Java service, there are several methods to obtain the JAR dependency information of the current Java service. These include using the Maven command (mvndependency) to view it, or waiting for the Java project to finish compiling and then checking the JAR list in the lib directory. The image building step generates a unique identifier for this image. This step records and maintains the association between the image identifier and the JAR dependency information, which can be persistently stored in a database. JAR information includes name, version, etc.

[0029] Listen for container creation events: When a container is created, an image version must be specified. This allows you to query the JAR dependencies associated with the currently running container based on the image version. Record the relationship between the current container ID and the image version, and maintain the current container ID in the [runtime container set].

[0030] Listen for container change events: Only when the image version changes, such as in rollback or upgrade scenarios, record the relationship between the container ID and the image version, cancel the relationship with the original image version, and maintain the current container ID in the [runtime container collection].

[0031] Event Container Stop Event: Removes the current container ID from the [runtime container collection].

[0032] Locate JAR: Iterate through the [runtime container collection], check the image version for each container ID, check the JAR dependencies from the image, and if the input value is matched, record the current container ID and image version in the return value. Example 2

[0033] A method for detecting JAR vulnerabilities for container management platforms, which can directly query the current [runtime container collection]; Image Building: The Java service image building process includes two steps: compiling and packaging the Java service, and building the image. During the compilation and packaging of the Java service, there are several methods to obtain the JAR dependency information of the current Java service. These include using the Maven command (mvndependency) to view it, or waiting for the Java project to finish compiling and then checking the JAR list in the lib directory. The image building step generates a unique identifier for this image. This step records and maintains the association between the image identifier and the JAR dependency information, which can be persistently stored in a database. JAR information includes name, version, etc.

[0034] Locate the JAR, iterate through the [runtime container collection], for each container ID, check its image version, check the JAR dependencies from its image, if it matches the input value, record the current container ID and image version in the return value. Example 3

[0035] A JAR vulnerability detection system for a container management platform is characterized by including a controller that executes the JAR vulnerability detection method for a container management platform according to either Embodiment 1 or Embodiment 2. Example 4

[0036] A storage medium storing a computer program that executes the JAR vulnerability detection method for a container management platform as described in either Embodiment 1 or Embodiment 2. Example 5

[0037] A computer includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the JAR vulnerability detection method for a container management platform as described in either Embodiment 1 or Embodiment 2.

[0038] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for detecting JAR vulnerabilities in a container management platform, characterized in that, This includes compiling and packaging Java services, and obtaining the JAR dependency information of the current Java service; Build the image and generate a unique identifier for it; Listen for container creation events. When a container is created, specify the image version. Based on the image version, query the JAR dependency information associated with the currently running container, record the relationship between the current container ID and the image version, and maintain the current container ID in the runtime container set. Listen for container change events. Only when the image version changes, record the relationship between the container ID and the image version, cancel the relationship with the original image version, and maintain the current container ID in the runtime container set. Listen for container stop events and remove the current container ID from the runtime container collection; Locate the JAR, traverse the collection of runtime containers, check its image version for each container ID, and check the JAR dependencies from its image; Among them, the association between the image identifier and JAR dependency information is recorded and maintained when building the image, and can be persistently stored in the database.

2. The JAR vulnerability detection method for container management platforms according to claim 1, characterized in that, To obtain the JAR dependency information of the current JAVA service, you can use Maven commands or wait for the JAVA project to finish compiling and then view the JAR list in the lib directory.

3. The JAR vulnerability detection method for container management platforms according to claim 1, characterized in that, The JAR dependency information includes name and version.

4. The JAR vulnerability detection method for container management platforms according to claim 1, characterized in that, Locating a JAR further involves traversing the set of runtime containers, checking the image version for each container ID, checking the JAR dependencies from the image, and recording the current container ID and image version in the return value if the target version of the JAR exists.

5. The JAR vulnerability detection method for container management platforms according to claim 1, characterized in that, The Java service is built using one of Maven, Ant, or Gradle.

6. The JAR vulnerability detection method for container management platforms according to claim 1, characterized in that, If the container management platform can directly query the currently running container collection, then there is no need to listen for container creation events, container change events, or container stop events.

7. A JAR vulnerability detection system for container management platforms, characterized in that, The controller includes the operation of the JAR vulnerability detection method for container management platforms according to any one of claims 1-6.

8. A storage medium, characterized in that, The storage medium stores a computer program that executes the JAR vulnerability detection method for a container management platform as described in any one of claims 1-6.

9. A computer, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the JAR vulnerability detection method for container management platforms as described in any one of claims 1-6.