Software patch security execution method and system based on container isolation

Abstract

The invention relates to the field of software security, and particularly discloses a software patch security execution method and system based on container isolation. The method comprises the following steps of: receiving a target software path and a patch file path through a Go language; creating a temporary container environment, mounting a software directory in a read-only mode, and mounting a patch file in an executable mode; running a network monitoring module in a host machine, intercepting all network requests of the patch program in the container by adopting a transparent agent, and prompting a user to make a decision in real time; executing the predefined function test script in the container, and verifying the integrity of the core function through weighted calculation; and if the function test is passed and no network request is blocked, synchronizing the modified file in the container to a target directory of the host machine, otherwise, automatically destroying the container. According to the method, malicious codes are isolated through the container, network behaviors are dynamically monitored, functional integrity is automatically verified, and the problems of security risks and environmental pollution of patch application are effectively solved.

Description

Technical Field

[0001] The present invention relates to the field of software security technology, and in particular to a method and system for securely executing software patches based on container isolation. Background Art

[0002] As software systems continue to grow in complexity and deployment scale, software patch management has become a critical component in maintaining system security and functional integrity. Patches are typically used to fix security vulnerabilities, functional defects, or improve performance, but the patch application process itself can introduce new security risks and stability issues. Existing technologies present the following key technical challenges that need to be addressed:

[0003] Malicious attackers may implant backdoors, ransomware, or data-stealing code by tampering with patches; patches may initiate undeclared network connections when executed, and data leakage caused by uncontrollable network behavior needs to be addressed urgently; functional failures caused by patch compatibility defects may cause abnormalities in the core functions of the software, manifesting as resource exhaustion problems such as interruption of key business processes, data calculation logic errors, or memory leaks; failed patch installations will leave some modified files or configurations, causing the software to be in a semi-updated state and causing unforeseen errors, or leftover files will interfere with subsequent patch applications.

[0004] To address the above issues, we have designed a software patch security execution method and system based on container isolation to solve the above problems. Summary of the Invention

[0005] The purpose of the present invention is to address the shortcomings of the prior art, such as the systemic risks brought by malicious patches, data leakage caused by uncontrollable network behavior, functional failures caused by patch compatibility defects, and software in a semi-updated state due to residual parts of failed patch installation. A method and system for secure execution of software patches based on container isolation is proposed. This technical solution dynamically controls risks during the execution phase, curbs the spread of malicious code through lightweight environment isolation, blocks unauthorized communications through interactive network monitoring, ensures functional integrity through an automated verification mechanism, and eliminates modification residues through instantaneous environment destruction.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A method for securely executing software patches based on container isolation includes the following steps:

[0008] Step S1, receiving the target software installation path and patch file path;

[0009] Step S2, create a temporary container environment and mount the directory;

[0010] Step S3, running a network monitoring module to intercept requests when executing the patch program in the container;

[0011] Step S4: Run the target software in the container and execute the functional test script pre-defined by the automated verification module to verify the software functions and determine the core functions of the software;

[0012] Step S5: Determine whether to synchronize the file based on the verification result and network behavior.

[0013] Furthermore, in step S2, the Go language is used to call the container management interface to create a temporary container environment. The target software installation directory is mounted in read-only mode to the first path of the container, and the patch program is mounted as an executable file to the second path of the container. The temporary container environment is configured to prohibit persistent storage and is automatically destroyed after the container exits. The steps for creating a temporary container environment are as follows:

[0014] Step S21, using the os / exec package of the Go language to call the Docker command line tool or using the Docker SDK of the Go language to create a container;

[0015] Step S22: configuring an independent network namespace for the container;

[0016] Step S23: Start a daemon process inside the container to receive the execution command sent by the host machine.

[0017] Furthermore, in step S3, while the patch program is being executed in the container, a network monitoring module written in Go is run on the host machine. The network monitoring module intercepts all network requests of the patch program in the container by creating a transparent proxy.

[0018] When the network monitoring module detects a network request, it pauses the request and displays a dialog box to the user, prompting the user to choose to allow or block the request. The processing function of the network request is:

[0019] ;

[0020] in, Indicates the function that processes the request. Indicates that output is allowed. Indicates that the output is blocked; Represents a network request.

[0021] Furthermore, creating a transparent proxy includes the following steps:

[0022] Step S31, using the net package and gopacket library in the Go language on the host machine to monitor the original network data packet;

[0023] Step S32, redirecting the outbound traffic of the container to the port monitored by the proxy program by configuring iptables rules;

[0024] Step S33, after receiving the redirected traffic, the proxy program parses and extracts the target address, source address, port and data content;

[0025] Step S34: Display the information on the user interface. Based on the user's selection, the network request is released or intercepted by the proxy program.

[0026] Furthermore, in step S4, the target software is run in the container, and the automated verification module written in Go language executes a predefined functional test script to determine whether the core functions of the target software are running normally. The expression for verifying the software function after the patch by the automated verification module is as follows:

[0027] ;

[0028] in, Indicates the verification result. Indicates success, Indicates failure, Indicates the total number of test items, Indicates the The weight of the test items, Indicates the The results of the test items; Indicates the preset threshold.

[0029] Furthermore, the automated verification module written in Go language executes predefined functional test scripts including:

[0030] Step S41, starting the target software and executing the key operation sequence;

[0031] Step S42: Capture the output log of the target software and use the regexp package in the Go language to perform regular expression matching to check whether it contains the expected success pattern;

[0032] Step S43: Check the status of the controls on the target software interface and obtain status information through OCR or automated testing tools.

[0033] Furthermore, in step S5, whether to synchronize files is determined based on the verification results and network behavior. If the functional verification is successful and the user does not block any network requests, the files modified by the patch in the container are copied to the target software installation directory of the host machine; otherwise, all changes in the container are discarded.

[0034] Furthermore, copying the patched files in the container to the target software installation directory on the host machine includes:

[0035] Step S51: Use the Go language to traverse the target software installation directory in the container, calculate the hash value of the file and compare it with the original file to obtain a modified file list;

[0036] Step S52: Only the files in the modified file list are extracted to a temporary directory of the host machine through the container export function;

[0037] Step S53: Run the automated verification module to verify the original software application export file on the host machine, and overwrite the original file after the verification passes.

[0038] A system for securely executing software patches based on container isolation, the system comprising:

[0039] A user interface module receives a target software installation path and a patch file path specified by a user;

[0040] The container management module, implemented in Go language, is used to create and manage temporary container environments;

[0041] The network monitoring module, implemented in Go language, is used to intercept and display network requests and wait for user decisions;

[0042] The automated verification module, implemented in Go, is used to execute predefined functional test scripts to verify the functionality of the patched software.

[0043] The file synchronization module, implemented in Go language, is used to synchronize modified files in the container to the host machine.

[0044] Furthermore, the system also includes a whitelist management module for storing known safe patch characteristics, wherein the patch characteristics include:

[0045] File hash value, destination address and port of network request;

[0046] When the patch's characteristics match those in the whitelist, its network request is automatically allowed and the user confirmation step is skipped.

[0047] Compared with the existing technology, the beneficial effects of the present invention are: the present invention uses container isolation technology to limit the execution environment of the patch program, configures an independent network namespace to achieve complete isolation, monitors network requests in real time through a transparent proxy and supports user decisions, combines an automated verification mechanism to ensure functional integrity, and finally only synchronously modifies files after verification is passed. It has the advantages of effectively isolating potential malicious patches, dynamically monitoring network behavior, automatically verifying functional integrity, and eliminating modification residues. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1This is a flow chart of a software patch security execution method based on container isolation proposed by the present invention; Figure 2 This is a schematic diagram of the process of creating an isolated container in the software patch security execution method based on container isolation proposed by the present invention; Figure 3 This is a flowchart of network monitoring in a software patch security execution method based on container isolation proposed by the present invention; Figure 4 This is a flowchart of file synchronization in a software patch security execution method based on container isolation proposed by the present invention. DETAILED DESCRIPTION

[0049] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0050] Traditional antivirus solutions rely on static signature detection, which has limited protection against new or unknown malicious patches. When patches are executed directly within the main operating system environment, malicious code can gain unrestricted access to the host's file system, registry, and sensitive data, potentially causing systemic intrusion. This risk is particularly severe in mission-critical systems.

[0051] Data leakage caused by uncontrollable network behavior needs to be addressed urgently. Patches can initiate undeclared network connections during execution, potentially leaking system environment information to external servers, downloading unverified add-ons, or establishing reverse shell connections to receive remote commands. Standard firewalls only provide coarse-grained control based on ports and IP addresses, and are unable to dynamically intercept program execution and prompt users to make decisions, making potential data leakage risks difficult to effectively control.

[0052] Patches can cause core software functional anomalies, manifesting as interruptions to critical business processes, data calculation logic errors, memory leaks, and other resource depletion issues. Enterprises typically rely on manual testing to verify patch stability, which can take hours to days. Existing automated testing tools lack deep integration with the patch deployment process, preventing a closed "deploy-verify-rollback" cycle and delaying problem discovery.

[0053] Failed patch installations can leave partially modified files or configurations, leaving the software in a partially updated state and causing unforeseen errors, or leaving legacy files that interfere with subsequent patch applications. Traditional virtualization technologies require full cloning of system images, which consumes large resources and is slow to boot, making them difficult to meet the agility requirements of patch verification.

[0054] Managing these software patches presents challenges, including the spread of malicious code, data leakage risks, functional anomalies, and environmental remnants. Traditional antivirus solutions rely on static detection and are unable to address unknown malicious patches. Standard firewalls offer only coarse-grained control based on ports and IP addresses. Manual testing and verification are time-consuming, and virtualization technology consumes significant resources and is slow to start. For example, when an enterprise applied a patch, malicious code leaked sensitive data through undeclared network connections, and traditional protection methods were unable to dynamically intercept such requests.

[0055] It's necessary to build an isolated environment to prevent the spread of malicious behavior, while also establishing a dynamic monitoring mechanism to control network behavior. Analysis revealed that container technology can provide lightweight isolation, but file interaction between the container and the host needs to be addressed. Transparent proxies can capture network traffic, but this requires integration with user decision-making mechanisms. Automated testing requires deep integration with container deployment to achieve rapid verification. Based on this, a technical approach was developed that combines container isolation, network monitoring, and automated verification.

[0056] Therefore, this embodiment proposes a software patch security execution method based on container isolation, referring to Figure 1 , the method is implemented in the following manner.

[0057] Step S1, receiving the target software installation path and patch file path;

[0058] Step S2: Create a temporary container environment (isolated container) and mount the directory;

[0059] Step S3, running a network monitoring module to intercept requests when executing the patch program in the container;

[0060] Step S4: Run the target software in the container and execute the functional test script pre-defined by the automated verification module to verify the software functions and determine the core functions of the software;

[0061] Step S5: Determine whether to synchronize the file based on the verification result and network behavior.

[0062] A temporary container environment refers to an instantaneous running environment created through the container management interface. Specifically, it can be implemented using the Docker SDK. The temporary container environment is automatically destroyed after the container exits, and is used to isolate the direct impact of the patch program on the host machine. The network monitoring module refers to a module component that captures network traffic through a transparent proxy. Specifically, the gopacket library can be used to parse data packets, and traffic redirection can be achieved by configuring iptables rules to dynamically control the network behavior of the patch program. The automated verification module refers to a module component that executes pre-defined functional test scripts. Specifically, regular expressions can be used to match log information to quickly verify the functional integrity of the software after the patch. The file synchronization mechanism refers to the process of selectively copying modified files after verification. Specifically, the changed files can be identified through hash value comparison to ensure that only valid modifications are synchronized.

[0063] like Figure 2 As shown, in step S2, the Go language is used to call the container management interface (Docker interface). After the user specifies the target software installation path and the patch file path, the system creates a temporary container environment and sets the mount configuration. The target software directory is mounted read-only to the first path of the container, and the patch is mounted as an executable file to the second path of the container. The temporary container environment is configured to prohibit persistent storage and automatically destroy after the container exits.

[0064] The specific steps to create a temporary container environment include:

[0065] Step S21: The host machine calls the Docker interface and uses the Go language os / exec package to call the Docker command line tool or uses the Go language Docker SDK to create a temporary container environment (isolated container).

[0066] Step S22: Configure an independent network namespace for the container (mount configuration);

[0067] In step S23, a lightweight daemon process is started inside the container to receive the execution command (network policy) sent by the host.

[0068] Among them, the Go language's os / exec package calls the Docker command-line tool, which means operating the container by executing system commands. Specifically, this can be achieved by using the exec.Command function to construct the Docker run instruction. This method is compatible with different versions of container runtime environments. The Go language's Docker SDK refers to directly calling the programming interface provided by the container engine. Specifically, it can be achieved by initializing the client object and calling the ContainerCreate method. This method can accurately control the container configuration parameters. The network strategy adopted is: an independent network namespace refers to allocating an independent network protocol stack to the container. Specifically, it can be achieved by setting the Docker --network parameter to none mode. This feature prevents the container from directly accessing the external network. A lightweight daemon process refers to a resident service program running inside the container. Specifically, a binary file compiled by the Go language can be used to listen to the Unix domain socket. This process is responsible for parsing and executing the patch installation instructions sent by the host.

[0069] Upon receiving a patch execution request from the user, the container management module invokes the Docker command-line tool or SDK interface based on the host environment. For example, in a development and testing environment, an isolated environment can be created by executing the "docker run -v / host / path: / container / path:ro" command using the exec package. In a production environment, a connection is established using the Docker SDK's NewClientWithOpts method, followed by a call to the ContainerCreate interface to configure the read-only mount parameter. When the container starts, an isolated network space is created by setting NetworkMode to "none" to block unauthorized network communication. The daemon running inside the container listens for control commands via file descriptors. For example, upon receiving a patch execution command from the host, it triggers the patch program to run in the isolated environment.

[0070] Traditional virtualization technologies require full cloning of operating system images. For example, VMware typically allocates fixed disk space and loads a complete kernel to create a virtual machine, resulting in excessive resource usage and startup times exceeding 60 seconds. This solution, however, uses container technology to achieve process-level isolation. For example, Docker container startup time can be reduced to less than 2 seconds, and memory usage is only 5%-10% of the host machine. Existing container networks typically use a bridge mode, which creates a potential network attack surface. The independent network namespace completely cuts off the container's connection to the external network.

[0071] like Figure 3As shown, in step S3, while the patch program is executing within the container, a network monitoring module written in Go is simultaneously running on the host machine. This module creates a transparent proxy to intercept all network requests from the patch program within the container. The host machine's network monitoring module intercepts all outbound requests in real time and prompts the user to make a decision. For example, if the patch attempts to connect to an unknown server, the network monitoring module detects the network request, pauses the request, and displays a dialog box to the user, prompting the user to choose whether to allow or block the request.

[0072] The processing function for network requests is:

[0073] ;

[0074] in, Indicates the function that processes the request. Indicates that output is allowed. Indicates that the output is blocked; Represents a network request; the trust list is pre-configured by the user.

[0075] At the same time, the automated verification module runs test scripts within the container, using weighted calculations to determine whether core functionality meets standards. If functional verification succeeds and no network requests are blocked, the system synchronizes modified files within the container to the host machine; otherwise, the container environment is automatically destroyed.

[0076] Traditional patch testing in a fully virtualized environment requires several minutes to start up, but this approach leverages container technology to prepare the environment in seconds. Existing firewalls can only filter traffic based on preset rules, while this approach enables dynamic control through transparent proxy interaction with users. Conventional testing tools operate independently of the deployment process, while this approach deeply integrates automated verification into the container execution process.

[0077] The specific method to create a transparent proxy is:

[0078] Step S31, using the net package and gopacket library in the Go language on the host machine to monitor the original network data packet;

[0079] Step S32, redirecting the outbound traffic of the container to the port monitored by the proxy program by configuring iptables rules;

[0080] Step S33, after receiving the redirected traffic, the proxy program parses and extracts the target address, source address, port and data content;

[0081] Step S34: display the above information on the user interaction interface; based on the user's selection, the network request is released or intercepted by the proxy program.

[0082] Monitoring raw network packets refers to capturing unprocessed network communication data through the underlying network interfaces provided by the operating system. Specifically, this can be accomplished by using the Go language's "net" package to establish raw sockets and using the "gopacket" library for protocol parsing, thereby enabling full monitoring of the network behavior of the patch within the container. Configuring iptables rules refers to modifying network traffic routing policies using the Linux kernel's packet filtering system. Specifically, by executing the iptables command, you can add a NAT table rule to forward the egress traffic of a specified container to the local port monitored by the proxy program, ensuring that all outbound requests are subject to proxy review. Parsing and extracting the destination address refers to separating the communication quintuple and payload from the IP header and transport layer header of a network packet. Specifically, this can be accomplished by using the gopacket library's layer parsing functionality to peel off Ethernet frames, IP packets, and TCP / UDP segments layer by layer, extracting key fields for subsequent decision-making. The user interface refers to a graphical or command-line request approval terminal. Specifically, a Go language GUI library or web framework can be used to create a real-time request list display interface, with each request accompanied by the destination address, port, and data summary, awaiting user confirmation.

[0083] When the patch program in the container attempts to establish a network connection, the outbound data packets are first received by the host network card. Through the pre-configured iptables rules, these packets are redirected to the local port that the agent program listens on. After the agent program uses the raw socket to capture the data packets, it uses the protocol parsing library to peel off the packet header layer by layer, extracting the target IP, port, protocol type and the first 128 bytes of the payload as summary information, and determines whether it matches the whitelist of trusted patch feature data loaded during the system initialization phase. If it matches, it is automatically released directly; if it does not match, this information is pushed to the user interface in real time, displaying the detailed parameters of the request in a readable form. Users can decide whether to release or block based on whether the target address belongs to the preset trust list. The agent program forwards or discards traffic by rewriting the target address of the data packet according to the instructions.

[0084] Traditional firewall solutions can only filter ports or IP addresses based on static rules and are unable to dynamically capture and review specific network requests during program execution. However, this solution, through a transparent proxy and interactive approval mechanism, not only identifies undeclared addresses that patches attempt to connect to, but also captures potential data outflows, such as sending encrypted packets to unregistered servers.

[0085] In step S4, the target software is run in the container, and the automated verification module written in Go language executes the predefined functional test script to verify the software function and determine whether the core function of the target software is running normally. The expression for the automated verification module to verify the software function after the patch is as follows:

[0086] ;

[0087] in, Indicates the verification result. Indicates success, Indicates failure, Indicates the total number of test items, Indicates the The weight of the test items, Indicates the The result of each test item (1 means pass, 0 means fail); Indicates the preset threshold.

[0088] The functional test scripts that start the automated verification module include:

[0089] Step S41, starting the target software and executing the key operation sequence;

[0090] Step S42: Capture the output log of the target software and use the regexp package in the Go language to perform regular expression matching to check whether it contains the expected success pattern;

[0091] Step S43: Check the status of a specific control on the target software interface and obtain status information through OCR or automated testing tools.

[0092] Among them, the functional test script refers to a pre-written set of operational instruction sequences used to verify the core functions of the software. Specifically, it can be implemented by simulating operational steps based on key business processes, such as executing queries, inserts, transaction rollbacks, and other operations in database patches. Regular matching refers to pattern recognition of log content through predefined regular expression patterns. Specifically, it can be implemented using the FindString or MatchString methods of the regexp package, such as searching for success identifiers such as "transaction committed successfully" in the log. OCR or automated testing tools refer to technical means for obtaining the status of graphical interface controls. Specifically, the Tesseract OCR engine can be used to parse text in interface screenshots, or the enabled and visible attribute values ​​of controls can be obtained through Selenium WebDriver.

[0093] The automated verification module first executes key software operations in a predefined sequence, such as simulating page loading, form submission, and plug-in invocation in a browser patch. Logs generated during the operation are captured in real time and scanned line by line using a regular expression matching engine to detect whether there are keywords that match the successful pattern. Simultaneously, the interface status detection module obtains the status of specific UI elements through screenshots or control tree traversal, for example, checking whether a "Save" button is clickable or a progress bar has reached 100%. Functional verification is considered passed when the execution results of all test items meet expectations.

[0094] Traditional manual testing requires operators to step through test cases and visually observe the results, which can easily lead to inadequate verification due to missed operations or subjective judgment bias. However, a combined verification approach based on regular expressions and automated tools enables objective testing covering the entire process. For example, regular expressions can be used to precisely match transaction submission status codes in logs, avoiding potential omissions that can occur when manually reviewing massive log volumes.

[0095] Reference Figure 4 ,This application further proposes that in step S5, whether to synchronize files is determined based on the verification results and network behavior.,If the functional verification is successful and the user does not block any network requests, the files modified by the patch in the container are copied to the target software installation directory of the host machine; otherwise, all changes in the container are discarded.

[0096] The steps to copy the patched files in the container to the host machine include:

[0097] Step S51: Use the Go language to traverse the target software installation directory in the container, calculate the hash value of the file and compare it with the original file to obtain a modified file list;

[0098] Step S52: Only the files in the modified file list are extracted to a temporary directory of the host machine through the container export function;

[0099] Step S53: Run the automated verification module again to verify the original software application export file on the host machine. If the verification is successful, the original file is overwritten; otherwise, the file is discarded.

[0100] Among them, calculating the hash value of a file refers to the process of generating a unique identifier for a file through a hash algorithm, which can be specifically implemented using the SHA-256 algorithm, and is used to accurately identify modified files and avoid waste of resources caused by full copying. The container export function refers to the operating interface for transferring files inside the container to the host machine, which can be specifically implemented through the container file system export interface of the Docker API, and is used to achieve directional transfer of files inside and outside the container. The host machine temporary directory refers to the temporary storage space allocated by the operating system, which can be specifically created through the os.MkdirTemp function of the Go language, and is used to isolate and store patch files to be verified. Running the automated verification module again refers to a secondary verification of the synchronized host environment, which can be specifically implemented by reusing the test script of step S4 to ensure the compatibility of patch files in the real environment.

[0101] When the patch program in the container is executed, the changed files are quickly located through the hash value comparison algorithm. For example, only files with inconsistent hash values ​​are filtered out to generate a modified file list. Subsequently, the files in the modified file list are transferred in batches to the temporary storage area of ​​the host machine through the export function of the container management interface. Before overwriting the original files, the automated verification module will reload the target software on the host machine and execute predefined functional test cases, such as verifying the software startup time, memory usage, and core business processes. Only when all test items pass the preset threshold will the patch files in the temporary directory be moved to the target installation directory to complete the final update.

[0102] Traditional methods for synchronizing patch files typically copy entire directories, which can easily lead to redundant file overwriting or configuration conflicts. Existing virtualization solutions require the complete export of virtual machine images; for example, VMware's vmdk file export operation can take over 10 minutes. This solution uses hash comparison to achieve incremental synchronization, transferring only 5% of modified files, for example. Furthermore, secondary verification ensures the effectiveness of the patch in the real environment, avoiding the risk of environmental contamination caused by direct overwriting.

[0103] This application further proposes a software patch security execution system based on container isolation, which includes a user interface module, a container management module, a network monitoring module, an automatic verification module and a file synchronization module, all of which are implemented in the Go language.

[0104] Among them, the user interface module refers to the interactive unit used to receive user input information. Specifically, the fmt package and flag package in the Go language can be used to implement command line parameter parsing, or the fyne framework can be used to build a graphical interface for collecting the target software path and patch file path to provide input parameters for subsequent processing.

[0105] The container management module refers to a control unit used to create a temporary container environment. Specifically, a temporary container can be created by calling the Docker SDK or executing the docker run command, and the target software directory of the host machine can be mounted into the container in read-only mode to prevent the patch program from making irreversible modifications to the original files.

[0106] The network monitoring module refers to a security unit used to intercept and analyze network communications. Specifically, it can use the Go language's net package and gopacket library to build a transparent proxy, redirect container traffic through iptables rules, and display the source address, destination port, and data content of network requests in real time, providing users with an interactive decision-making interface.

[0107] The automated verification module refers to a test unit used to detect software functions. Specifically, it can start the target software process through the Go language os / exec package, combine regular expression matching log output, or call Headless Chrome to perform interface element detection to verify the integrity of the core functions after the patch is applied.

[0108] The file synchronization module refers to the operation unit used for data migration. Specifically, it can use the Go language's file system traversal interface to compare the hash value differences of files inside and outside the container, and use the container snapshot export function to overwrite the verified modified files to the original directory of the host machine.

[0109] When the user submits the target software path and patch file path through the command line or graphical interface, the container management module starts a temporary container environment, mounts the host's software installation directory in read-only mode, and mounts the patch file as an executable file. The network monitoring module establishes a transparent proxy channel on the host side, captures the network connection requests initiated by the patch program in the container in real time, and asks the user to confirm release or interception through a pop-up dialog box or terminal prompt. The automated verification module runs predefined test scripts inside the container, such as simulating the user operation process after starting the target software, and checking whether the response results of key functions meet expectations. When all network requests are authorized and the function verification passes, the file synchronization module identifies the modified files through hash value comparison, exports them from the container and overwrites the original files of the host. If any link is abnormal, the container environment will be destroyed immediately to ensure that no traces of modification remain.

[0110] Traditional patch deployment solutions install directly on the host environment, lack dynamic monitoring of network behavior, and rely on manual functional verification. This system, however, uses container isolation technology to restrict patch execution to a temporary environment. It integrates a transparent proxy to enable real-time interception of network requests and user interaction. It also employs automated test scripts to rapidly verify software functionality, significantly shortening the patch verification cycle while ensuring security. Compared to virtual machine solutions, container environments can boot up in seconds, reducing resource usage by approximately 80%, making them more suitable for scenarios requiring frequent patch testing.

[0111] The container-isolated software patch security execution system also includes a whitelist management module for storing known safe patch characteristics, which include file hash values, destination addresses and ports of network requests. When the characteristics of a patch match records in the whitelist, its network request is automatically allowed and the user confirmation step is skipped.

[0112] The whitelist management module refers to a database component that stores trusted patch features. It can be implemented using a key-value database or a relational database to quickly match the hash value of the current patch with network behavior features. The file hash value refers to the digital fingerprint of the patch generated using the SHA-256 algorithm. It can be implemented using the Go language crypto / sha256 package to verify the integrity of the patch file. The destination address and port of a network request refer to the combination of the target IP and port number in the TCP / IP protocol. This can be achieved by parsing the IP header and TCP header of the network data packet to identify whether the communication target belongs to a trusted server.

[0113] The whitelist management module loads pre-configured trusted patch signature data during system initialization. When the network monitoring module captures a network request initiated by a patch program, it first extracts the request's target address, port, and patch file hash value, and compares them with the whitelist database in real time. If a match exists for all three signatures, the network request is allowed and logged. If some signatures do not match, the user confirmation process is triggered. By establishing a trusted signature library, this module incorporates known secure network communication behaviors into automated processing, reducing the frequency of manual intervention.

[0114] Traditional firewalls can only filter network traffic based on static rules and are unable to make dynamic decisions based on patch file characteristics. This solution combines patch authentication with network behavior control through a whitelist mechanism. This reduces the execution time of trusted patches while ensuring security. For example, for official vendor patches that have passed security audits, their network requests can be exempted from manual review.

[0115] It should be noted that the parts not covered by the present invention are the same as the existing technology or can be implemented by using the existing technology. The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art who, within the technical scope disclosed by the present invention, makes equivalent substitutions or changes based on the technical solution and inventive concept of the present invention shall be covered by the scope of protection of the present invention.

Claims

1. A software patch security execution method based on container isolation, characterized in that: The following steps are involved: Step S1, receiving the target software installation path and patch file path; Step S2, create a temporary container environment and mount the directory; Step S3, running a network monitoring module to intercept requests when executing the patch program in the container; Step S4: Run the target software in the container and execute the functional test script pre-defined by the automated verification module to verify the software functions and determine the core functions of the software; Step S5: Determine whether to synchronize the file based on the verification result and network behavior.

2. A software patch security execution method based on container isolation according to claim 1, characterized in that: In step S2, the Go language is used to call the container management interface to create a temporary container environment. The target software installation directory is mounted in read-only mode to the first path of the container, and the patch program is mounted as an executable file to the second path of the container. The temporary container environment is configured to prohibit persistent storage and automatically destroy after the container exits. The steps for creating a temporary container environment are as follows: Step S21, using the Go language os / exec package to call the Docker command line tool or using the Go language Docker SDK to create a container; Step S22: configuring an independent network namespace for the container; Step S23: Start a daemon process inside the container and receive an execution command sent by the host.

3. The method for securely executing software patches based on container isolation according to claim 1, characterized in that: In step S3, when the patch program is executed in the container, a network monitoring module written in Go language is run on the host machine. The network monitoring module intercepts all network requests of the patch program in the container by creating a transparent proxy. When the network monitoring module detects a network request, it pauses the network request and displays a dialog box to the user, prompting the user to choose to allow or block the request. The processing function of the network request is: in, Indicates the function that processes the request. Indicates that output is allowed. Indicates that the output is blocked; Represents a network request.

4. A software patch security execution method based on container isolation according to claim 3, characterized in that: Creating a transparent proxy involves the following steps: Step S31, using the net package and gopacket library in the Go language on the host machine to monitor the original network data packet; Step S32, redirecting the outbound traffic of the container to the port monitored by the proxy program by configuring iptables rules; Step S33, after receiving the redirected traffic, the proxy program parses and extracts the target address, source address, port and data content; Step S34: Display the information on the user interface. Based on the user's selection, the network request is released or intercepted by the proxy program.

5. The method for securely executing software patches based on container isolation according to claim 1, wherein: In step S4, the target software is run in the container, and the automated verification module written in Go language executes the predefined functional test script to determine whether the core functions of the target software are running normally. The expression used by the automated verification module to verify the function of the patched software is as follows: in, Indicates the verification result. Indicates success, Indicates failure, Indicates the total number of test items, Indicates the The weight of the test items, Indicates the The results of the test items; Indicates the preset threshold.

6. A method for securely executing software patches based on container isolation according to claim 5, characterized in that: The automated verification module written in Go language executes predefined functional test scripts including: Step S41, starting the target software and executing the key operation sequence; Step S42: Capture the output log of the target software and use the regexp package in the Go language to perform regular expression matching to check whether it contains the expected success pattern; Step S43: Check the status of the controls on the target software interface and obtain status information through OCR or automated testing tools.

7. The method for securely executing software patches based on container isolation according to claim 1, characterized in that: In step S5, whether to synchronize files is determined based on the verification results and network behavior. If the functional verification is successful and the user does not block any network requests, the files modified by the patch in the container are copied to the target software installation directory of the host machine; otherwise, all changes in the container are discarded.

8. A software patch security execution method based on container isolation according to claim 7, characterized in that: Copying the patched files in the container to the target software installation directory on the host machine includes: Step S51: Use the Go language to traverse the target software installation directory in the container, calculate the hash value of the file and compare it with the original file to obtain a modified file list; Step S52: Only the files in the modified file list are extracted to a temporary directory of the host machine through the container export function; Step S53: Run the automated verification module to verify the original software application export file on the host machine, and overwrite the original file after the verification passes.

9. A system for the container-isolated software patch security execution method according to any one of claims 1 to 8, characterized in that: The system includes: A user interface module receives a target software installation path and a patch file path specified by a user; The container management module, implemented in Go language, is used to create and manage temporary container environments; The network monitoring module, implemented in Go language, is used to intercept and display network requests and wait for user decisions; The automated verification module, implemented in Go, is used to execute predefined functional test scripts to verify the functionality of the patched software. The file synchronization module, implemented in Go language, is used to synchronize modified files in the container to the host machine.

10. The system according to claim 9, characterized in that The system also includes a whitelist management module for storing known safe patch characteristics, wherein the patch characteristics include: File hash value, destination address and port of network request; When the patch's characteristics match those in the whitelist, its network request is automatically allowed and the user confirmation step is skipped.

Images