Software package management and control method and device, equipment and storage medium

Abstract

The invention provides a software package management and control method and device, equipment and a storage medium, relates to the technical field of computers, and can guarantee the security of software package files entering a software library from the source. The method comprises the following steps: acquiring a software package file; software package admission detection is carried out on the software package file to obtain a detection result of the software package file, and the software package admission detection is used for indicating to detect the security of the software package file; and on the basis of a detection result, the software package file passing the software package admission detection is racked to a software library.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a software package management method, apparatus, device, and storage medium. Background Technology

[0002] Software package management refers to the process of managing and controlling the acquisition, storage, distribution, installation, and operation of software installation packages.

[0003] In related technologies, the management of software installation packages employs a hybrid model combining internal private sources and manual external downloads. Specifically, the enterprise maintains an internal software repository, from which hosts can directly download and install software packages. For software packages not available in the internal repository, users need to download them from the official website or mirror site and then upload them to the enterprise software repository via a file transfer tool. The host then selects and downloads the required software package from the internal repository.

[0004] However, while related technologies can download the required software installation packages from external sources to internal software repositories, the obtained and downloaded software installation packages may carry vulnerabilities or viruses, and the security of software installation packages entering internal software repositories cannot be guaranteed. Summary of the Invention

[0005] This application provides a software package management method, apparatus, device, and storage medium that can ensure the security of software package files entering the software library from the source.

[0006] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides a software package management method, the method comprising: Obtain the software package file. Perform software package access testing on the software package file and obtain the test results. Based on the test results, upload the software package file that passes the software package access testing to the software repository. Software package access testing is used to indicate whether the security of the software package file needs to be tested.

[0007] The solution provided in this application performs a package access check on the package file before it is uploaded to the software repository, obtaining the check result. If the package file passes the access check, it is uploaded to the software repository. This achieves security testing of the package file before it enters the software repository, ensuring the security of the package files uploaded to the repository and effectively preventing malicious code, viruses, or package files with security vulnerabilities from entering the software repository, thus protecting the security of package files entering the software repository from the source.

[0008] One possible implementation of the above-mentioned software package access control can be specifically implemented as follows: sandbox testing of the software package files. Sandbox testing is used to indicate that the software package files should be tested in an isolated network environment. By conducting sandbox testing on the software package files, they can be tested in an isolated network environment, effectively detecting risk information about the software package files and ensuring their security before access control.

[0009] Another possible implementation is that the above-mentioned package access detection for package files can be specifically implemented by matching the package file with risky packages in a historical risk software repository. Here, historical risk information matching is used to instruct matching based on the package file's name and / or version number within the historical risk software repository. By matching the package file with risky packages in the historical risk software repository, the matching results are obtained. Based on the matching results, it is possible to detect whether the package file belongs to the historical risk software repository, thereby achieving rapid matching and interception to ensure that known risky packages do not enter the software repository.

[0010] Another possible implementation is that the above-mentioned package access control for package files can be specifically implemented as: performing package component analysis on the package files. Package component analysis is used to indicate the analysis of open-source components and / or security vulnerabilities in the package files. By analyzing the open-source components and / or security vulnerabilities in the package files, known security vulnerabilities existing in the open-source components of the package files can be detected.

[0011] Another possible implementation, the software package management method provided in this application, may further include: obtaining the application scope of software package files uploaded to the software repository; and distributing the software package files based on their application scope. Distributing software package files according to their application scope can achieve precise distribution of software package files, thereby preventing software package files from being distributed to applications for which they are not authorized.

[0012] Another possible implementation, based on the application scope of the software package file, can be specifically implemented as follows: Determine the host account information within the application scope of the software package file. Distribute the software package file to the hosts corresponding to the host account information. Here, the host account information indicates the account information of the hosts within the authorized scope of the software package file. Distributing the software package file to the hosts corresponding to the host account information within the application scope of the software package file enables control over the software package file distribution process, improving the security and accuracy of software package file distribution.

[0013] Another possible implementation is as follows: Obtain the file to be uploaded. Perform file recognition on the file to be uploaded to obtain the software package file. By performing file recognition on the file to be uploaded, the file type of the file to be uploaded can be determined, thereby distinguishing the software package file from other types of files, and thus obtaining the software package file.

[0014] Another possible implementation is that the above-mentioned file recognition of the file to be uploaded to obtain the software package file can be specifically implemented as follows: The file extension and / or header code characteristics of the file to be uploaded are identified and verified to obtain the software package file. By identifying and verifying the file extension and / or header code characteristics of the file to be uploaded, it can be detected whether the file to be uploaded is a software package file, and thus the software package file can be obtained.

[0015] Another possible implementation of the software package management method provided in this application may further include: obtaining a risk scheduling instruction, which indicates information about risky software package files; parsing the risk scheduling instruction to obtain risk file information, which describes the risk information of the software package files in structured data; and managing the software package files based on the risk file information and the application status of the software package files. By parsing the risk scheduling instruction to obtain risk file information, and then managing the software package files according to the risk file information and the application status of the software package files, the method achieves management of risky software package files.

[0016] Another possible implementation, based on the risk file information and the application status of the software package file, can be implemented as follows: If a software package file that meets the risk file information criteria is listed in the software repository but not distributed, it will be removed from the software repository. Alternatively, if a software package file that meets the risk file information criteria is distributed from the software repository to the host but not installed on the host, an alarm message will be displayed, indicating that the software package file is risky and its use is suspended. Or, if a software package file that meets the risk file information criteria is installed on the host, the software package file on the host will be remediated. When a software package file meets the risk file information criteria, the server takes corresponding risk handling measures according to the different application statuses of the software package file, thereby achieving precise control over risky software package files and improving the efficiency of security vulnerability remediation.

[0017] Another possible implementation involves including one or more of the following in the aforementioned risk file information: the ID of the risk dispatch instruction, the name of the risk package file, the version range of the risk package file, the vulnerability risk level, the type of the risk package file, the vulnerability description, the solution, the source of vulnerability discovery, or the time of vulnerability discovery. Based on multiple pieces of risk file information, risky package files can be quickly and accurately identified, thereby improving the efficiency of security vulnerability remediation.

[0018] Secondly, a software package management device is provided, comprising: an acquisition module and a processing module. The get module is used to retrieve package files.

[0019] The processing module is used to perform package access detection on the package file and obtain the detection result of the package file. The package access detection is used to indicate the security detection of the package file.

[0020] The aforementioned processing module is used to upload the software package file to the software library based on the detection results.

[0021] In one possible implementation, the processing module is further configured to: perform sandbox testing on the software package file, wherein sandbox testing is used to indicate trial operation of the software package file in an isolated network environment; or, match the software package file with risky software packages in a historical risk software repository, wherein historical risk information matching is used to indicate matching in the historical risk software repository based on the name and / or version number of the software package file; or, perform software package component analysis on the software package file, wherein software package component analysis is used to indicate analysis of open-source components and / or security vulnerabilities in the software package file.

[0022] In another possible implementation, the aforementioned acquisition module is also used to: acquire the application scope of the software package files uploaded to the software repository. The aforementioned processing module is also used to distribute the software package files based on their application scope.

[0023] In another possible implementation, the above processing module is further configured to: determine the host account information within the application scope of the software package file, wherein the host account information indicates the account information of the hosts within the authorization scope of the software package file; and distribute the software package file to the hosts corresponding to the host account information.

[0024] In another possible implementation, the aforementioned acquisition module is also used to: acquire the file to be uploaded. The aforementioned processing module is also used to perform file recognition on the file to be uploaded to obtain the software package file.

[0025] In another possible implementation, the above processing module is also used to: identify and verify the file extension and / or header code characteristics of the file to be uploaded, and obtain the software package file.

[0026] In another possible implementation, the acquisition module is further configured to: acquire risk scheduling instructions, which indicate information about risky software package files. The processing module is further configured to parse the risk scheduling instructions to obtain risk file information, which describes the risk information of the software package files using structured data. Based on the risk file information and the application status of the software package files, the software package files are managed and controlled.

[0027] In another possible implementation, the above processing module is further configured to: remove the software package file that meets the risk document information from the software repository if its application status is "already uploaded to the software repository but not distributed"; or, display an alarm message if the application status of the software package file that meets the risk document information is "already distributed from the software repository to the host but not installed on the host," with the alarm message indicating that the software package file is at risk and its use is suspended; or, perform rectification processing on the software package file on the host if the application status of the software package file that meets the risk document information is "already installed on the host."

[0028] Another possible implementation is that the aforementioned risk file information includes one or more of the following: the ID of the risk dispatch instruction, the name of the risk package file, the version range of the risk package file, the vulnerability risk level, the type of the risk package file, the vulnerability description, the solution, the source of vulnerability discovery, or the time of vulnerability discovery.

[0029] The technical effects of any implementation method in the second aspect can be found in the technical effects of any implementation method in the first aspect mentioned above, and will not be repeated here.

[0030] Thirdly, a computer device is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the software package management method described above.

[0031] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the software package management method described above.

[0032] Fifthly, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the software package management method described above is implemented.

[0033] The solutions provided in aspects three through five above are used to implement the method provided in aspect one above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation method of the solutions provided in aspects three through five above can be found in the technical effects corresponding to any implementation method in aspect one above, and will not be described in detail here.

[0034] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

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

[0036] Figure 1 A schematic diagram of the computer system architecture provided in the embodiments of this application; Figure 2 A flowchart illustrating a software package management method provided in an embodiment of this application; Figure 3 An interface diagram for software package file type detection provided in this application embodiment; Figure 4 A flowchart illustrating another software package management method provided in this application embodiment; Figure 5 An interface diagram for software package file distribution control provided in an embodiment of this application; Figure 6 Another interface diagram for software package file distribution control provided in this application embodiment; Figure 7 A flowchart illustrating another software package management method provided in this application embodiment; Figure 8 A flowchart illustrating another software package management method provided in this application embodiment; Figure 9 A schematic diagram illustrating a software package file access approval process provided in an embodiment of this application; Figure 10 A flowchart illustrating another software package management method provided in this application embodiment; Figure 11 A flowchart illustrating another software package management method provided in this application embodiment; Figure 12 This is a schematic diagram of the structure of a software package management device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0037] In the embodiments of this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different. There is no sequential or major order among the technical features described by "first" and "second".

[0038] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0039] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0040] Furthermore, the network architecture and scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0041] To facilitate understanding, the terms used in the embodiments of this application will be explained first.

[0042] Access control refers to the permission or qualification to enter a certain field, system, or organization, ensuring that only qualified entities can enter a specific area. The specific meaning of access control varies depending on the application scenario. For example, in the application scenario of system access control, access control refers to a user or device obtaining permission to access a system, network, or platform, such as logging into an account or connecting to WiFi; in the application scenario of regional access control, access control refers to permission to enter a specific region.

[0043] For example, the industry-standard method for managing software packages often combines internal private sources with manual external downloads to control host software installation packages, which will be briefly explained below.

[0044] Enterprises typically maintain internal private software repositories, such as Yum (Yellow Dog Updater, Modified, a package manager) or APT (Advanced Packaging Tool), which allow for centralized software management. Administrators pre-select a batch of basic, general-purpose software for inclusion in the private repository. When a host needs to install software, it can directly pull the software from the repository for installation. Here, "repository software" refers to software included in the private repository. However, private software repositories usually only maintain a small number of basic software packages and have a low update frequency, meaning that most software needs cannot be met through this secure method. For software missing from the private repository, business personnel typically manually download the installation package from official websites or mirror sites on the internet and then upload it to the internal private repository via file transfer tools. The host then retrieves the downloaded software from the private repository for installation.

[0045] However, the aforementioned method of combining internal private sources with manual external downloads may result in software installation packages containing vulnerabilities and viruses. Furthermore, the transmission of software installation packages from official internet websites or mirror sites to the enterprise's internal network can introduce multiple uncontrollable risks. In addition, the lack of security barriers in the initial stage of entering the private software repository allows external threats to directly infiltrate it. Therefore, the security of software installation packages entering the internal software repository cannot be guaranteed.

[0046] Based on this, this application provides a software package management method. Before uploading a software package file to a software repository, a software package access check is performed on the file to obtain the check result. If the software package file passes the access check, it is uploaded to the software repository. This achieves security testing of the software package file before it enters the software repository, ensuring the security of the software package files uploaded to the repository and effectively preventing malicious code, viruses, or software package files with security vulnerabilities from entering the software repository, thus protecting the security of the software repository from the source.

[0047] The solutions provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0048] The solution provided in this application can be applied to Figure 1 In the computer system shown, such as Figure 1 The diagram shows the architecture of the computer system.

[0049] For example, Figure 1 The computer system shown includes server 101, host 102, software package download source 103, and risk dispatch instruction distribution center 104.

[0050] Among them, server 101 can be a device that provides software package management, such as a file server responsible for storing software package files, or a security detection server responsible for performing software package file access detection.

[0051] The host 102 can be a specific computer device within an enterprise that needs to install software and deploy applications. Optionally, the host 102 can be at least one of a smartphone, tablet computer, e-book reader, MP3 player, MP4 player, laptop computer, and desktop computer.

[0052] Package download source 103 can be a website where you can obtain the packages needed by the enterprise, such as an official website or mirror site on the Internet. Business personnel can manually download the required packages from package download source 103.

[0053] Risk dispatch instruction issuance center 104 can be an organization with vulnerability intelligence release authority, responsible for collecting, analyzing and issuing information related to network security vulnerabilities.

[0054] Specifically, server 101 can obtain the necessary software packages for internal use from software package download source 103. Server 101 can also receive information related to network security vulnerabilities issued by risk dispatch instruction distribution center 104. After performing a series of tests on the obtained software packages, the software package files can be uploaded to the enterprise's internal software repository, and then distributed to internal network hosts.

[0055] Optionally, server 101 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data, etc. This application embodiment does not limit the implementation method or application scenario of server 101. This application provides a software package management method that includes full lifecycle management of software installation packages, including identification, access control, distribution, and vulnerability discovery and remediation. While managing the entire lifecycle of the software installation package, logs are recorded at each stage, establishing a full lifecycle log record for the software installation package from identification, access control, distribution to post-installation vulnerability discovery and remediation.

[0056] Among them, identification refers to identifying the file type of the software installation package.

[0057] Access control refers to the security testing of software installation packages identified as software packages before they are allowed into the internal software repository.

[0058] Distribution refers to the process of distributing software package files from a software repository to other hosts.

[0059] Vulnerability discovery and remediation refers to the process of identifying software packages with security vulnerabilities and patching those vulnerabilities. The following sections will explain these four aspects in detail.

[0060] Figure 2 This is a flowchart illustrating a software package management method provided in an embodiment of this application. The method can be executed by a server, which can be... Figure 1 Server 101 in the example. The software package management method provided in this application is applicable to software package file access scenarios. In such scenarios, the server performs access checks on the acquired software package files to determine whether the software package files are allowed to enter the software library. By performing software package access checks on the acquired software package files using the method provided in this application, obtaining the detection results, and then uploading the software package files to the software library based on the detection results, the software package files can be controlled, thereby improving the security of software package management from the source.

[0061] like Figure 2 As shown, the software package management method provided in this application embodiment may include: Step S201: The server obtains the software package file.

[0062] In this context, a software package file can be understood as a file whose file type is a software package. For example, software package files include, but are not limited to, software installation package formats such as EXE (Executable), RPM (Red Hat Package Manager), DEB (Debian Package), and MSI (Microsoft Installer).

[0063] Specifically, the server retrieves the file to be uploaded. Then, it performs file recognition on the file to be uploaded to obtain the software package file.

[0064] The files to be uploaded can be understood as various files obtained from the software package download source and prepared to be uploaded to the security testing server. Optionally, the software package download source can be an official website, such as the Microsoft Office, WPS official website, Oracle official download site, etc., or it can be a mirror source maintained by the system vendor, such as the CentOS official mirror site, Ubuntu official mirror site, etc.

[0065] In some embodiments, the server obtains the file to be uploaded from a software package download source.

[0066] For example, for software missing from the software repository, business personnel can manually download the software package from the official website or mirror site on the Internet. However, the file type of the software package downloaded by the business personnel may be a software package file or a non-software package file, such as a docx (Document Open XML Format, Word Open XML document), xlsx (Excel Open XML Spreadsheet, Excel Open XML Spreadsheet), txt (Text File), or other ordinary text files. Therefore, the server identifies the file type of the software package obtained from the software package download source and then obtains the software package file based on the file type identification result.

[0067] Furthermore, the server identifies and verifies the file extension and / or header code characteristics of the file to be uploaded to obtain the software package file.

[0068] Specifically, after obtaining the file to be uploaded from the software package download source, the business personnel identify and verify the file extension and / or header code characteristics of the file to be uploaded to detect the file type of the file to be uploaded.

[0069] In this context, the file extension refers to the characters following the period (.) at the end of the file name. For example, .txt indicates a text file, .jpg (Joint Photographic Experts Group) indicates a JPEG image, and .exe indicates an executable file.

[0070] The header code characteristics can be understood as a specific sequence of bytes or data structure contained at the beginning of a file, used to identify the file's type and format. Different file formats have different header code characteristics. For example, JPEG files begin with FFD8 FF, EXE / DLL (Dynamic Link Library) files begin with 4D 5A, PNG (Portable Network Graphics) files begin with 89 50 4E 47, PDF (Portable Document Format) files begin with 25 50 44 46, and ZIP archives begin with 50 4B 03 04.

[0071] By identifying and verifying the file extensions and / or header code features of the uploaded files, accurate identification of file types can be achieved, distinguishing between package files and non-package files, while effectively preventing attempts to bypass detection by modifying filenames.

[0072] For example, such as Figure 3 The interface shown is for detecting the file type of the software package. For example, after business personnel obtain the file to be uploaded from the software package download source, they enter the file type identification process for the file to be uploaded, and perform file detection. In the identification process, the magic number and file extension of the file to be uploaded are detected. The detection process includes file header analysis, extension detection, type matching, and software package detection.

[0073] File header analysis refers to obtaining specific bytes of data at the beginning of a file, which can quickly identify the file type.

[0074] The file header, also known as the magic number, is a fixed-length data field at the beginning of a file. It contains metadata about the file, such as file type identifier, version number, and encoding method. Different file formats have different file header characteristics.

[0075] For example, JPEG files begin with FF D8 FF, EXE / DLL files begin with 4D 5A, PNG files begin with 89 50 4E47, PDF files begin with 25 50 44 46, and ZIP archives begin with 50 4B 03 04.

[0076] File extension detection refers to the detection of file extensions.

[0077] However, file extensions are easily modified and have low security. Therefore, they are often used in conjunction with file header analysis to verify the file type by checking the actual content of the file, thus preventing malicious files from being disguised as safe files.

[0078] Type matching refers to matching the file header and file extension to determine the file type of the file to be uploaded.

[0079] Package detection refers to the detection process to determine whether a file to be uploaded is a package file.

[0080] The results are displayed after the file detection is completed. The results include the file type and software package.

[0081] For example, the result of file type detection can be: Windows executable file (EXE / DLL). The result of package detection can be: It is a package file.

[0082] For example, the server obtains the file to be uploaded as chrome.exe from the package download source. It identifies the file extension as .exe and then identifies the header code as 0x4D5A7800. The server then matches the file extension with the header code. Specifically, the file extension is identified as .exe, and the header code 0x4D5A7800 satisfies the condition that EXE files begin with 4D5A, thus determining the file type to be a Windows executable file (EXE). Simultaneously, the package detection result is confirmed as a package.

[0083] In some embodiments, after identifying and verifying the file to be uploaded to obtain the software package file, the server calculates the hash value of the software package file and compares it with whether a file record with the same hash value already exists in the software library. If so, the user is notified that the software package file already exists in the software library, avoiding duplicate storage. Furthermore, digitally signing the hash value of the software package file can improve the security of the software package file during transmission.

[0084] In this context, a digital signature can be understood as the server using its private key to hash and sign the software package file when sending it, while the recipient uses its public key to verify it upon receiving the package. Digital signatures ensure that the software package file received by the recipient was indeed published by the server and has not been tampered with.

[0085] For example, after the software package file completes the identification and detection, the software package file needs to be transferred from the server that performed the identification and detection, such as the identification and detection server, to the server that performed the access detection, such as the access detection server, or from one module of the server to another module of the same server.

[0086] The following describes digital signatures using the example of an identification detection server sending a software package file to an access detection server. First, the identification detection server selects a hash function to calculate the hash value of the software package file. Then, it encrypts the hash value using its private key and packages the software package file and digital signature together before sending it to the access detection server. Upon receiving the software package file and digital signature, the access detection server first obtains the public key and then uses the obtained public key of the identification detection server to decrypt the digital signature, thus retrieving the original hash value. The access detection server then uses the same hash function as the identification detection server to calculate a new hash value for the received software package file. This new hash value is compared with the decrypted original hash value. If the two hash values ​​are identical, the software package file has not been tampered with during transmission, and the software package file received by the access detection server is the same one sent by the identification detection server. The public key can be obtained in various ways, such as downloading it from a public key server provided beforehand by the identification detection server.

[0087] In addition, for non-package files, the server uses its large model capability to detect whether there is sensitive content in the file. If there is no sensitive content, it allows the file to be uploaded and proceeds with the file upload process. Non-package files do not need to undergo an access control process, so they are directly uploaded to the file server for storage.

[0088] The file upload process refers to the standardized steps required to transfer local files from a user's device to a server over a network.

[0089] For example, for non-package files such as documents, images, compressed files, or text files, the server uses its large model capabilities to detect the content of the non-package files. If the non-package files do not contain sensitive content such as illegal or non-compliant information, public safety information, or personal privacy information, the non-package files are uploaded from the business personnel's local terminals to the file server for storage.

[0090] Step S202: The server performs package access detection on the package file and obtains the detection result of the package file.

[0091] The detection result refers to the assessment of the security of the software package file. The detection result of the software package file is used to determine whether the software package file is allowed to enter the software repository.

[0092] Package access control is used to indicate the security checks performed on package files. Package access control can be understood as checking the security of package files through scanning, verification, and other methods before deployment.

[0093] Specifically, after obtaining the software package file, the server performs software package admission checks on the software package file.

[0094] Optionally, during the software package admission detection phase, the server can obtain relevant metadata information about the software package files. Metadata information refers to data describing the software package files. The software package file itself is data, while the metadata information describes the data and is used for data identification, management, and use. Optionally, the metadata information includes basic information such as: software package name, version number, icon, vendor, feature type, applicable architecture, description, version features, and whether it is general-purpose, as well as the software category of the software package file, for example, software categories include: database, middleware, operation and maintenance monitoring, tools, etc.

[0095] In one possible implementation, the method of package admission detection includes one or more of the following, but is not limited thereto, and the embodiments of this application do not specifically limit it: Method 1: Perform sandbox testing on the software package files.

[0096] Sandbox testing is used to indicate the trial run of software package files in an isolated network environment.

[0097] An isolated network environment can be understood as placing software package files in a virtual environment that is completely isolated from the network, thereby preventing malware from spreading or stealing data and ensuring the security of the software package access detection process.

[0098] Sandbox testing refers to dynamic behavior analysis of software packages. Dynamic behavior analysis involves monitoring the actual behavior of software packages when they run in an isolated network environment, and determining whether the software package is malicious by observing its various operations during execution.

[0099] Furthermore, if the sandbox detection results are abnormal, or if the sandbox detection cannot complete the detection of the software package files (e.g., due to an abnormal sandbox environment, detection timeout, or file corruption), the software package access detection process will be terminated directly.

[0100] For example, sandboxes are primarily used to analyze executable files, such as .exe, .dll, and .scr (Screen Saver) script files. Other custom-formatted software packages or those that are corrupted may not be parsed by the sandbox environment, thus preventing sandbox testing. Furthermore, the sandbox service may experience temporary outages or maintenance, preventing sandbox testing. In such cases, the server will terminate the software package admission testing process. Method 2: The server matches the software package file with risky software packages in the historical risky software repository.

[0101] Among them, historical risk information matching is used to instruct matching in the historical risk software library based on the name and / or version number of the software package file.

[0102] A historical risk software repository is a database specifically used to store and manage information about software packages known to pose security risks or malicious behavior.

[0103] Historical risk information refers to the data related to software packages containing risks such as security threats, vulnerabilities, and malicious information that have been identified, recorded, and analyzed in the past. A historical risk software library can be formed based on historical risk information.

[0104] Matching refers to the process of comparing the software package file to be detected with historical risk information in the historical risk software database, and making a correlation judgment through identification information such as package name and version number.

[0105] Specifically, the software package file name and / or version number is compared and verified with the software package file name and / or version number in the historical risk software repository. If the name and version number of a software package file in the historical risk software repository are completely consistent with the name and version number of the software package file, the software package file is determined to be an insecure file, and the software package access detection process is terminated.

[0106] For example, if a software package file is named hash.exe and has a version number of 1.0, and the historical risk software repository contains a software package file named hash.exe with a version number of 1.0, then the software package file is considered risky, and the software package access detection process for that software package file will be terminated.

[0107] Method 3: Analyze the software package components in the software package file.

[0108] Among them, package component analysis is used to indicate the analysis of open source components and / or security vulnerabilities in package files.

[0109] Specifically, by analyzing the package components of the package files, it is possible to identify the open-source components and known vulnerabilities contained in the package files, thereby improving the security of package access detection.

[0110] For example, scanning a Java application deployment package using SCA (Software Composition Analysis) can identify all the third-party open-source components referenced within it, such as log4j 2.14.1 and Spring Core 5.3.8. These components can then be matched against publicly available vulnerability databases to uncover known security risks. Step S203: Based on the detection results, the server uploads the software package files that have passed the software package access detection to the software library.

[0111] Specifically, the server determines whether to upload a software package to the software repository based on the package admission detection results. If the package file passes the package admission detection, it is allowed to be uploaded to the software repository; if the detection result is unsuccessful, the package file admission process is terminated, and the package file is not allowed to be uploaded to the software repository.

[0112] Optionally, if a software package fails the software package access detection, a detailed detection report can be generated and provided. This report may include the specific detection items that failed the access detection, the reasons for failure, the violated rules and standards, and related logs. Alternatively, software packages that fail the access detection can be moved to a temporary isolation area. In this area, the software package, its metadata, and the detection report are stored together with a retention period, such as 30 days. The submitter can then fix the issues based on the detection report and resubmit a new version within this period. Furthermore, software packages that fail the access detection can be manually reviewed. For example, for software packages that fail the access detection due to security tool misjudgments, the submitter can appeal. The reviewer will make a final decision based on the provided explanations and the detection report, choosing to overturn the original automatic detection result and approve the release, or uphold the original judgment and supplement the reasons for rejection.

[0113] In summary, the solution provided in this embodiment proposes a software package management method. By performing software package access detection on software package files and obtaining the detection results, the software package files that pass the access detection are uploaded to the software library based on the detection results. This achieves security detection of software package files before they enter the software library, ensuring the security of software package files uploaded to the software library and effectively preventing malicious code, viruses, or software package files with security vulnerabilities from entering the software library, thus protecting the security of the software library from the source.

[0114] Furthermore, after a package file that has passed the package access test is uploaded to the software repository, the service can also distribute the package files uploaded to the software repository (see [link]). Figure 4 Steps S204 and S205 in the process.

[0115] Step S204: The server obtains the application scope of the software package files uploaded to the software repository.

[0116] The scope of application of a software package file refers to the range of all hosts that have the right to access the target software package file in the software repository's listing list.

[0117] Once software packages are uploaded to the software repository, they are uniformly incorporated into the artifact center for visual management. The server categorizes software packages into general-purpose and non-general-purpose packages based on their application scope. General-purpose packages are suitable for multiple business scenarios and can be managed and accessed by business personnel in the artifact center, making them visible to all tenants. Non-general-purpose packages are distributed and used only within a specific tenant scope.

[0118] The artifact center can be understood as a platform used to store and manage software package files uploaded to the software repository.

[0119] A tenant can be understood as an independent resource space allocated within the artifact center for different business departments or project teams. For example, development tools and test environment software packages can be distributed to R&D tenants; production environment software packages and system tools can be distributed to operations and maintenance tenants.

[0120] For example, business personnel can log in to the artifact center, select the target software package file to be distributed, and view the application scope of the target software package file. For example, the server can automatically obtain all hosts and corresponding host account information within the tenant range to which the business personnel belong, based on the host they logged in to, and dynamically render this information on the distribution interface for the business personnel to select.

[0121] Dynamic rendering refers to the process by which the server acquires and displays relevant data on the interface in real time based on the permissions of the currently logged-in user.

[0122] Furthermore, once the software package file is uploaded to the software repository, hosts within the application scope of the software package file can view, download, and install the software package file they have access to.

[0123] Step S205: Distribute the software package file based on its application scope.

[0124] Specifically, after the server obtains the application scope of the software package file uploaded to the software repository, it can obtain the host account information within that application scope based on the application scope. This host account information indicates the account information of the hosts within the authorization scope of the software package file. The software package file is then distributed to the hosts corresponding to the specified host accounts.

[0125] After logging into the artifact center, business personnel can view all general-purpose software packages and the non-general-purpose software packages that their respective tenants have access to. After selecting the software package file to be distributed, business personnel can further select the target host to which the software package file should be distributed, and specify the file directory on the target host to store the software package, thereby achieving a software distribution mechanism with controllable permissions and scope. Furthermore, if the target software package file to be distributed is already available in the software repository, it can be directly distributed with a single click; if the target software package file is not available in the software repository, it needs to be added to the management system first before distribution management can proceed. Adding to the management system refers to the process of obtaining the software package file and adding it to the software repository. Specifically, adding to the management system includes the process of identifying, checking for access permissions, and adding the software package file to the repository.

[0126] Specifically, such as Figure 5 The diagram shows the interface for controlling the distribution of software packages. After logging into the artifact center, business personnel click and open the "Create Distribution Task" page. On this page, they can select the target host and target folder directory to which the software package files will be distributed. The target folder directory refers to the file directory on the target host used to store the software packages. Figure 5 As shown, business personnel can select the target host to which the software package file is to be distributed from the host list on the left, and then select the directory to be stored in the directory of the selected target host in the right interface. This allows them to specify the file directory on the target host to store the software package. Finally, they can select "Create Distribution Task" to distribute the software package file, thereby achieving control over the software package file distribution process.

[0127] like Figure 6 The interface diagram shown illustrates the distribution control of software packages. Based on the application scope of the software packages, they can be divided into general-purpose software packages and non-general-purpose software packages.

[0128] exist Figure 6In the interface shown, "general software" refers to general-purpose software packages, while "non-general software" refers to non-general-purpose software packages. After selecting "general software," business users can see all the software categories included in that category on the left side of the interface. For example, general software can be divided into databases, middleware, operations and monitoring, infrastructure, and others. Each category includes multiple subcategories; for example, databases can include relational databases and NoSQL (Not Only SQL) databases; middleware can include message queues, task scheduling, and log management; operations and monitoring can include code management tools, monitoring tools, deployment tools, and CI / CD (Continuous Integration / Continuous Delivery / Continuous Deployment) pipelines; and infrastructure can include operating systems and JDK (Java Development Kit). After selecting a software category, business users can see all the software packages included in that category on the right side of the interface. Business users can then select the target software package and choose one-click distribution to manage the distribution of the software package.

[0129] After a business user submits a distribution task, the server will automatically retrieve the corresponding software package file from the file server and, relying on the underlying distribution mechanism, securely and accurately transfer it to the specified file directory on the selected host. Once the distribution task is complete, the server will generate a notification and send it to the business user, indicating that the distribution operation has been completed.

[0130] Among them, a file server is a server specifically used for storing and managing software package files.

[0131] Furthermore, after the software package files that pass the package access test are uploaded to the software repository, the service can also perform vulnerability discovery and remediation on the uploaded software package files (see...). Figure 4 Steps S206-S208 in the process.

[0132] Step S206: The server obtains the risk scheduling instruction.

[0133] Among them, the risk scheduling instruction is used to indicate information about software package files that are at risk.

[0134] For example, software package files may pose the following risks: carrying malware, counterfeiting, tampering, security vulnerabilities, bundled promotions and adware, abuse of permissions and privacy breaches.

[0135] Among them, carrying malicious programs refers to software packages containing programs that may lead to data theft, system control, or file encryption for ransom. For example, malicious programs may be viruses, Trojans, ransomware, or backdoor programs.

[0136] Counterfeiting refers to the act of impersonating genuine software, deceiving users into downloading it by disguising its name, icon, or interface, and then implanting malicious programs, stealing information, or committing fraud.

[0137] Tampering refers to the modification of software packages by a third party to inject additional code.

[0138] A security vulnerability is a flaw in a software package file that can be exploited by attackers.

[0139] Bundled promotions and adware refer to the silent installation of unnecessary additional programs without the user's knowledge, which can affect system performance and may also cause pop-ups and collect privacy information.

[0140] Abuse of permissions and privacy leaks refer to software packages requesting too many system permissions, such as contacts, location, and camera, which may result in the collection and leakage of personal information and sensitive data.

[0141] For example, a risk scheduling command can be a risky software package file scanning command, used to instruct the server to scan the software repository and all hosts to obtain a list of hosts with risky software package files deployed. A risk scheduling command can also be a risky software package file removal command, used to instruct the server to freeze and remove all scanned risky software package files from the enterprise's internal software repository. A risk scheduling command can also be an access control rule update command, used to instruct the server to perform access control checks on software package files entering the software repository using new access control rules.

[0142] In some embodiments, the server can obtain risk scheduling instructions from the risk scheduling instruction distribution center.

[0143] In one possible implementation, the server can periodically request risk scheduling instructions from the risk scheduling instruction issuance center. For example, the server can send a request to the risk scheduling instruction issuance center every 30 days, and the risk scheduling instruction issuance center will respond by issuing risk scheduling instructions to the server upon receiving the request.

[0144] In another possible implementation, the risk scheduling instruction issuance center will proactively send risk scheduling instructions to the server when it discovers a security vulnerability with a wide impact or a high level of harm.

[0145] For example, when the National Information Security Vulnerability Database or industry security organizations detect a security vulnerability in a widely used basic component, such as the open-source library libcurl being found to have a high-risk remote code execution vulnerability, the National Information Security Vulnerability Database or industry security organizations will proactively push risk dispatch instructions to all servers within their jurisdiction through a secure channel. After receiving the instructions, the servers will automatically parse and execute them.

[0146] Step S207: The server parses the risk scheduling instructions to obtain risk file information.

[0147] Among them, the risk file information is used to describe the risk information of the software package file in structured data.

[0148] For example, the risk file information may include one or more of the following: the ID of the risk dispatch instruction, the name of the risk software package file, the version range of the risk software package file, the vulnerability risk level, the type of the risk software package file, the vulnerability description, the solution, the source of vulnerability discovery, or the time of vulnerability discovery. However, it is not limited thereto, and the embodiments of this application do not specifically limit it.

[0149] Specifically, after obtaining the risk document information, the server can use the natural language understanding capabilities of the large model to parse the name, description, and attachments of the risk scheduling instructions, extract and transform them into structured data, and finally obtain the risk document information. Attachments can include files in formats such as Excel, PDF, Word, and PNG.

[0150] Step S208: Manage the software package files based on the risk file information and the application status of the software package files.

[0151] Specifically, based on the risk file information obtained from parsing the risk scheduling instructions, the risk file information is compared with the software package file to determine whether the software package file meets the risk file information.

[0152] In some embodiments, based on risk file information and the application status of software package files, the server automatically generates threat intelligence impact analysis work orders according to the instruction dimension, and assigns the work orders to the security vulnerability operations team to manage the software package files. The vulnerability operations team then formulates corresponding vulnerability remediation plans for software package files under different application statuses based on the instruction details in the work order.

[0153] Here, collision can be understood as using the natural language understanding capabilities of a large model to automatically compare risk document information with software package files.

[0154] The command dimension can be understood as an organizational method for conducting threat intelligence impact analysis based on risk dispatch commands as the basic unit.

[0155] In one possible implementation, if the application status of a software package file that meets the risk document information is that it has been uploaded to the software repository but has not been distributed, the software package file that meets the risk document information will be removed from the software repository.

[0156] In the case of a software package file whose application status is "already listed in the software repository but not distributed", it means that the software package file exists in the software repository but has not been deployed to any host. The risk has not spread, and the software package file should be removed from the software repository in a timely manner to avoid distribution and use.

[0157] Specifically, when a risky software package file is uploaded to the software repository but not distributed, the software package file is removed from the repository, and a notification is automatically sent to the applicant for access to the software package file, stating that the software package file has been removed due to a security vulnerability.

[0158] In another possible implementation, an alarm message is displayed if the application status of a software package file that meets the risk file information is that it has been distributed from the software repository to the host but has not been installed on the host.

[0159] The alarm information is used to indicate that the software package file has a risk and its use should be suspended.

[0160] Optionally, the alert information may include an alert title, the name and version information of the at-risk software package, the risk type, the risk level, and a risk description. The risk level can be categorized into different levels such as severe, high-risk, and medium-risk. The risk type can be categorized into different types such as security vulnerabilities, malware, license non-compliance, and supply chain contamination. For example, the alert title could be: "[High-risk] The software package to be installed contains a known security vulnerability." The risk description could be: "This version of nginx has a remote denial-of-service vulnerability, which could cause the service to crash if attacked."

[0161] In another possible implementation, if the application status of the software package file that meets the risk document information is that it has been installed on the host, the software package file on the host is rectified.

[0162] Optionally, rectification measures include, but are not limited to, forcibly uninstalling risky software packages, automatically updating software packages, and downloading application patch files.

[0163] Specifically, if the application status of the software package file that meets the risk document information is "already installed on the host", then contact the person in charge of the host to immediately carry out vulnerability remediation.

[0164] In summary, the solution provided in this embodiment offers a software package management method. By performing software package access detection on the software package files and obtaining the detection results, the software package files that pass the access detection are uploaded to the software library based on the detection results. This achieves security detection of software package files before they enter the software library, ensuring the security of software package files uploaded to the software library and effectively preventing malicious code, viruses, or software package files with security vulnerabilities from entering the software library, thus protecting the security of the software library from the source.

[0165] Furthermore, software packages are distributed according to their application scope, and all distribution activities are logged to ensure traceability. This method effectively controls the secondary distribution and deployment of software packages among internal hosts. It allows security teams to accurately determine the complete propagation chain—"who, when, how, and where"—after a security incident, enabling rapid isolation of affected hosts, reducing the spread of security risks, and improving the timeliness of security incident investigation, root cause analysis, and subsequent containment efforts.

[0166] When a software package version is found to have a high-risk vulnerability, all affected hosts can be accurately located within minutes, enabling rapid and precise strikes and isolation, minimizing the scope of risk impact, and enhancing the resilience of overall security defense.

[0167] Furthermore, by parsing risk scheduling instructions, risk file information is obtained. Then, based on this risk file information and the application status of the software package files, the software package files are managed. This method enables the discovery and control of risky software package files. Additionally, by considering the propagation path of the software package files, affected hosts can be quickly isolated, reducing the spread of security risks.

[0168] Furthermore, the above embodiments have described the steps of the software package management method provided in this application from the perspective of specific method steps. The software package management method provided in this application will be described below with reference to specific examples.

[0169] For example, Figure 7 This is a flowchart illustrating another software package management method provided in an embodiment of this application. The method is executed by a computer device.

[0170] Step S301: Business personnel upload the files to be uploaded to the server.

[0171] Specifically, business personnel can download the software file to be uploaded from the software package download source, and then use a file transfer tool to upload the file to the security detection server.

[0172] Step S302: The server identifies and verifies the file extension of the file to be uploaded.

[0173] Step S303: The server identifies and verifies the header code of the file to be uploaded.

[0174] Step S304: Determine whether the file type of the file to be uploaded is a software package type.

[0175] Specifically, the file type of the file to be uploaded is determined by combining the file extension and header code, to determine whether the file type is a software package. If the file type is a software package, then step S305 is executed; otherwise, step S308 is executed.

[0176] Step S305: Obtain the package file and calculate the hash value of the package file.

[0177] The hash value is a fixed-length string (usually in hexadecimal representation) generated by a hash function, used to uniquely identify the original input data.

[0178] Specifically, after obtaining the software package file, the hash value of the software package file is calculated, and it is checked whether there is already a record of a software package file with the same hash value in the software library. If so, the user is prompted that the software library already contains the software package file to avoid duplicate storage.

[0179] Step S306: Digitally sign the hash value of the software package file.

[0180] Digital signatures are electronic signatures based on cryptographic technology used to verify the authenticity, integrity, and non-repudiation of digital information.

[0181] Specifically, the server uses its private key to digitally sign the hash value of the software package file, and the recipient uses the public key to verify the software package file after receiving it. This can achieve source authentication of the software package file and ensure the integrity of the software package file.

[0182] Step S307: Perform package access detection on the package file.

[0183] By performing software package access checks on software package files, mandatory security audits can be implemented to ensure the security of software package files entering the software repository from the source.

[0184] Step S308: Identify sensitive data in the file to be uploaded.

[0185] Sensitive data refers to information that is prohibited from dissemination by laws and regulations, falls under internal confidentiality requirements of enterprises / organizations, involves personal privacy information, and may pose security or compliance risks. Examples include unpublished internal company information, statements or descriptions that violate laws and regulations, etc.

[0186] Step S309: Determine whether the file to be uploaded contains sensitive data.

[0187] For files to be uploaded that are not software packages, perform sensitive data identification. If the file to be uploaded contains sensitive data, proceed to step S310; otherwise, proceed to step S311.

[0188] Step S310: Intercept the upload request for the file to be uploaded.

[0189] Step S311: Execute the upload process for the file to be uploaded.

[0190] For example, Figure 8 This is a flowchart illustrating another software package management method provided in an embodiment of this application. The method is executed by a server.

[0191] Step S401: Business personnel fill in the basic information, classification information, and tenant information of the software package file.

[0192] Step S402: Business personnel submit software package file access application.

[0193] Step S403: Perform sandbox testing on the software package files.

[0194] Step S404: Determine whether the sandbox test has passed.

[0195] If the sandbox test passes, proceed to step S405; otherwise, proceed to step S412.

[0196] Step S405: Match the package file with the risk packages in the historical risk software repository.

[0197] Step S406: Determine whether the software package file matches the risky software packages in the historical risky software repository.

[0198] If the software package file is not a risky software package in the historical risky software repository, proceed to step S407; otherwise, proceed to step S412.

[0199] Step S407: Perform package component analysis on the package file.

[0200] Step S408: Multi-level business personnel approve the software package file access application through a work order.

[0201] The specific process for multi-level business personnel to approve software package file access applications is as follows: Figure 9 As shown.

[0202] For example, after the software package file passes the software package access detection, it is submitted to the security interface person of the department to which the business personnel belong for approval. If the department security interface person approves, it is submitted to the business personnel's direct supervisor for approval. If the direct supervisor approves, it is submitted to the operations personnel of the software supply chain operations team for approval. If the operations team approves, the software package file is officially put on the software repository and transferred to the designated directory of the file server. At the same time, an approval message is sent to the relevant business personnel. If any level of approval fails, an approval failure message is sent to the relevant business personnel.

[0203] Step S409: Determine whether the approval is successful.

[0204] If the approval is granted, proceed to step S410; otherwise, proceed to step S412.

[0205] Step S410: Upload the software package file to the application scope of the corresponding software package file in the software library.

[0206] Step S411: Move the package file to the specified software library directory.

[0207] Step S412: Send the access approval result to the business personnel.

[0208] For example, Figure 10 This is a flowchart illustrating another software package management method provided in an embodiment of this application. The method is executed by a server.

[0209] Step S501: Business personnel log in to the artifact center and obtain the list of software package files for the current tenant based on the tenant scope of the currently logged-in user.

[0210] Step S502: Based on the currently logged-in user information, determine all target hosts for which the user is authorized to perform distribution operations.

[0211] Step S503: Business personnel select the software package file and determine the distribution host account information and the specified storage directory of the target host.

[0212] Step S504: The system executes asynchronous task distribution.

[0213] Step S505: The system displays the distribution progress.

[0214] Step S506: After the distribution is completed, the system sends a notification to the business personnel that the distribution operation is complete.

[0215] For example, Figure 11This is a flowchart illustrating another software package management method provided in an embodiment of this application. The method is executed by a server.

[0216] Step S601: Perform incremental parsing on the risk scheduling instructions to obtain risk file information.

[0217] Incremental parsing refers to parsing only the parts of the data / content that have changed, rather than re-parsing the entire content.

[0218] Specifically, the risk scheduling instructions are incrementally parsed to obtain risk file information, and then steps S602 and S604 are executed respectively.

[0219] Step S602: Compare the risk file information with the software package file information in the software library.

[0220] For example, by leveraging the natural language understanding capabilities of large models, the problematic components and their version ranges in the risk document information are compared with the names and versions of the listed software packages to determine whether there are any cases where the names and versions of the listed software packages match the names and versions of the risky software packages, thereby verifying whether the listed software packages are affected by known threat intelligence.

[0221] Step S603: Obtain the distribution records and host account information of the risky software package files in the software library.

[0222] Step S604: Compare the risk file information with the software package file information already installed on the host.

[0223] Specifically, the EDR (Endpoint Detection and Response) system collects a list of software packages from all hosts on the network. This list includes application software, web frameworks, and web applications. A large-scale model is used to parse the risky file information, extracting the names of vulnerable software packages and their corresponding precise versions. The extracted list of vulnerable software packages and versions is then matched against the overall list of software packages on all hosts on the network to generate a list of hosts with the vulnerable software packages installed, enabling precise risk identification and emergency response.

[0224] Step S605: Determine the host and host account information for the installed risky software package file.

[0225] Step S606: Generate a threat intelligence impact matrix ledger.

[0226] The threat intelligence impact matrix can be understood as a structured risk summary table that integrates vulnerabilities, host ownership, risk file information, and remediation information.

[0227] A ledger is a detailed record sheet that records information such as income, expenditure, changes, and status of a certain task or asset.

[0228] The threat intelligence impact matrix can include: software name, software version, vulnerability discovery time, scope of impact (department, system, system owner, host IP, impact type, remediation status), threat intelligence information (dispatch instruction details, threat intelligence details), and remediation plan.

[0229] Specifically, by integrating the distribution records and host account information of risky software packages in the software repository with the host and host account information of the installed risky software packages, and summarizing and deduplicating the results, and linking them with the host ownership information in the CMDB (Configuration Management Database), such as department, system, and system owner, a unified threat intelligence impact matrix is ​​finally formed. Based on the threat intelligence impact matrix, a threat intelligence impact analysis work order is then generated.

[0230] Step S607: Issue a threat intelligence impact analysis work order to the vulnerability operations team.

[0231] The threat intelligence impact analysis work order can include detailed information such as the instruction order number, instruction title, instruction description, business scenario, instruction type, instruction level, work order type, instruction status, creator, creation department, creation time, issuing personnel, issuing time, and instruction attachments. It can also include details of the hosts to which the vulnerability software package file has been distributed or installed, and information on software package files that have been uploaded to the software repository.

[0232] Step S608: After the vulnerability operation team fills in the remediation plan and submits the work order, the vulnerability remediation work order is issued to the corresponding person in charge.

[0233] The vulnerability remediation work order can include detailed information such as instruction number, instruction title, instruction description, business scenario, instruction type, instruction level, work order type, instruction status, creator, creation department, creation time, issuing personnel, issuing time, and instruction attachments. It can also include information on the scope of impact of software package file vulnerabilities, such as software name, software version, host IP, host user, responsible person, department name, project team, and vulnerability details. The vulnerability details include basic vulnerability information, vulnerability summary, and solution.

[0234] Specifically, the server will group relevant records according to the system administrator, generate vulnerability remediation work orders, and distribute them to the corresponding administrators. Upon receiving a vulnerability remediation work order, the system administrator must perform the corresponding operations according to the remediation plan and submit the work order upon completion, thus achieving closed-loop management of the entire vulnerability remediation process. Furthermore, it will be integrated with the security incident handling system to focus on monitoring hosts with installed risky software packages. Once a security incident occurs, a high-level alarm will be triggered, and the incident's handling priority will be increased. The security incident handling system can be understood as a system within the enterprise security architecture specifically designed to handle various network security incidents.

[0235] Based on the impact matrix, vulnerability remediation work orders are automatically generated and linked to the security incident monitoring system to achieve closed-loop management of vulnerability removal, notification distribution, and host repair. A fully automated vulnerability handling pipeline has been established, from command parsing and impact scope analysis to work order generation and follow-up, all without manual intervention. This reduces security threat response time from "days" to "minutes," effectively improving the efficiency of security operations and vulnerability remediation. By providing complete threat intelligence impact analysis work orders and vulnerability remediation work orders, and tracking threat intelligence impact records from discovery to remediation closure, all remediation statuses are clearly visible, completely eliminating traditional manual operation modes and fundamentally improving work experience and efficiency.

[0236] Further, perform step S609 or step S610.

[0237] Step S609: The person in charge shall perform the corresponding operations according to the rectification plan.

[0238] For example, when the risk of a software package can be eliminated through repair, configuration adjustment, or other means, the relevant person in charge shall perform the corresponding operations to repair the vulnerability according to the rectification plan.

[0239] Compared to existing technologies, the discovery and handling of threat intelligence involves a series of inefficient steps, including manual intervention, analysis, and offline communication, taking hours or days and lacking transparency. When a vulnerability is found in a software package file or common component, security teams struggle to quickly and accurately locate affected hosts, leading to significant delays in vulnerability remediation and increasing the time enterprises are exposed to security risks. This application automatically generates threat intelligence impact analysis work orders based on the threat intelligence impact matrix and assigns them to the security vulnerability operations team. The vulnerability operations team then develops corresponding vulnerability remediation plans for each type of affected software based on the instructions in the work order, greatly shortening the vulnerability remediation time and the time enterprises are exposed to security risks.

[0240] Step S610: Remove the risky software package file.

[0241] Among them, risky software package files refer to software package files that are at risk.

[0242] For example, when a software package file poses a risk that cannot be eliminated through remediation, or when the risk is so high that it must be completely removed, the software repository will remove the software package file.

[0243] Step S611: Send a notification to the seller that the software package file has been removed from the platform.

[0244] The foregoing mainly describes the solution provided in this application. Accordingly, this application also provides a software package management device for implementing the above-described method embodiments.

[0245] like Figure 12 The schematic diagram shown illustrates the structure of a software package management device, which may include an acquisition module 701 and a processing module 702. The acquisition module 701 is used to execute... Figure 2 The illustrated method includes step S201; the processing module 702 is used to execute... Figure 2 The operations of steps S202 and S203 in the middle and Figure 4 The operations in steps S204, S205, S206, S207, and S208.

[0246] In some embodiments, the software package management device includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0247] This application embodiment can divide the software package management device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0248] like Figure 13As shown, the computer device provided in this application embodiment may include a processor 801, a bus 802, a communication interface 803, and a memory 804. The processor 801, memory 804, and communication interface 803 communicate with each other via the bus 802. It should be understood that this application does not limit the number of processors and memories in the computer device.

[0249] The 802 bus can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 13 The bus 802 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 802 may include a path for transmitting information between various components of a computer device (e.g., memory 804, processor 801, communication interface 803).

[0250] Processor 801 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0251] The memory 804 may include volatile memory, such as random access memory (RAM). The processor 801 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0252] The communication interface 803 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between computer devices and other devices or communication networks.

[0253] The memory 804 stores executable program code, and the processor 801 executes the executable program code to implement the functions of the aforementioned method embodiments. That is, the memory 804 stores instructions for executing the above-described software package management method.

[0254] In another aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the software package management method provided in the above-described method embodiments.

[0255] On the other hand, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the software package management method described above is implemented.

[0256] Through the above description of the implementation methods, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the module can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, modules, and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0257] Since the software package management device, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above methods, the technical effects obtained can also be referred to the above method embodiments. The embodiments of the present invention will not be repeated here.

[0258] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. One exemplary embodiment couples a storage medium to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a network device. Of course, the processor and storage medium can also exist as discrete components in the network device.

[0259] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the processes or functions of the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD). The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A software package management method, characterized in that, The method includes: Get the package file; The software package file is subjected to software package access detection to obtain the detection result of the software package file. The software package access detection is used to indicate the security detection of the software package file. Based on the detection results, the software package files that pass the software package access detection will be uploaded to the software library.

2. The method according to claim 1, characterized in that, The software package access detection performed on the software package file includes one or more of the following: The software package file is subjected to sandbox testing, wherein the sandbox testing is used to indicate that the software package file is tested in an isolated network environment; or, The software package file is matched with risky software packages in a historical risk software library, wherein the historical risk information matching is used to indicate a match in the historical risk software library based on the name and / or version number of the software package file; or, The software package file is subjected to software package component analysis, wherein the software package component analysis is used to indicate the analysis of open source components and / or security vulnerabilities in the software package file.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the application scope of the software package files uploaded to the software library; The software package file is distributed based on its application scope.

4. The method according to claim 3, characterized in that, The distribution of the software package file based on its application scope includes: Based on the application scope of the software package file, host account information within the application scope is determined, and the host account information is used to indicate the account information of the host within the authorization scope of the software package file; The software package file is distributed to the host corresponding to the host account information.

5. The method according to any one of claims 1 to 4, characterized in that, The process of obtaining the software package file includes: Get the file to be uploaded; The file to be uploaded is identified to obtain the software package file.

6. The method according to claim 5, characterized in that, The step of performing file recognition on the file to be uploaded to obtain the software package file includes: The file extension and / or header code characteristics of the file to be uploaded are identified and verified to obtain the software package file.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Obtain a risk scheduling instruction, which indicates information about a software package file that is at risk; The risk scheduling instruction is parsed to obtain risk file information, which is used to describe the risk information of the software package file in structured data. The software package files are managed based on the risk file information and the application status of the software package files.

8. The method according to claim 7, characterized in that, The management and control of the software package file based on the risk file information and the application status of the software package file includes: If the application status of a software package file that meets the risk file information is that it has been uploaded to the software repository but has not been distributed, the software package file that meets the risk file information will be removed from the software repository. or, If the application status of a software package file that meets the risk file information is that it has been distributed from the software repository to the host but has not been installed on the host, an alarm message is displayed. The alarm message is used to indicate that the software package file has a risk and its use should be suspended. or, If the application status of the software package file that meets the risk file information is that it has been installed on the host, the software package file on the host shall be rectified.

9. The method according to claim 7, characterized in that, The risk file information includes one or more of the following: the ID of the risk scheduling instruction, the name of the risk package file, the version range of the risk package file, the vulnerability risk level, the type of the risk package file, the vulnerability description, the solution, the source of vulnerability discovery, or the time of vulnerability discovery.

10. A software package management device, characterized in that, The device includes: The get module is used to retrieve package files; The processing module is used to perform software package access detection on the software package file and obtain the detection result of the software package file. The software package access detection is used to indicate that the security of the software package file should be detected. The processing module is also used to upload the software package file to the software library based on the detection results.

11. A computer device, characterized in that, The computer device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the software package management method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the software package management method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a processor, implement the software package management method as described in any one of claims 1 to 9.

Images