Distributed vulnerability mining method and device based on Kubernetes deployment

Abstract

The embodiment of the application provides a distributed vulnerability mining method and device based on Kubernetes deployment and electronic equipment, and belongs to the technical field of vulnerability mining, which comprises the following steps: preparing a kubernetes environment; constructing a container image by using a multi-level construction mode; constructing a fuzz tester according to target program characteristics, a seed file set, a test engine type and a mutation strategy configuration; setting an independent namespace for each target program, and each tester is an independent deployment; collecting statistical data in the process of the fuzz testing; verifying a crash sample after the crash occurs; when verifying, starting a verification container of the same fuzz tester, the image being the same, and the starting command being changed into a verification parameter format, so as to avoid that the verification container occupies resources for a long time. By using the scheme, a containerized, distributed and dynamically scheduled vulnerability mining system based on a strategy can be realized on the basis of kubernetes.

Description

Technical Field

[0001] This invention relates to the field of vulnerability discovery technology, and in particular to a distributed vulnerability discovery method, apparatus, and electronic device based on Kubernetes deployment. Background Technology

[0002] Fuzzing has been proven to be an effective vulnerability discovery method. With the rapid development of cloud computing, more and more computing power is being used to deploy fuzzing systems, such as Google's Clusterfuzz and Microsoft's OneFuzz, enabling more vulnerabilities to be discovered in a timely manner.

[0003] While Google and Microsoft's cloud fuzzing systems rely on their respective cloud computing platforms and possess powerful computing capabilities, excellent open interfaces, and continuously improving mutation algorithms, they are not suitable for all scenarios. For example, they may need to be deployed in other public or private cloud environments, or for short-term, rapid deployment on a single server.

[0004] Some designs do not rely on specific cloud platforms and are deployed using only servers / virtual machines. However, this approach is essentially a migration of traditional physical machine-based deployment methods to the cloud platform, without fully utilizing the cloud platform's capabilities for automation and orchestration. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a distributed vulnerability mining method, apparatus and electronic device based on Kubernetes deployment, which at least partially solves the problems existing in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a distributed vulnerability mining method based on Kubernetes deployment, comprising:

[0007] Prepare the Kubernetes environment. If it is a production environment, initialize it according to the official documentation and install Calico for container networking configuration. If it is a test environment, install and configure minikube directly.

[0008] The container image is built using a multi-level build approach, including: the first level builds the base OS image; the second level builds the necessary toolkit image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each subsequent level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle, while the fourth level image is built as needed according to the fuzzing task.

[0009] Based on the characteristics of the target program, the seed file set, the test engine type, and the mutation strategy configuration, a fuzz tester is built.

[0010] Each target program is assigned a separate namespace, and each tester is deployed independently. The initial number of replicas is 1, and the resources allocated to the pod are distributed evenly based on total resources and experience data.

[0011] Collect statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes; use statistical data and empirical formulas to comprehensively score the performance of the fuzzers, then conduct horizontal comparisons based on the scores and adjust the vertical resources of the corresponding pods; increase the number of replicas for fuzzers with outstanding performance.

[0012] When a crash occurs, the crash sample is verified. During verification, a verification container with the same fuzzer is started, with identical images. The startup command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

[0013] According to a specific implementation of an embodiment of this disclosure, the construction of the container image using a multi-level build method includes:

[0014] The base OS image is created by the official team, downloaded from Docker Hub, and referenced in the Dockerfile;

[0015] Install necessary toolkit images on top of the base OS image, including essential compilation tools, code management tools, and download tools; install via the operating system's application repository or using pip or npm package management tools; and clear the package cache after installation to free up space.

[0016] Fuzzing engine image: Based on the necessary toolkit image, deploy different types of fuzzing engines;

[0017] The target program fuzzer image is used to deploy libpng's fuzzer on top of the fuzzing engine image.

[0018] According to a specific implementation of an embodiment of this disclosure, the subsequent level is built upon the previous level, including:

[0019] Once the Docker image built in the previous stage is complete, it is uploaded to a private Docker repository. The build files of the subsequent stage image can then directly reference the Docker image from the previous stage.

[0020] According to a specific implementation of an embodiment of this disclosure, the fourth-level image is constructed on demand based on the fuzzing task, including:

[0021] The target program tester image is specifically designed with a Dockerfile and build.sh script based on the fuzzing target, and it is updated iteratively with the target and rebuilt in a timely manner.

[0022] According to the resource recycling strategy, unused tester images should be destroyed in a timely manner. If the tester image is needed again in the future, the Dockerfile and build.sh of the tester image should be kept and the tester image should be rebuilt when needed.

[0023] According to a specific implementation of this disclosure, the step of constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration includes:

[0024] For command-line programs, which are considered to be a combination of input parameters, fuzz tests are performed by writing encode-fuzzer and decode-fuzzer respectively for the encoding and decoding of video files.

[0025] According to a specific implementation of this disclosure, the step of configuring and constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration further includes:

[0026] The seed file set refers to the initial input data file given at the start of fuzzing. Different fuzzers use different seed file sets. The seed file set is initially collected from the Internet, and then the test engine also supplements the seed file during the fuzzing process.

[0027] According to a specific implementation of this disclosure, the step of configuring and constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration further includes:

[0028] The type of test engine can be selected based on experience or by filtering based on its performance during the fuzzing process;

[0029] Mutation strategy configuration refers to setting the types and weights of mutation methods used by a fuzz testing engine, which typically includes many types of mutation methods.

[0030] Secondly, embodiments of the present invention provide a distributed vulnerability mining device based on Kubernetes deployment, comprising:

[0031] The preparation module is used to prepare the Kubernetes environment. For production environments, initialize according to the official documentation and install Calico for container network configuration. For experimental environments, directly use minikube for installation and configuration.

[0032] The build module is used to build container images using a multi-level build approach, including: the first level builds the base OS image; the second level builds the necessary toolkit image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each subsequent level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle, while the fourth level image is built on demand according to the fuzzing task.

[0033] The configuration module is used to configure and build a fuzz tester based on the characteristics of the target program, the seed file set, the test engine type, and the mutation strategy.

[0034] The deployment module is used to set up an independent namespace for each target program, while each tester is deployed independently. The initial number of replicas is 1, and the resources allocated to the pod are distributed evenly based on the total resources and experience data.

[0035] The collection module is used to collect statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes. It then uses statistical data and empirical formulas to comprehensively score the performance of the fuzzers, performs horizontal comparisons based on the scores, and adjusts the vertical resources of the corresponding pods accordingly. For fuzzers with outstanding performance, the number of replicas is increased.

[0036] The verification module is used to verify the crash sample after a crash occurs. During verification, a verification container with the same fuzzer is started. The image is identical, and the start command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

[0037] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0038] At least one processor; and,

[0039] The memory is communicatively connected to the at least one processor; wherein,

[0040] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the distributed vulnerability mining method based on Kubernetes deployment in any of the first aspects or any implementations thereof.

[0041] Fourthly, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the distributed vulnerability mining method based on Kubernetes deployment in the first aspect or any implementation thereof.

[0042] Fifthly, embodiments of the present invention also provide a computer program product, the computer program product including a computing program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to execute the distributed vulnerability mining method based on Kubernetes deployment in the first aspect or any implementation thereof.

[0043] The distributed vulnerability mining scheme based on Kubernetes deployment in this embodiment of the invention includes: preparing a Kubernetes environment; for a production environment, initialization is performed according to the official documentation, and Calico is installed for container network configuration; for an experimental environment, minikube is directly used for installation and configuration; a multi-level build method is used to build container images, including: the first level builds a base OS image; the second level builds necessary toolkit images; the third level builds a fuzzing engine image; and the fourth level builds a target program fuzzer image. Each subsequent level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle, while the fourth level image is built on demand according to the fuzzing task; and the variable... A heterogeneous policy configuration is used to build fuzzers. An independent namespace is set up for each target program, and each fuzzer is deployed independently, with an initial replica count of 1. Resources allocated to each pod are evenly distributed based on total resources and empirical data. Statistical data is collected during fuzzing, including runtime, speed, path coverage, and number of crashes. The effectiveness of the fuzzers is comprehensively scored using statistical data and empirical formulas, and then horizontal comparisons are made based on the scores, with vertical resource adjustments made to the corresponding pods. For fuzzers with outstanding performance, the number of replicas is increased. When a crash occurs, the crash sample is verified. During verification, a verification container of the same fuzzer is started, with the same image, and the startup command is changed to the verification parameter format to avoid the verification container consuming resources for a long time. This solution fully utilizes the automation and orchestration capabilities of cloud computing platforms, using Kubernetes as the infrastructure to realize a containerized, distributed, policy-based dynamic scheduling vulnerability discovery system. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1A schematic diagram of a distributed vulnerability mining method based on Kubernetes deployment provided in an embodiment of the present invention;

[0046] Figure 2 A schematic diagram of another distributed vulnerability mining method based on Kubernetes deployment provided in an embodiment of the present invention;

[0047] Figure 3 A schematic diagram of another distributed vulnerability mining method based on Kubernetes deployment provided in an embodiment of the present invention;

[0048] Figure 4 A schematic diagram of another distributed vulnerability mining method based on Kubernetes deployment provided in an embodiment of the present invention;

[0049] Figure 5 A schematic diagram of the structure of a distributed vulnerability mining device based on Kubernetes deployment provided in an embodiment of the present invention;

[0050] Figure 6 A schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0051] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0052] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0053] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0054] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0055] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0056] This disclosure provides a distributed vulnerability discovery method based on Kubernetes deployment. The distributed vulnerability discovery method based on Kubernetes deployment provided in this embodiment can be executed by a computing device, which can be implemented as software or a combination of software and hardware, and can be integrated into servers, terminal devices, etc.

[0057] See Figure 1 , Figure 2 , Figure 3 and Figure 4 This disclosure provides a distributed vulnerability mining method based on Kubernetes deployment, including:

[0058] S101. Prepare the Kubernetes environment. If it is a production environment, initialize it according to the official documentation and install Calico for container network configuration. If it is a test environment, install and configure minikube directly.

[0059] S102 uses a multi-level build method to build container images, including: the first level builds the base OS image; the second level builds the necessary tool package image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle. The fourth level image is built as needed according to the fuzzing task.

[0060] S103, builds a fuzz tester based on the characteristics of the target program, seed file set, test engine type, and mutation strategy configuration;

[0061] S104 sets up an independent namespace for each target program, while each tester is deployed independently. The initial number of replicas is 1, and the resources allocated to the starting pod are distributed evenly based on total resources and experience data.

[0062] S105 collects statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes; uses statistical data and empirical formulas to comprehensively score the performance of the fuzzer, then makes horizontal comparisons based on the scores and adjusts the vertical resources of the corresponding pods; for fuzzers with outstanding performance, the number of replicas is increased.

[0063] S106. After a crash occurs, the crash sample is verified. During verification, a verification container with the same fuzzer is started. The image is identical, and the start command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

[0064] Specifically, container images are built in multiple levels: (I) base OS image; (II) necessary toolkit image; (III) fuzzing engine image; (IV) target program fuzzer image. Each subsequent level is built upon the previous one. The first three levels of images are universal and have a relatively long update cycle. The fourth level image is built on demand based on the fuzzing task.

[0065] The main steps in building (I) the base OS image; (II) the necessary toolkit image; (III) the fuzzing engine image; and (IV) the target program fuzzer image include:

[0066] (1) The base OS image is usually created by the official website and can be downloaded from Docker Hub. It only needs to be referenced in the Dockerfile. For example:

[0067]

[0068] (2) Necessary toolkit images mainly consist of installing essential compilation tools, code management tools, download tools, etc., on top of the base OS image. These are typically installed through the operating system's application repository or using package management tools such as pip or npm. After installation, the package cache is cleared to free up space. For example:

[0069]

[0070] The image name is simply named base.

[0071] (3) Fuzzing engine images are based on necessary toolkit images, deploying different types of fuzzing engines. For example, deploying AFL:

[0072]

[0073] The image name is simply base-afl

[0074] (4) For the target program fuzzer image, deploy the fuzzer based on the fuzzing engine image. For example, deploy the libpng fuzzer:

[0075]

[0076] build.sh is the script for building the fuzzer; the image is simply named afl-libpng.

[0077] The main steps for building a subsequent Docker image on top of the previous one include: as mentioned above, after the Docker image built by the previous one is completed, it is uploaded to a private Docker repository and can be directly referenced in the build file (Dockerfile) of the subsequent image.

[0078] The fourth-level image is built on demand based on the fuzzing task, and the steps include...

[0079] (1) As mentioned above, the first three levels of images do not involve the target of fuzzing, so they do not need to be updated frequently after being built. Only when major versions are upgraded, such as when Ubuntu releases 22.04 or LLVM releases 14.0, will new Docker images be added accordingly.

[0080] (2) The difference is that the target program tester image needs to be specially written with Dockerfile and build.sh according to the fuzzing target, and needs to be repeatedly built in a timely manner as the target is updated iteratively.

[0081] (3) The tester image may take up a lot of space. To reduce resource waste, unused images can be destroyed in a timely manner according to the resource recycling strategy. If it is needed again later, just keep the Dockerfile and build.sh and rebuild it.

[0082] The fuzz tester is built based on the characteristics of the target program, the seed file set, the test engine type, the mutation strategy configuration, and other conditions, including the following steps.

[0083] (1) Target program characteristics, mainly referring to program function points. For command-line programs, it can be considered as a combination of a set of input parameters, such as the encoding and decoding of video files. Encode-fuzzer and decode-fuzzer can be written separately for fuzz testing.

[0084] (2) The seed file set refers to the initial input data files given at the start of fuzzing. These files should not directly cause a crash and should cover as many code paths as possible. Different seed file sets should be used for different fuzzers. The seed file set can initially be collected from the network, and the test engine also has the function of supplementing seed files during the fuzzing process.

[0085] (3) The type of test engine can be selected based on experience or by filtering based on its performance during the fuzzing process. For example, honggfuzz supports netdriver mode, which is more suitable for fuzzing httpd, but there is also a fuzzing engine t-reqs specifically for the HTTP protocol that can be used.

[0086] (4) Mutation strategy configuration refers to the various mutation methods typically included in a fuzzing engine, such as 1 / 2 / 4 / 8-byte random mutations, random mutations within the ASCII character range, etc. The type and weight of each mutation method can be set.

[0087] (5) The above are just some general factors that need to be considered when building a fuzz tester, and are not limiting conditions. Modification or supplementation is allowed according to the actual situation.

[0088] The solutions described in the above embodiments enable hierarchical construction of tester images, making them easier to update, maintain, and reuse. At the same time, the resources consumed by the tester containers are dynamically adjusted based on statistical data, comprehensive scoring, and adjustment strategies, and crash verification containers are started on demand, improving resource utilization.

[0089] The resources consumed by the tester containers are dynamically adjusted based on a comprehensive statistical score and a dynamic adjustment strategy. For example, the currently running tester containers fuzz-c1, fuzz-c2, and fuzz-c3 are initially allocated 4 CPUs and 16GB of memory. The comprehensive statistical score essentially uses an empirical formula to convert sampled data such as runtime, speed, path coverage, and number of crashes into integers between 1 and 100. A higher score indicates better performance, and vice versa. The dynamic adjustment strategy is a set of rules for updating resource configurations, such as: (i) running for at least 12 hours, (ii) dynamically adjusting every hour, and (iii) increasing resources by 25% for scores greater than 80 and decreasing resources by 25% for scores less than 50. Assuming all three testers have run for 12 hours, fuzz-c1 scored 91 points, fuzz-c2 scored 67 points, and fuzz-c3 scored 45 points, then after adjustments, fuzz-c1 should be allocated 5 CPUs and 20GB of memory, fuzz-c2 should remain unchanged, and fuzz-c3 should be allocated 3 CPUs and 12GB of memory.

[0090] See Figure 2 According to a specific implementation of this disclosure, the construction of the container image using a multi-level build method includes:

[0091] S201, the base OS image is created by the official team, downloaded from Docker Hub, and referenced in Dockerfile;

[0092] S202, the essential toolkit image, installs necessary compilation tools, code management tools, and download tools on top of the base OS image; it installs through the operating system's application repository or using pip or npm package management tools; and clears the package cache after installation to free up space;

[0093] S203, a fuzz testing engine image, deploys different types of fuzz engines based on the necessary toolkit image;

[0094] S204 is the target program fuzzer image, which deploys libpng's fuzzer on top of the fuzzing engine image.

[0095] According to a specific implementation of an embodiment of this disclosure, the subsequent level is built upon the previous level, including:

[0096] Once the Docker image built in the previous stage is complete, it is uploaded to a private Docker repository. The build files of the subsequent stage image can then directly reference the Docker image from the previous stage.

[0097] See Figure 3According to a specific implementation of this disclosure, the fourth-level image is constructed on demand based on the fuzzing task, including:

[0098] S301, the target program tester image, is specifically designed with a Dockerfile and build.sh based on the fuzzing target, and is updated iteratively with the target and rebuilt in a timely manner;

[0099] S302. According to the resource recycling strategy, unused tester images are destroyed in a timely manner. If the tester image is needed again in the future, the Dockerfile and build.sh of the tester image are kept and the tester image is rebuilt when needed.

[0100] According to a specific implementation of this disclosure, the step of constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration includes:

[0101] For command-line programs, which are considered to be a combination of input parameters, fuzz tests are performed by writing encode-fuzzer and decode-fuzzer respectively for the encoding and decoding of video files.

[0102] According to a specific implementation of this disclosure, the step of configuring and constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration further includes:

[0103] The seed file set refers to the initial input data file given at the start of fuzzing. Different fuzzers use different seed file sets. The seed file set is initially collected from the Internet, and then the test engine also supplements the seed file during the fuzzing process.

[0104] See Figure 4 According to a specific implementation of this disclosure, the step of constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration further includes:

[0105] S401, test engine type, select based on experience, or filter based on performance during the fuzzing process;

[0106] S402, Mutation Strategy Configuration, refers to the setting of the types and weights of mutation methods used by a fuzz testing engine, which typically includes many types of mutation methods.

[0107] See Figure 5 This invention also discloses a distributed vulnerability mining device 50 based on Kubernetes deployment, comprising:

[0108] Module 501 is used to prepare the Kubernetes environment. If it is a production environment, initialize it according to the official documentation and install Calico for container network configuration. If it is a test environment, install and configure minikube directly.

[0109] Build module 502 is used to build container images using a multi-level build method, including: the first level builds the base OS image; the second level builds the necessary tool package image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle. The fourth level image is built on demand according to the fuzzing task.

[0110] Module 503 is configured to build a fuzz tester based on the characteristics of the target program, the seed file set, the test engine type, and the mutation strategy.

[0111] Deployment module 504 is used to set up an independent namespace for each target program, while each tester is deployed independently with an initial replica count of 1. The resources allocated to the pod at startup are distributed evenly based on total resources and experience data.

[0112] The collection module 505 is used to collect statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes. It then uses statistical data and empirical formulas to comprehensively score the performance of the fuzzers, performs horizontal comparisons based on the scores, and adjusts the vertical resources of the corresponding pods accordingly. For fuzzers with outstanding performance, the number of replicas is increased.

[0113] The verification module 506 is used to verify the crash sample after a crash occurs. During verification, the verification container of the same fuzzer is started. The image is the same, and the start command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

[0114] See Figure 6 This invention also provides an electronic device 60, which includes:

[0115] At least one processor; and,

[0116] The memory is communicatively connected to the at least one processor; wherein,

[0117] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the distributed vulnerability mining method based on Kubernetes deployed in the foregoing method embodiments.

[0118] This invention also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to perform the aforementioned method embodiments.

[0119] This invention also provides a computer program product, which includes a computing program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the distributed vulnerability mining method based on Kubernetes deployment in the foregoing method embodiments.

[0120] Figure 6 The device shown can perform Figure 1-4 For the methods shown in the embodiments, the parts not described in detail in this embodiment can be referred to the following: Figure 1-4 The relevant descriptions of the illustrated embodiments are not repeated here.

[0121] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device 60 suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0122] like Figure 6 As shown, electronic device 60 may include a processing unit (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of electronic device 60. The processing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0123] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 60 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 60 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0124] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0125] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0126] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0127] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: acquire at least two Internet Protocol (IP) addresses; send a node evaluation request including the at least two IP addresses to a node evaluation device, wherein the node evaluation device selects an IP address from the at least two IP addresses and returns it; and receive the IP address returned by the node evaluation device; wherein the acquired IP address indicates an edge node in a content delivery network.

[0128] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: receive a node evaluation request including at least two Internet Protocol (IP) addresses; select an IP address from the at least two IP addresses; and return the selected IP address; wherein the received IP address indicates an edge node in the content delivery network.

[0129] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0131] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0132] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof.

[0133] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A distributed vulnerability mining method based on Kubernetes deployment, characterized in that, include: Prepare the Kubernetes environment. If it is a production environment, initialize it according to the official documentation and install Calico for container network configuration. If it is a test environment, install and configure minikube directly. The container image is built using a multi-level build approach, including: the first level builds the base OS image; the second level builds the necessary toolkit image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each subsequent level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle, while the fourth level image is built as needed according to the fuzzing task. Based on the characteristics of the target program, the seed file set, the test engine type, and the mutation strategy configuration, a fuzz tester is built. Each target program is assigned a separate namespace, and each tester is deployed independently. The initial number of replicas is 1, and the resources allocated to the pod are distributed evenly based on total resources and experience data. Collect statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes; use statistical data and empirical formulas to comprehensively score the performance of the fuzzers, then conduct horizontal comparisons based on the scores and adjust the vertical resources of the corresponding pods; increase the number of replicas for fuzzers with outstanding performance. When a crash occurs, the crash sample is verified. During verification, a verification container with the same fuzzer is started, with identical images. The startup command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

2. The method according to claim 1, characterized in that, The method of building container images using a multi-level build approach includes: The base OS image is created by the official website, downloaded from Docker Hub, and referenced in the Dockerfile; Install necessary toolkit images on top of the base OS image, including essential compilation tools, code management tools, and download tools; install via the operating system's application repository or using pip or npm package management tools; and clear the package cache after installation to free up space. Fuzzing engine image: Based on the necessary toolkit image, deploy different types of fuzzing engines; The target program fuzzer image is used to deploy libpng's fuzzer on top of the fuzzing engine image.

3. The method according to claim 2, characterized in that, The subsequent level is built upon the previous level and includes: Once the Docker image built in the previous stage is complete, it is uploaded to a private Docker repository. The build files of the subsequent stage image can then directly reference the Docker image from the previous stage.

4. The method according to claim 3, characterized in that, The fourth-level image, built on demand according to the fuzzing task, includes: The target program tester image is specifically designed with a Dockerfile and build.sh script based on the fuzzing target, and it is updated iteratively along with the target and rebuilt in a timely manner. According to the resource recycling strategy, unused tester images should be destroyed in a timely manner. If the tester image is needed again in the future, the Dockerfile and build.sh of the tester image should be kept and the tester image should be rebuilt when needed.

5. The method according to claim 4, characterized in that, The process of constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy configuration includes: For command-line programs, which are considered to be a combination of input parameters, fuzz tests are performed by writing encode-fuzzer and decode-fuzzer respectively for the encoding and decoding of video files.

6. The method according to claim 5, characterized in that, The process of configuring and constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy also includes: The seed file set refers to the initial input data file given at the start of fuzzing. Different fuzzers use different seed file sets. The seed file set is initially collected from the Internet, and then the test engine also supplements the seed file during the fuzzing process.

7. The method according to claim 6, characterized in that, The process of configuring and constructing a fuzz tester based on target program characteristics, seed file set, test engine type, and mutation strategy also includes: The type of test engine can be selected based on experience or by filtering based on its performance during the fuzzing process; Mutation strategy configuration refers to setting the types and weights of mutation methods used by a fuzz testing engine, which typically includes many types of mutation methods.

8. A distributed vulnerability discovery device based on Kubernetes, characterized in that, include: The preparation module is used to prepare the Kubernetes environment. For production environments, initialize according to the official documentation and install Calico for container network configuration. For experimental environments, directly use minikube for installation and configuration. The build module is used to build container images using a multi-level build approach, including: the first level builds the base OS image; the second level builds the necessary toolkit image; the third level builds the fuzzing engine image; and the fourth level builds the target program fuzzer image. Each subsequent level is built on the basis of the previous level. The first three levels of images are universal and have a long update cycle, while the fourth level image is built on demand according to the fuzzing task. The configuration module is used to configure and build a fuzz tester based on the characteristics of the target program, the seed file set, the test engine type, and the mutation strategy. The deployment module is used to set up an independent namespace for each target program, while each tester is deployed independently. The initial number of replicas is 1, and the resources allocated to the pod are distributed evenly based on the total resources and experience data. The collection module is used to collect statistical data during the fuzzing process, including runtime, speed, path coverage, and number of crashes. It then uses statistical data and empirical formulas to comprehensively score the performance of the fuzzers, performs horizontal comparisons based on the scores, and adjusts the vertical resources of the corresponding pods accordingly. For fuzzers with outstanding performance, the number of replicas is increased. The verification module is used to verify the crash sample after a crash occurs. During verification, a verification container with the same fuzzer is started. The image is identical, and the start command is changed to the verification parameter format to avoid the verification container running for a long time and consuming resources.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the distributed vulnerability mining methods based on Kubernetes deployment as described in claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the distributed vulnerability mining method based on Kubernetes deployment as described in any one of claims 1-7.

Images