A Security Policy-Based Method and System for Scanning Laptop Software Vulnerabilities

Abstract

This application relates to a security policy-based method for scanning software vulnerabilities in laptops. The method first obtains the security policy library of the target laptop, which contains access control rules, data operation restrictions, and vulnerability detection benchmark requirements for different software types. Next, it collects software runtime data from the target laptop, including current running process information, file system operation records, network connection status, and software configuration parameters. Then, it matches and analyzes the software runtime data against the security policy library to generate preliminary scan results. Next, it assesses the risk level of the software vulnerabilities based on the preliminary scan results. Finally, based on the risk level and the remediation guidelines in the security policy library, it generates software vulnerability remediation guidance information. This approach enables comprehensive and accurate scanning of laptop software vulnerabilities and provides effective remediation guidance.

Description

Technical Field

[0001] This application relates to the field of software security technology, and in particular to a laptop software vulnerability scanning system based on security policies. Background Technology

[0002] In today's rapidly developing information technology landscape, laptops, as highly popular and powerful mobile computing devices, are widely used in various fields such as office work, study, and entertainment. However, with the increasing diversity and complexity of software applications, the security threats facing laptop software are also becoming increasingly severe. Software vulnerabilities can be maliciously exploited, leading to serious consequences such as data breaches, system crashes, and cyberattacks, causing significant losses to users.

[0003] Existing methods for scanning laptop software vulnerabilities have several limitations. Firstly, many traditional scanning methods rely heavily on signature databases of known vulnerabilities, limiting their detection to already recorded vulnerabilities and making them ill-suited for identifying newly emerging, unknown vulnerabilities. This signature-matching approach proves inadequate in the face of constantly evolving attack methods and software security challenges. Secondly, existing scanning methods often lack a comprehensive consideration of software usage scenarios and security strategies. Different types of software, such as office software, development tools, and entertainment applications, have varying security requirements and risk characteristics. However, existing methods typically employ a uniform standard for scanning, failing to provide personalized vulnerability detection and risk assessment based on the specific characteristics and usage environment of the software.

[0004] Furthermore, in vulnerability risk assessment, existing methods mostly focus only on the severity of the vulnerability itself, neglecting factors such as the functional importance of software modules, the potential impact of abnormal operations, and the correlation with historical vulnerabilities. This makes it difficult to allocate resources reasonably when patching vulnerabilities, potentially leading to the neglect of some low-risk vulnerabilities with significant potential impact, while some high-risk vulnerabilities with minor impact on the system consume excessive patching resources.

[0005] Therefore, in order to improve the security of laptop software, a more intelligent and comprehensive vulnerability scanning method is needed, which can combine security strategies to accurately detect vulnerabilities and assess risks in different types of software, and provide effective remediation guidance. Summary of the Invention

[0006] In view of the above, in order to at least partially address the shortcomings of the prior art, in a first aspect, embodiments of this application provide a method for scanning laptop software vulnerabilities based on a security strategy, the method comprising:

[0007] Obtain the security policy library of the target laptop, which contains access control rules, data operation restrictions and vulnerability detection benchmark requirements for different software types;

[0008] Collect software operation data of the target laptop, including current running process information, file system operation records, network connection status and software configuration parameters;

[0009] The software runtime data is matched and analyzed with the security policy library to generate preliminary scan results containing software module identifiers that do not meet the security policy and descriptions of abnormal operation behaviors.

[0010] Based on the functional importance of the software modules, the potential impact of abnormal operations, and the correlation with historical vulnerabilities in the preliminary scan results, assess the risk level of the software vulnerabilities.

[0011] Based on the risk level and the remediation guidelines in the security policy library, generate software vulnerability remediation guidance information that includes remediation operation steps, remediation priority indicators, and verification method descriptions.

[0012] Secondly, embodiments of this application also provide a laptop software vulnerability scanning system based on a security policy, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the laptop software vulnerability scanning method based on the security policy.

[0013] In summary, the laptop software vulnerability scanning method and system based on security policies provided in this application achieve comprehensive and accurate scanning of laptop software vulnerabilities by comprehensively utilizing a security policy library and software operation data for matching analysis. This method can perform personalized vulnerability detection for different types of software based on their specific security needs and risk characteristics, greatly improving the accuracy and effectiveness of vulnerability detection. For example, in vulnerability risk assessment, it fully considers factors such as the functional importance of software modules, the potential impact of abnormal operations, and the correlation with historical vulnerabilities, making the risk assessment results more scientific and reasonable. Through this comprehensive assessment, the priority of vulnerability remediation can be determined more accurately, remediation resources can be allocated reasonably, and remediation efficiency can be improved. Furthermore, based on the risk level and remediation guidelines in the security policy library, detailed software vulnerability remediation guidance information is generated, including remediation operation steps, remediation priority indicators, and verification method descriptions. This provides clear guidance for software vulnerability remediation, making the remediation process more standardized and reliable, further improving the security and stability of laptop software.

[0014] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0015] 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 drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on the above drawings without creative effort.

[0016] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0017] Figure 1 This is a flowchart illustrating a laptop software vulnerability scanning method based on a security strategy, as provided in an embodiment of this application.

[0018] Figure 2 This describes the intended application scenario for the laptop software vulnerability scanning method.

[0019] Figure 3 This is a schematic diagram of a laptop software vulnerability scanning system based on a security strategy, provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0021] Please see Figure 1 and Figure 2 As shown, Figure 1 This is a flowchart illustrating the laptop software vulnerability scanning method based on security policies provided in this application embodiment. Figure 2 This describes the intended application scenario of the laptop software vulnerability scanning method. This scenario includes at least one third-party security service platform and multiple laptops interacting with each other. In this embodiment, the third-party security service platform can be a server, server cluster, or other device with powerful data processing and storage capabilities. The laptops can be portable laptops or other devices with data acquisition and transmission capabilities; this embodiment does not specifically limit their capabilities. Multiple laptops collect their own software runtime data, such as current process information, file system operation records, network connection status, and software configuration parameters, and collaboratively analyze this data with the third-party security service platform to assess software vulnerability risks, generate remediation guidance information, and achieve information exchange and collaborative work between the two, thereby ensuring laptop software security.

[0022] like Figure 1 As shown, the method includes steps S110-S150, which will be described in detail below.

[0023] Step S110: Obtain the security policy library of the target laptop. The security policy library contains access control rules, data operation restrictions, and vulnerability detection benchmark requirements for different software types.

[0024] In this embodiment, the security policy library of the target laptop is obtained as the basis for subsequent vulnerability scanning. The security policy library contains access control rules, data operation restrictions, and vulnerability detection benchmark requirements for different software types. These rules and requirements help determine whether the software operation complies with security standards. In one possible example scenario of this embodiment, assume the target laptop is an office laptop used by an employee of a company, and various office software, development tools, and entertainment applications are installed on it. To ensure the software security of the laptop, it is necessary to obtain the corresponding security policy library.

[0025] Step S110 may include the following steps S111-S115, which are described in detail below.

[0026] Step S111: Extract the preset basic security policy from the target laptop's system security configuration file. The basic security policy includes general access control rules at the operating system level and default data operation restrictions.

[0027] In this embodiment, basic security policies are extracted from the target laptop's system security configuration file. These basic security policies can be pre-set by the operating system and include general access control rules and default data operation restrictions. As an example, the basic security policies can be extracted by reading the target laptop's system security configuration file. For instance, the operating system may stipulate that all software must be authorized to access critical system files and prohibit software from arbitrarily modifying the system registry. These rules constitute part of the basic security policy.

[0028] Step S112: Synchronize and update industry-specific security policies from a third-party security service platform. These industry-specific security policies include software type-specific access control rules and enhanced data operation restrictions related to the target laptop's usage scenario.

[0029] In this embodiment, an industry-specific security policy is synchronously updated from a third-party security service platform. This policy is tailored to the target laptop's usage scenario and software type, offering greater targeting and security. Step S112 can be implemented through the following sub-steps S1121-S1125, as described in detail below.

[0030] Step S1121: Obtain the usage scenario tags of the target laptop. The usage scenario tags are determined by analyzing the frequency of use and functional focus of office software, development tools, and entertainment applications in historical software usage records.

[0031] In this embodiment, the usage scenario tags of the target laptop are determined by analyzing its historical software usage records. These tags reflect the primary work or entertainment uses of the target laptop. For example, analysis of the laptop's historical software usage records reveals that office software is used frequently, mainly for document processing and data analysis; development tools are also used to some extent for coding and project development; and entertainment applications are used relatively infrequently. Based on these analysis results, the laptop's usage scenario tag is determined to be "primarily for office and development."

[0032] Step S1122: Send a policy synchronization request to a third-party security service platform based on the usage scenario tag. The policy synchronization request includes the target laptop's operating system version, software installation list, and industry affiliation information.

[0033] In this embodiment, a policy synchronization request is sent to a third-party security service platform based on the determined usage scenario label. The request includes the target laptop's operating system version, software installation list, and industry affiliation information, so that the third-party security service platform can provide industry-specific security policies that meet the laptop's requirements.

[0034] As an example, based on the aforementioned example, a policy synchronization request was sent to a third-party security service platform according to the usage scenario tag of "primarily for office and development". The request can list in detail the target laptop's operating system version (such as Windows 10), software installation list (such as Microsoft Office, Visual Studio, etc.), and industry (such as information technology industry).

[0035] Step S1123: Receive industry-specific security policy data packets returned by a third-party security service platform. The data packets include enhanced access control rules for office software, enhanced data operation restrictions for development tools, and enhanced vulnerability detection benchmark requirements for entertainment applications.

[0036] In this embodiment, the industry-specific security policy data packet returned by the third-party security service platform contains enhanced security policies for different software types. For example, the third-party security service platform returns an industry-specific security policy data packet upon request. For office software, the data packet includes enhanced access control rules, such as restricting office software to accessing only the company's internal file server; for development tools, it includes enhanced data operation restrictions, such as prohibiting development tools from performing file operations outside the project directory; and for entertainment applications, it includes enhanced vulnerability detection benchmark requirements, such as requiring entertainment applications to use encrypted protocols for network connections.

[0037] Step S1124: Perform integrity verification on the industry-specific security policy data packet, and verify whether the digital signature and hash value of the data packet are consistent with the verification information provided by the third-party security service platform.

[0038] In this embodiment, the received industry-specific security policy data packets are subjected to integrity verification to ensure that the data packets have not been tampered with during transmission. The integrity of the data packets is determined by verifying whether the digital signature and hash value of the data packets are consistent with the verification information provided by the third-party security service platform.

[0039] As an example, in the process of verifying the integrity of industry-specific security policy data packets, one can first verify the digital signature of the data packet to ensure that it originates from a trusted third-party security service platform. Then, the hash value of the data packet is calculated and compared with the hash value provided by the third-party security service platform. If they match, the data packet is considered intact.

[0040] Step S1125: Parse the verified industry-specific security policy data packet, and extract the software type-specific access control rules and enhanced data operation restrictions that match the target laptop's usage scenario tags as the industry-specific security policy.

[0041] In this embodiment, the verified industry-specific security policy data packet is parsed to extract software type-specific access control rules and enhanced data operation restrictions that match the target laptop's usage scenario tags, which are then used as the final industry-specific security policy.

[0042] As an example, we parse the validated industry-specific security policy data packets. For instance, based on the usage scenario tag "primarily for office and development," we extract specific access control rules and enhanced data operation restrictions for office software and development tools. For example, we extract rules that allow office software to access the company's internal file server, and restrictions that prohibit file operations on development tools outside the project directory.

[0043] Step S113: Perform version verification on the basic security policy and the industry-specific security policy, identify policy clauses with version conflicts, and mark them as items to be verified.

[0044] In this embodiment, version verification can be performed on basic security policies and industry-specific security policies to identify policy clauses with version conflicts and mark them as items to be verified.

[0045] In one possible example of this embodiment, version verification is performed between the basic security policy extracted from the system security configuration file and the industry-specific security policy synchronized from a third-party security service platform. During the verification process, if conflicts are found between the access permission provisions for certain system files in the basic security policy and those in the industry-specific security policy, the conflicting policy clauses can be marked as items to be verified for subsequent processing.

[0046] Step S114: Categorize and consolidate the policy clauses that are not marked as conflicting, dividing them into office software policy groups, development tool policy groups, and entertainment application policy groups according to software type. Each policy group includes access control rules, data operation restrictions, and vulnerability detection benchmark requirements for the corresponding software type.

[0047] In this embodiment, unmarked conflict policy clauses are categorized and integrated, divided into different policy groups according to software type. Each policy group contains access control rules, data operation restrictions, and vulnerability detection benchmark requirements for the corresponding software type. For example, unmarked conflict policy clauses are categorized and integrated as follows: Policy clauses involving office software are integrated into the office software policy group, which includes access control rules (e.g., access to the company's internal file server is restricted), data operation restrictions (e.g., unauthorized modification of important documents is prohibited), and vulnerability detection benchmark requirements (e.g., regular checks for software updates); Policy clauses involving development tools are integrated into the development tool policy group, which includes access control rules (e.g., access to the project directory is restricted), data operation restrictions (e.g., file operations outside the project directory are prohibited), and vulnerability detection benchmark requirements (e.g., checking the security of the code repository); Policy clauses involving entertainment applications are integrated into the entertainment application policy group, which includes access control rules (e.g., connection to the official server is restricted), data operation restrictions (e.g., access to sensitive system information is prohibited), and vulnerability detection benchmark requirements (e.g., checking the encryption of network connections).

[0048] Step S115: Manually review the policy clauses marked as conflicting, retain the high-priority policy clauses based on the actual usage needs of the target laptop, and generate the final security policy library.

[0049] In this embodiment, conflicting policy clauses are manually reviewed. Based on the actual usage needs of the target laptop, high-priority policy clauses are retained, ultimately generating a complete security policy library. For example, in one possible example of this embodiment, conflicting policy clauses are manually reviewed. Considering that the target laptop is mainly used for office and development work, and the enterprise has high requirements for data security, it is decided to retain the provisions on system file access permissions from industry-specific security policies, as these provisions better meet the enterprise's security needs. After manual review and screening, all valid policy clauses are integrated to generate the final security policy library.

[0050] Step S120: Collect software running data of the target laptop, including current running process information, file system operation records, network connection status and software configuration parameters.

[0051] In this embodiment, software runtime data of the target laptop is collected, which is an important input for subsequent vulnerability scanning. Software runtime data includes current running process information, file system operation records, network connection status, and software configuration parameters. Analysis of this data allows for understanding the software's runtime status and behavior. For example, as a case study, we continue to collect software runtime data from an office laptop used by an employee of a company.

[0052] Step S120 may include the following sub-steps S121-S125, which are described in detail below.

[0053] Step S121: Obtain a list of all currently running software processes through the system process monitoring interface, and record the name, start time, parent process identifier, and system resource usage of each process as the information of the currently running process.

[0054] In this embodiment, a list of all currently running software processes on the target laptop is obtained through the system process monitoring interface, and relevant information for each process is recorded, including process name, start time, parent process ID, and system resource usage. For example, as an example, the system process monitoring interface is used to obtain a list of all currently running software processes. For instance, the Microsoft Word process is recorded as "WINWORD.EXE", with a start time of 9:30 AM, a parent process ID of explorer.exe, CPU usage of 5%, and memory usage of 100MB. Similarly, other running software processes are also recorded in detail.

[0055] Step S122: Traverse the specified directory path of the file system and record the timestamps, operation types, and target file paths of file operations performed by the software module on system files and user data files as file system operation records; the file operations include at least one of read operations, write operations, and delete operations.

[0056] In this embodiment, a specified directory path in the file system is traversed to record file operation information of the software module on system files and user data files, including the timestamp of the operation, the operation type, and the target file path. As an example, a specified directory path in the file system is traversed, such as the "Program Files" and "Users" directories on drive C. It is recorded that an office software program read the user data file "document.docx" at 10:15 AM; and a development tool wrote to the system file "system.dll" at 2:30 PM.

[0057] Step S123: Monitor the data flow transmission status of the network interface and record the target IP address, port number, transmission protocol type, and data traffic size of the network connection established by the software module as the network connection status.

[0058] In this embodiment, the data flow transmission status of the network interface is monitored, and the relevant information of the network connection established by the software module is recorded. This can be achieved through the following sub-steps S1231-S1236, which are described in detail below.

[0059] Step S1231: Enable the network traffic monitoring driver to capture data packets from all network interfaces of the target laptop.

[0060] In this embodiment, a network traffic monitoring driver is enabled to capture data packets from all network interfaces of the target laptop. For example, a suitable network traffic monitoring driver needs to be selected first. Different operating systems support different types of drivers, so the selection must be based on the operating system used by the target laptop. For example, if the target laptop is using a Windows operating system, an open-source network packet capture driver such as WinPcap or Npcap can be selected; if it is using a Linux operating system, the libpcap driver can be selected.

[0061] Step S1232: Perform protocol parsing on the captured data packets to extract the source process identifier, target IP address, target port number, transport protocol type, and data packet size.

[0062] In this embodiment, the captured data packets are parsed to extract key information such as the source process identifier, target IP address, target port number, transport protocol type, and data packet size. For example, the parsed data packet may have a source process identifier of "WINWORD.EXE", a target IP address of "192.168.1.100", a target port number of "80", a transport protocol type of "HTTP", and a data packet size of 1024 bytes.

[0063] Step S1233: Associate the source process identifier with the corresponding software module and establish a mapping relationship between the software module and the network connection.

[0064] In this embodiment, for example, the data packet can be associated with the Microsoft Word software module based on the source process identifier "WINWORD.EXE". This establishes a mapping relationship between the software module and the network connection, facilitating subsequent analysis of the software's network behavior.

[0065] Step S1234: Aggregate network connections established by the same software module within a preset time window, and count the number of connections, total data traffic, and average connection duration for each target IP address.

[0066] In this embodiment, as an example, a preset time window of 1 hour is used. Network connections established by the Microsoft Word software module within this 1-hour period are aggregated. Statistics show that the software module connected to the target IP address "192.168.1.100" 10 times, with a total data traffic of 10KB and an average connection duration of 5 seconds.

[0067] Step S1235: Filter out network connections related to system services and retain only network connection information initiated by user-installed software modules.

[0068] In this embodiment, network connections related to system services are filtered out, and only network connection information initiated by user-installed software modules is retained, in order to more accurately analyze the network behavior of user software. For example, network connections related to system services (such as the Windows Update service) can be filtered out. Only network connection information initiated by software modules such as office software, development tools, and entertainment applications installed by the user is retained.

[0069] Step S1236: Organize the target IP address, port number, transmission protocol type and data traffic size from the retained network connection information into a network connection status record.

[0070] In this embodiment, the retained network connection information is organized to form a network connection status record.

[0071] As an example, the target IP address, port number, transport protocol type, and data traffic size from the retained network connection information are organized. For instance, the network connection status record between the Microsoft Word software module and the target IP address "192.168.1.100" is organized, including the port number "80", the transport protocol type "HTTP", and the data traffic size of 10KB.

[0072] Step S124: Read the configuration file and registry entries of the software module, and extract the software's function activation status, permission setting parameters, data storage path, and third-party service integration information as software configuration parameters.

[0073] In this embodiment, the configuration files and registry entries of the software module are read to extract relevant configuration parameters, including feature activation status, permission settings, data storage paths, and third-party service integration information. As an example, the configuration files and registry entries of a certain office software are read. The feature activation status of the software, such as whether the auto-save function is enabled, is extracted from the configuration file; permission settings, such as whether there is permission to modify system files, are extracted from the registry entries; the data storage path, such as the default document save path, is also obtained; and third-party service integration information, such as whether cloud storage services are integrated, is also obtained. This information is organized into software configuration parameters for subsequent vulnerability scanning and analysis.

[0074] Step S125: Timestamp align the current running process information, the file system operation record, the network connection status, and the software configuration parameters to generate software running data with time-series correlation.

[0075] In this embodiment, the previously collected information on the current running process, file system operation records, network connection status, and software configuration parameters are aligned according to timestamps, so that the data has a temporal correlation and forms complete software running data.

[0076] As an example, data from different data sources can be aligned using timestamps as a benchmark. For instance, for a specific point in time, software process information, file operation records, network connection status, and software configuration parameters corresponding to that time point can be correlated. If at 10:30 AM, an office software process is running, performs a file read operation, and establishes a network connection with a specific IP address, this information can be integrated chronologically to form software operation data with temporal correlations. This allows for a more comprehensive and accurate understanding of the software's operational status and behavior at different points in time.

[0077] Step S130: Match and analyze the software runtime data with the security policy library to generate preliminary scan results containing identifiers of software modules that do not meet security policies and descriptions of abnormal operation behaviors.

[0078] In this embodiment, the collected software runtime data is matched and analyzed against a security policy database to identify software modules and abnormal operational behaviors that do not meet security policies, and preliminary scan results are generated. As an example, continuing with an employee's office laptop, the previously generated software runtime data is matched and analyzed in detail against the security policy database.

[0079] Step S130 may include the following sub-steps S131-S135, which are described in detail below.

[0080] Step S131: Extract access control rules for office software policy groups from the security policy library, check whether the parent process identifier of the office software process meets the preset trusted process chain requirements, and record the identifiers of non-compliant office software modules and their parent process violation information.

[0081] In this embodiment, access control rules are extracted from the office software policy group in the security policy library, with a focus on checking whether the parent process identifier of the office software process meets the preset trusted process chain requirements.

[0082] As an example, the Office Software Policy Group stipulates that the parent process of office software must be a trusted system process. For instance, the parent process of Microsoft Word should normally be explorer.exe. During the inspection, it was found that the parent process of a certain Microsoft Word process was identified as an unknown process, which did not meet the preset trusted process chain requirements. The office software module was identified as "WINWORD.EXE", and the parent process violation information was recorded as "The parent process is identified as an unknown process, which does not meet the trusted process chain requirements".

[0083] Step S132: Based on the data operation restrictions of the development tool policy group, check whether the development tool's write operations on system files are only for allowed temporary directory paths, and record the development tool module identifier and file path violation information for performing write operations in non-allowed directories.

[0084] In this embodiment, the data operation restrictions of the development tools policy group in the security policy library are used to verify whether the development tools' write operations on system files comply with the regulations. As an example, the development tools policy group stipulates that development tools can only perform write operations on system files in allowed temporary directory paths. For example, a development tool like Visual Studio is allowed to perform file write operations in a specific project temporary directory. During the verification process, it was found that the development tool performed write operations in a non-allowed critical system directory. The development tool module identifier was recorded as "devenv.exe", and the file path violation information was "Performed write operations in a non-allowed critical system directory (such as C:\Windows\System32)".

[0085] Step S133: Based on the network connection restrictions of the entertainment application policy group, verify whether the target IP address of the network connection established by the entertainment application is within the whitelist range, and record the identification of the entertainment application module and the violation information of the IP address that connects to a non-whitelisted IP address.

[0086] In this embodiment, based on the network connection restrictions of the entertainment application policy group in the security policy library, it is verified whether the target IP address of the network connection established by the entertainment application is within the whitelist. As an example, the entertainment application policy group stipulates that entertainment applications can only connect to IP addresses within the whitelist. For example, the whitelisted IP address that a certain entertainment application, game A, is allowed to connect to is the IP address of the game's official server. During the verification process, it was found that the entertainment application established a network connection with a non-whitelisted IP address. The entertainment application module identifier is recorded as "gameA.exe", and the IP address violation information is "connected to a non-whitelisted IP address (such as 192.168.1.200)".

[0087] Step S134: Extract the vulnerability detection benchmark requirements of each policy group in the security policy library, compare the permission settings in the software configuration parameters to see if they meet the minimum permission level of the benchmark requirements, and record the software module identifiers and permission parameter violation information that exceed the permission settings.

[0088] In this embodiment, vulnerability detection benchmark requirements are extracted from each policy group in the security policy library, and the permission settings in the software configuration parameters are compared with them to identify software modules with excessive permission settings. This can be achieved through the following sub-steps S1341-S1346, which are explained in detail below.

[0089] Step S1341: Extract the minimum permission level requirements of the office software from the office software policy group. The minimum permission level requirements include allowing only reading of the user document directory, prohibiting writing to critical system directories, and allowing only connection to the enterprise internal network.

[0090] In this embodiment, the minimum permission level requirements for office software are extracted from the office software policy group. As an example, the office software policy group specifies that the minimum permission level requirements for office software include only allowing reading of the user's document directory, such as "C:\Users\username\Documents"; prohibiting writing to critical system directories, such as "C:\Windows"; and only allowing connection to the corporate internal network, such as the IP address range 192.168.1.0-192.168.1.255.

[0091] Step S1342: Extract the minimum permission level requirements for the development tools from the development tool policy group. The minimum permission level requirements include allowing only access to the project working directory, prohibiting direct modification of the system registry, and allowing only connection to the specified IP of the code hosting platform.

[0092] In this embodiment, the minimum permission level requirements for development tools are extracted from the development tool policy group. As an example, the development tool policy group specifies that the minimum permission level requirements for development tools include only allowing access to the project working directory, such as "C:\Projects\ProjectA"; prohibiting direct modification of the system registry; and only allowing connection to the IP address specified by the code hosting platform, such as GitHub's IP address.

[0093] Step S1343: Extract the minimum permission level requirements for entertainment applications from the entertainment application policy group. The minimum permission level requirements include allowing access only to the user's media file directory, prohibiting reading sensitive system information, and allowing connection only to the application's official server.

[0094] In this embodiment, the minimum permission level requirements for entertainment applications are extracted from the entertainment application policy group. As an example, the entertainment application policy group specifies that the minimum permission level requirements for entertainment applications include only allowing access to the user's media file directory, such as "C:\Users\username\Music"; prohibiting reading sensitive system information, such as key information in the registry; and only allowing connection to the IP address of the application's official server.

[0095] Step S1344: Obtain the actual permission settings in the software configuration parameters, including file access path range, registry modification permissions, and network connection target range.

[0096] In this embodiment, the actual permission settings in the software configuration parameters are obtained, including the file access path range, registry modification permissions, and network connection target range. As an example, for a certain office software, the actual file access path range obtained from the software configuration parameters includes critical system directories, the registry modification permission is set to "modifiable," and the network connection target range includes external networks. These actual permission settings will be used to compare with the minimum permission level requirements.

[0097] Step S1345: Compare the actual permission settings with the minimum permission level requirements of the corresponding policy group to identify software modules whose file access paths exceed the allowed range, whose registry modification permissions are too high, and whose network connection targets exceed the specified range.

[0098] In this embodiment, the actual permission settings of the software are compared with the minimum permission level requirements of the corresponding policy group to identify software modules with excessive permission settings. As an example, the actual permission settings of a certain office software are compared with the minimum permission level requirements of the office software policy group. It is found that the software's file access path exceeds the allowed user document directory range, its registry modification permissions are too high, and its network connection target exceeds the scope of the enterprise's internal network. This software module is determined to have excessive permission settings.

[0099] Step S1346: Record the identifiers of software modules with excessive permission settings and the corresponding file access path violation information, registry permission violation information, and network connection target violation information as the permission parameter violation information.

[0100] In this embodiment, the identifiers of software modules with excessive permission settings and related violation information are recorded. As an example, the identifier of the office software module with excessive permission settings is "WINWORD.EXE", the file access path violation information is "the file access path exceeds the allowed user document directory range and includes critical system directories", the registry permission violation information is "the registry modification permission is too high, allowing modification of the system registry", and the network connection target violation information is "the network connection target exceeds the scope of the enterprise's internal network and includes external networks".

[0101] Step S135: Integrate all software module identifiers that do not comply with the security policy and their corresponding parent process violation information, file path violation information, IP address violation information, and permission parameter violation information to generate preliminary scan results.

[0102] In this embodiment, all previously recorded software module identifiers and related violation information that do not comply with the security policy are integrated to generate preliminary scan results. As an example, violation information regarding the parent process and permission parameters of the office software module "WINWORD.EXE," file path violations of the development tool module "devenv.exe," and IP address violations of the entertainment application module "gameA.exe" are integrated. The preliminary scan results include identifiers of software modules that do not meet the security policy and detailed descriptions of abnormal operational behaviors, providing a foundation for subsequent vulnerability risk assessment.

[0103] Step S140: Assess the risk level of the software vulnerability based on the functional importance of the software module, the potential impact of abnormal operations, and the correlation with historical vulnerabilities in the preliminary scan results.

[0104] In this embodiment, based on the preliminary scan results, the risk level of the software vulnerability is assessed by comprehensively considering the functional importance of the software module, the potential impact of abnormal operations, and the correlation with historical vulnerabilities. As an example, continuing with an employee's office laptop, a detailed risk level assessment is performed on the software modules in the preliminary scan results. Step S140 may include the following sub-steps S141-S145, which are described in detail below.

[0105] Step S141: Obtain the functional description information of each software module from the preliminary scan results from the software management database of the target laptop. Based on whether the software module involves core business processing, user data storage, or the operation of key system functions, classify the functional importance of the software module as critical, important, or general.

[0106] In this embodiment, functional description information of software modules is obtained from the target laptop's software management database and categorized according to their functional importance. As an example, for software modules in the preliminary scan results, their functional description information is obtained from the software management database. For instance, an office software used to process core business data, involving important document editing and data statistics, is categorized as critical; a development tool used for daily code development, but with minimal impact on the core system functionality, is categorized as important; and an entertainment application primarily for leisure and entertainment, not involving core business processing or user data storage, is categorized as general.

[0107] Step S142: Analyze the operation type involved in the abnormal operation, determine the scope of impact corresponding to the abnormal operation, and generate a potential scope of impact description; the potential scope of impact description includes whether it may cause data leakage, system crash or third-party attack entry.

[0108] In this embodiment, the type of abnormal operation is analyzed to determine its potential impact range, and a description of the potential impact range is generated. As an example, for an abnormal operation in a certain office software, such as exceeding permission settings and gaining access to critical system files and external networks, the operation type is analyzed as unauthorized access. This abnormal operation may lead to data leakage because it can obtain critical system data and transmit it to external networks; it may also become a third-party attack entry point, allowing external attackers to launch attacks using the software's abnormal permissions. The generated potential impact range description is "may lead to data leakage and become a third-party attack entry point."

[0109] Step S143: Query the vulnerability history database to obtain historical vulnerability records of the software module and the corresponding abnormal operation types' remediation status, and calculate the probability of the same abnormal operation causing security events in the past as the historical vulnerability association probability.

[0110] In this embodiment, a vulnerability history database is queried to obtain historical vulnerability records and abnormal operation remediation status of the software module, and the probability of the same abnormal operation leading to a security incident is statistically analyzed. As an example, querying the vulnerability history database reveals that for an unauthorized access violation in a certain office software, similar unauthorized access violations have historically led to security incidents in a certain number of cases. The probability of unauthorized access violations leading to security incidents in these cases is statistically analyzed and used as the historical vulnerability association probability of this particular abnormal operation in the software module.

[0111] Step S144: Establish risk level assessment rules, where: critical-level functions that are important and whose potential impact includes data leakage or system crash, and whose historical vulnerability association probability exceeds a preset threshold, are assessed as high-risk; important-level functions that are important and whose potential impact includes third-party attack entry points, or critical-level functions that are important but whose historical vulnerability association probability does not exceed a threshold, are assessed as medium-risk; all other cases are assessed as low-risk.

[0112] In this embodiment, risk level assessment rules are established to determine the risk level based on the functional importance of a software module, its potential impact scope, and the probability of association with historical vulnerabilities. As an example, a preset threshold is a pre-defined probability value. If a software module is critically important, its potential impact scope includes data leakage or system crashes, and its historical vulnerability association probability exceeds the preset threshold, it is assessed as high-risk. If a software module is important, its potential impact scope includes third-party attack entry points, or its functional importance is critical but its historical vulnerability association probability does not exceed the threshold, it is assessed as medium-risk. Other cases are assessed as low-risk.

[0113] Step S145: Based on the functional importance classification results, the potential impact scope description, and the historical vulnerability association probability, assess the risk level of each software module vulnerability in the preliminary scan results.

[0114] In this embodiment, based on the previous classification results and statistical data, the risk level of each software module vulnerability in the preliminary scan results is assessed. As an example, for the office software "WINWORD.EXE", its functional importance is critical, its potential impact includes data leakage and third-party attack entry points, and its historical vulnerability association probability exceeds a preset threshold, so it is assessed as high-risk. For the development tool "devenv.exe", its functional importance is important, its potential impact includes third-party attack entry points, so it is assessed as medium-risk. For the entertainment application "gameA.exe", its functional importance is average, its potential impact is relatively small, so it is assessed as low-risk.

[0115] Step S150: Based on the risk level and the remediation guidelines in the security policy library, generate software vulnerability remediation guidance information that includes remediation operation steps, remediation priority identifiers, and verification method descriptions.

[0116] In this embodiment, detailed software vulnerability remediation guidance information is generated based on the vulnerability's risk level and the remediation guidelines in the security policy library. As an example, continuing with an employee's office laptop, remediation guidance information is generated based on the previously assessed software module vulnerability risk level and the remediation guidelines in the security policy library.

[0117] Step S150 can be implemented through the following sub-steps S151-S157, which are described in detail below.

[0118] Step S151: Extract the repair guidance clauses corresponding to each risk level from the security policy library. High risk level corresponds to emergency repair clauses, medium risk level corresponds to regular repair clauses, and low risk level corresponds to optimized repair clauses.

[0119] In this embodiment, remediation guidelines corresponding to different risk levels are extracted from the security policy library. As an example, the security policy library sets emergency remediation clauses for high-risk vulnerabilities, such as immediately stopping the violating process and restricting access permissions to the violating files; sets regular remediation clauses for medium-risk vulnerabilities, such as adjusting software configuration parameters and updating software version patches; and sets optimization remediation clauses for low-risk vulnerabilities, such as disabling unnecessary functional modules and adjusting data storage paths.

[0120] Step S152: For high-risk vulnerabilities, formulate operational guidelines for terminating the operation of unauthorized processes, restricting access to unauthorized files, and blocking unauthorized network connections, in accordance with the requirements of the emergency remediation clauses.

[0121] In this embodiment, specific operational guidelines are formulated for high-risk vulnerabilities based on the emergency remediation clauses. As an example, for the office software "WINWORD.EXE" assessed as high-risk, the operational guidelines are as follows based on the emergency remediation clauses: Terminate the violating process by forcibly terminating the software process using the system process management tool; restrict access permissions for violating files by modifying the software's file access permissions to only allow access to the user's document directory; block the violating network connection by prohibiting the software from connecting to external networks through firewall settings.

[0122] Step S153: For medium-risk vulnerabilities, generate operation steps for adjusting software configuration parameters, updating software version patches, and rebinding trusted parent processes in accordance with the provisions of the standard remediation terms.

[0123] In this embodiment, for medium-risk vulnerabilities, the operation steps are generated according to the standard remediation terms. As an example, for the development tool "devenv.exe" which is assessed as medium-risk, the operation steps generated according to the standard remediation terms are as follows: Adjust the software configuration parameters, modify the software's registry permissions and network connection settings to meet the minimum privilege level requirements; update the software version patch, download and install the latest software version patch from official channels; rebind the trusted parent process, ensuring through system settings that the parent process of this development tool is a trusted system process.

[0124] Step S154: For low-risk vulnerabilities, provide optimization suggestions such as disabling unnecessary functional modules, adjusting data storage paths, and reducing network connection permissions, in accordance with the guidelines of the optimization and remediation terms.

[0125] In this embodiment, optimization suggestions are provided for low-risk vulnerabilities in accordance with the optimization and remediation terms. As an example, for the entertainment application "gameA.exe" which is rated as low-risk, the optimization suggestions are as follows: disable unnecessary functional modules, such as disabling the application's ad push function; adjust the data storage path, changing the application's data storage path from the system critical directory to a user-specified secure directory; and reduce network connection permissions, restricting the application to only connecting to the application's official server.

[0126] Step S155: Assign priority labels to each remediation operation step according to the risk level. High-risk vulnerability remediation steps are marked as the highest priority, medium-risk steps are marked as the second highest priority, and low-risk steps are marked as the general priority.

[0127] In this embodiment, priority identifiers are assigned to repair operation steps based on risk level. As an example, the repair operation step for the high-risk office software "WINWORD.EXE" is marked as the highest priority; the repair operation step for the medium-risk development tool "devenv.exe" is marked as the second highest priority; and the repair operation step for the low-risk entertainment application "gameA.exe" is marked as a general priority.

[0128] Step S156: Design verification method descriptions for each repair operation step, including verifying whether the repaired process meets the requirements of a trusted process chain, whether file operations are only for allowed directories, whether network connections are only connected to whitelisted IP addresses, and whether the configuration parameters meet the minimum permission level.

[0129] In this embodiment, a verification method is designed for each repair operation step, which can be implemented through the following sub-steps S1561-S1565, as described below.

[0130] Step S1561: For the repair steps to terminate the operation of the violating process, the verification method is designed as follows: after the repair operation is executed, check through the system process monitoring interface whether the process of the corresponding software module has been terminated and has not been restarted within a preset time.

[0131] In this embodiment, a verification method is designed for the repair steps of terminating the execution of an unauthorized process. As an example, for the repair steps of terminating the execution of the unauthorized process of the office software "WINWORD.EXE", the verification method is designed as follows: After performing the repair operation, check whether the software process has been terminated through the system process monitoring interface. Furthermore, continuously monitor whether the process restarts within a preset period of time, such as 10 minutes. If it does not restart within the preset time, the verification is successful.

[0132] Step S1562: For the remediation steps of restricting unauthorized file operation permissions, the verification method is designed as follows: simulate the software module to perform file write operations, check whether the operation is only allowed to be completed within the directory path specified by the security policy, and whether write operations to non-allowed directories are rejected by the system.

[0133] For remediation steps involving restricted file operation permissions, designing a reasonable verification method is crucial to ensuring the effectiveness of the remediation. Taking the office software "WINWORD.EXE" as an example, the remediation process restricts its file operation permissions, stipulating that file operations can only be performed within the user's document directory. During verification, a file write operation is simulated using the office software. File writes can be attempted in different directory paths using the system's provided file operation interface. First, a write operation is performed in the user's document directory specified by the security policy to check if the operation completes normally. If the write operation is successful, it indicates that the software can perform file operations normally in allowed directories. Next, a write operation is attempted in a non-allowed critical system directory to observe whether the system rejects the operation. If the system rejects the write operation, indicating insufficient permissions or operation failure, it indicates that the file operation permission restriction remediation for the office software is effective and meets the requirements of the security policy.

[0134] Step S1563: For the remediation steps of blocking unauthorized network connections, the verification method is designed as follows: try to let the software module connect to a non-whitelisted IP address, check whether the network connection request is blocked by the firewall, and whether the connection status shows as rejected.

[0135] For the remediation steps of blocking unauthorized network connections, corresponding verification methods need to be designed to confirm the success of the remediation. Taking the entertainment application "gameA.exe" as an example, its network connection permissions are restricted during the remediation process, stipulating that it can only connect to IP addresses within the whitelist. During verification, an attempt is made to allow the entertainment application to connect to a non-whitelisted IP address. This can be done by simulating network requests and sending connection requests to non-whitelisted IP addresses. At the same time, the firewall logs and the software's connection status are checked. If the firewall logs show that the connection request was blocked, and the software's connection status shows "rejected," such as displaying messages like "Connection refused" or "Unable to connect to the specified server," it indicates that the remediation of blocking the unauthorized network connection of the entertainment application is effective, successfully preventing the software from connecting to non-whitelisted IP addresses, which complies with the security policy.

[0136] Step S1564: For the repair steps involving adjusting software configuration parameters, the verification method is designed as follows: read the software configuration file and registry entries to confirm that the configuration parameters have been modified to the minimum permission level required by the security policy, including the file access path range, registry modification permissions, and network connection target range.

[0137] Adjusting software configuration parameters is a crucial step in patching software vulnerabilities. To ensure that these parameters are adjusted to meet the minimum privilege level required by the security policy, appropriate verification methods need to be designed. Taking the development tool "devenv.exe" as an example, its configuration parameters were adjusted during the patching process to comply with the minimum privilege level requirements of the development tool's policy group. During verification, the development tool's configuration file and registry entries were read. The actual configuration parameters of the software were obtained through the system's provided file read interface and registry access interface. Then, the actual file access path range, registry modification permissions, and network connection target range were compared with the minimum privilege level required by the security policy. For example, it was checked whether the file access path was restricted to the allowed project temporary directory, whether the registry modification permissions were set to prohibit direct modification, and whether the network connection target was limited to the IP address specified by the code hosting platform. If the actual configuration parameters matched the minimum privilege level required by the security policy, it indicated that the configuration parameter adjustment and patching of the development tool was effective, and the software's permission settings complied with the security policy.

[0138] Step S1565: For the repair steps of the updated software version patch, the verification method is designed as follows: check whether the version number of the software module is consistent with the patch version specified by the security policy, and verify the integrity of the patch installation through the official software interface.

[0139] Updating software patches is a necessary step in fixing software vulnerabilities. To ensure successful and effective patch installation, appropriate verification methods need to be designed. Taking the office software "WINWORD.EXE" as an example, a software patch was updated during the repair process. Verification begins by checking the software module's version number. This can be done using the software's built-in version information viewer or the system's software management tools. Then, this version number is compared with the patch version specified in the security policy. If the version numbers match, the software has been updated to the specified patch version. Next, the integrity of the patch installation is verified using the official software interface. Software developers typically provide verification tools or interfaces to check if patches are installed correctly. For example, calling the official interface to perform file integrity checks and signature verification. If the verification results show that the patch is installed completely without file corruption or signature mismatches, it indicates that the patch update for the office software is effective, the software has installed the correct and complete patch, and it effectively fixes the relevant vulnerabilities.

[0140] Step S1566: For the repair step of rebinding the trusted parent process, the verification method is designed as follows: monitor the process startup process of the software module and check whether the parent process identifier of the newly started process belongs to a legitimate process in the trusted process chain specified by the security policy.

[0141] Rebinding a trusted parent process is a crucial step in patching software vulnerabilities. To ensure the effectiveness of this fix, appropriate verification methods need to be designed. Taking the office software "WINWORD.EXE" as an example, a rebinding of a trusted parent process was performed during the patching process. Verification involved monitoring the startup process of this office software module. This could be done using system process monitoring tools or relevant system interfaces to monitor the software process startup in real time. When the software starts, the parent process identifier of the newly started process is obtained. Then, this parent process identifier is compared with legitimate processes in the trusted process chain defined by the security policy. Security policies typically specify which processes can serve as the software's parent process, forming a trusted process chain. For example, the parent process of the office software might be a trusted system process like explorer.exe. If the parent process identifier of the newly started process belongs to a legitimate process in the trusted process chain, it indicates that the rebinding of the trusted parent process for the office software is effective, the software startup process complies with the security policy requirements, and the security risks caused by an untrusted parent process are reduced.

[0142] Step S157: Integrate the repair operation steps, the repair priority identifier, and the verification method description to generate software vulnerability repair guidance information.

[0143] Specifically, the remediation steps designed for software modules with different risk levels, the priority identifiers assigned to these steps, and the verification methods for each remediation step can be integrated to generate comprehensive software vulnerability remediation guidance information. Taking the office software "WINWORD.EXE," the development tool "devenv.exe," and the entertainment application "gameA.exe" as examples, the remediation steps for the office software, such as terminating the running of the violating process, restricting access permissions to the violating files, adjusting software configuration parameters, updating software version patches, and rebinding the trusted parent process, are summarized, along with their corresponding highest priority identifiers and detailed verification method descriptions. Similarly, the remediation steps, second-highest priority and general priority identifiers, and corresponding verification method descriptions for the development tool and entertainment application are collected. Then, these are categorized and organized according to different software modules to form a guidance document containing vulnerability remediation information for all software modules. This document details the remediation steps, priority order, and how to verify the success of the remediation for each software module, providing clear and accurate guidance for users to remediate software vulnerabilities efficiently and securely, improving the security and stability of laptop software.

[0144] In summary, the aforementioned security policy-based laptop software vulnerability scanning method, by acquiring the target laptop's security policy library, collecting software runtime data, matching and analyzing the two to generate preliminary scan results, assessing the vulnerability risk level based on the preliminary scan results, and finally generating remediation guidance information based on the risk level and the security policy library, forms a complete and systematic software vulnerability scanning and remediation system. This method fully considers the characteristics and security requirements of different software types, combining multiple factors for vulnerability detection and risk assessment, accurately identifying vulnerabilities in software and providing effective remediation solutions, thus providing strong protection for the secure operation of laptop software. Furthermore, detailed verification method descriptions ensure the effectiveness and reliability of the remediation operations, making the entire vulnerability scanning and remediation process more scientific and rigorous.

[0145] Based on the above, such as Figure 3 The diagram shown is a schematic of a laptop software vulnerability scanning system based on a security policy, provided in an embodiment of this application. The laptop software vulnerability scanning system includes components such as a processor, a machine-readable storage medium, and input / output devices. The machine-readable storage medium is connected to the processor and is used to store programs, instructions, or code. The processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the aforementioned laptop software vulnerability scanning method based on a security policy. The laptop software vulnerability scanning system based on a security policy can be understood as being described in this application. Figure 2 The application scenario shown could be a part of the laptop, or it could be the laptop itself.

[0146] The machine-readable storage medium may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), etc. The machine-readable storage medium is used to store a program, which the processor executes upon receiving an execution instruction.

[0147] The processor may be an integrated circuit chip with signal processing capabilities. The processor mentioned above can be, but is not limited to, a general-purpose processor, including a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.

[0148] In summary, the laptop software vulnerability scanning method and system based on security policies provided in this application achieve comprehensive and accurate scanning of laptop software vulnerabilities by comprehensively utilizing a security policy library and software operation data for matching analysis. This method can perform personalized vulnerability detection for different types of software based on their specific security needs and risk characteristics, greatly improving the accuracy and effectiveness of vulnerability detection. For example, in vulnerability risk assessment, it fully considers factors such as the functional importance of software modules, the potential impact of abnormal operations, and the correlation with historical vulnerabilities, making the risk assessment results more scientific and reasonable. Through this comprehensive assessment, the priority of vulnerability remediation can be determined more accurately, remediation resources can be allocated reasonably, and remediation efficiency can be improved. Furthermore, based on the risk level and remediation guidelines in the security policy library, detailed software vulnerability remediation guidance information is generated, including remediation operation steps, remediation priority indicators, and verification method descriptions. This provides clear guidance for software vulnerability remediation, making the remediation process more standardized and reliable, further improving the security and stability of laptop software.

[0149] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The embodiments, implementation methods, and related technical features of this application can be combined and substituted with each other without conflict. The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of this application without departing from the scope of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A notebook software vulnerability scanning method based on a security policy, characterized in that, The method comprises: obtaining the security policy library of the target notebook, the security policy library containing access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for different software types; collecting software running data of the target notebook, the software running data containing current running process information, file system operation records, network connection status and software configuration parameters; matching and analyzing the software running data and the security policy library to generate a preliminary scanning result containing software module identification that does not meet the security policy and abnormal operation behavior description; evaluating the risk level of software vulnerability according to the functional importance of the software module in the preliminary scanning result, the potential impact range of abnormal operation and historical vulnerability correlation; generating software vulnerability repair guidance information containing repair operation steps, repair priority identification and verification method description based on the risk level and repair instruction clauses in the security policy library; wherein the obtaining of the security policy library of the target notebook comprises: extracting a preset basic security policy from the system security configuration file of the target notebook, the basic security policy containing general access control rules and default data operation restriction conditions at the operating system level; synchronously updating industry-specific security policies from a third-party security service platform, specifically including: obtaining the use scenario label of the target notebook, the use scenario label being determined by analyzing the use frequency and functional focus direction of office software, development tools and entertainment applications in historical software use records; sending a policy synchronization request to the third-party security service platform according to the use scenario label, the policy synchronization request containing the operating system version, software installation list and industry affiliation information of the target notebook; receiving the industry-specific security policy data packet returned by the third-party security service platform, the data packet containing enhanced access control rules for the office software, enhanced data operation restriction conditions for the development tools and enhanced vulnerability detection benchmark requirements for the entertainment applications; performing integrity check on the industry-specific security policy data packet to verify whether the digital signature and hash value of the data packet are consistent with the check information provided by the third-party security service platform; parsing the industry-specific security policy data packet that passes the check, and extracting software type specific access control rules and enhanced data operation restriction conditions matching the use scenario label of the target notebook as industry-specific security policies; the industry-specific security policies contain software type specific access control rules and enhanced data operation restriction conditions related to the use scenario of the target notebook; performing version check on the basic security policy and the industry-specific security policy, identifying policy clauses with version conflicts and marking them as to-be-checked items; classifying and integrating policy clauses that are not marked as conflicting, dividing them into office software policy groups, development tool policy groups and entertainment application policy groups according to software types, each group containing access control rules, data operation restriction conditions and vulnerability detection benchmark requirements for the corresponding software type; The strategy clauses of the label conflict are manually reviewed, high-priority strategy clauses are reserved according to the actual use requirements of the target notebook, and a final security policy library is generated.

2. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The software running data of the collection target notebook includes: Obtaining a list of all software processes currently running through a system process monitoring interface, recording the name, start time, parent process identifier and system resource occupation of each process as current running process information; Traversing a specified directory path of the file system, recording the timestamp, operation type and target file path of the file operation of the software module on the system file and user data file as file system operation records; the file operation includes at least one of read operation, write operation and delete operation; Monitoring the data stream transmission of the network interface, recording the target IP address, port number, transmission protocol type and data flow size of the network connection established by the software module as network connection state; Reading the configuration file and registry item of the software module, extracting the function enable state, permission setting parameter, data storage path and third-party service integration information of the software as software configuration parameters; Timestamp alignment of the current running process information, the file system operation record, the network connection state and the software configuration parameter is performed to generate software running data with time sequence correlation.

3. The security policy based notebook software vulnerability scanning method of claim 2, wherein, The monitoring of the data stream transmission of the network interface, the recording of the target IP address, the port number, the transmission protocol type and the data flow size of the network connection established by the software module as the network connection state includes: Enabling a network traffic monitoring driver to capture data packets of all network interfaces of the target notebook; Protocol analysis is performed on the captured data packets to extract source process identifier, target IP address, target port number, transmission protocol type and data packet size; According to the source process identifier, the corresponding software module is associated to establish a mapping relationship between the software module and the network connection; The network connections established by the same software module within a preset time window are aggregated to count the connection times, total data flow size and average connection duration of each target IP address; Filter out the network connections related to system services, and only keep the network connection information initiated by the user installed software module; The target IP address, port number, transmission protocol type and data flow size in the retained network connection information are arranged into network connection state records.

4. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The matching analysis of the software running data and the security policy library generates a preliminary scanning result containing software module identifiers that do not meet the security policy and abnormal operation behavior descriptions, including: Extracting the access control rules of the office software policy group from the security policy library, checking whether the parent process identifier of the office software process meets the preset trusted process chain requirement, and recording the office software module identifier and parent process violation information that do not meet the requirement; According to the data operation restriction condition of the development tool policy group, checking whether the write operation of the development tool on the system file is only for the allowed temporary directory path, and recording the development tool module identifier and file path violation information that perform write operation in the non-allowed directory; According to the network connection restriction condition of the entertainment application strategy group, it is verified whether the target IP address of the network connection established by the entertainment application belongs to the whitelist range, and the entertainment application module identifier and IP address violation information of the connected non-whitelist IP address are recorded; The vulnerability detection benchmark requirement of each strategy group in the security policy library is extracted, and it is compared whether the permission setting in the software configuration parameter reaches the minimum permission level of the benchmark requirement, and the software module identifier and permission parameter violation information of the permission setting exceeding the standard are recorded; All software module identifiers and corresponding parent process violation information, file path violation information, IP address violation information, and permission parameter violation information that do not meet the security policy are integrated to generate a preliminary scanning result.

5. The security policy based notebook software vulnerability scanning method of claim 4, wherein, The extraction of the vulnerability detection benchmark requirement of each strategy group in the security policy library, the comparison of whether the permission setting in the software configuration parameter reaches the minimum permission level of the benchmark requirement, and the recording of the software module identifier and permission parameter violation information of the permission setting exceeding the standard include: The minimum permission level requirement of the office software is extracted from the office software strategy group; The minimum permission level requirement of the development tool is extracted from the development tool strategy group; The minimum permission level requirement of the entertainment application is extracted from the entertainment application strategy group; The actual permission setting in the software configuration parameter is obtained, including the file access path range, the registry modification permission, and the network connection target range; The actual permission setting is compared with the minimum permission level requirement of the corresponding strategy group to identify software modules whose file access path exceeds the allowed range, whose registry modification permission is too high, and whose network connection target exceeds the specified range; The software module identifier and corresponding file access path violation information, registry permission violation information, and network connection target violation information of the permission setting exceeding the standard are recorded as the permission parameter violation information.

6. The security policy based notebook software vulnerability scanning method of claim 1, wherein, The risk level of the software vulnerability is evaluated according to the function importance of the software module in the preliminary scanning result, the potential impact range of the abnormal operation, and the historical vulnerability correlation, including: The function description information of each software module in the preliminary scanning result is obtained from the software management database of the target notebook, and the function importance of the software module is divided into critical, important, or general level according to whether it involves core business processing, user data storage, or system critical function operation; The operation type involved in the abnormal operation is analyzed, the corresponding impact range of the abnormal operation is determined, and the potential impact range description is generated; the potential impact range description includes whether it can cause data leakage, system crash, or third-party attack entry; The historical vulnerability record of the software module and the repair situation of the corresponding abnormal operation type are obtained by querying the vulnerability history database, and the probability of causing a security event in the same abnormal operation history is calculated as the historical vulnerability correlation probability; The risk level assessment rules are established, wherein: if the function importance is critical, the potential impact range contains data leakage or system collapse, and the historical vulnerability correlation probability exceeds a preset threshold, the risk level is high; if the function importance is important, the potential impact range contains a third-party attack entrance, or the function importance is critical but the historical vulnerability correlation probability does not exceed the threshold, the risk level is medium; and the rest is low. According to the division result of the function importance, the potential impact range description, and the historical vulnerability correlation probability, the risk level of each software module vulnerability in the preliminary scanning result is assessed.

7. The security policy based notebook software vulnerability scanning method of claim 6, wherein, The software vulnerability repair guidance information including repair operation steps, repair priority identification, and verification method description is generated based on the risk level and the repair guidance clauses in the security policy library, including: The repair guidance clauses corresponding to each risk level are extracted from the security policy library, wherein the high risk level corresponds to an emergency repair clause, the medium risk level corresponds to a regular repair clause, and the low risk level corresponds to an optimized repair clause; For high-risk-level vulnerabilities, operation guidelines for terminating the running of illegal processes, limiting the operation permissions of illegal files, and blocking illegal network connections are developed according to the requirements of the emergency repair clause; For medium-risk-level vulnerabilities, operation steps for adjusting software configuration parameters, updating software version patches, and re-binding trusted parent processes are generated according to the provisions of the regular repair clause; For low-risk-level vulnerabilities, optimization suggestion steps for shutting down unnecessary function modules, adjusting data storage paths, and narrowing network connection permissions are provided according to the guidelines of the optimized repair clause; The priority identification is assigned to each repair operation step according to the risk level; The verification method description is designed for each repair operation step, including verifying whether the processes after repair meet the trusted process chain requirements, whether the file operations are only for allowed directories, whether the network connections are only connected to white-listed IP addresses, and whether the configuration parameters reach the minimum permission level; The software vulnerability repair guidance information is generated by integrating the repair operation steps, the repair priority identification, and the verification method description.

8. A security policy based notebook software vulnerability scanning system, characterized by, The processor, the machine readable storage medium, the machine readable storage medium and the processor are connected, the machine readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine readable storage medium to realize the method in any one of claims 1-7.

Images