A code file scanning method, device and equipment and storage medium

Abstract

The application discloses a code file scanning method and device, equipment and a storage medium, and relates to the technical field of network security. The method comprises the following steps: receiving a scanning signal, and performing parallel scanning on a plurality of target code files stored in a storage device by using a target coprocessor, so as to convert character stream source codes in the plurality of target code files into corresponding target token streams; performing a filtering operation on the plurality of target token streams, and matching hash values of the target tokens obtained after the filtering with a preset risk rule library by using the target coprocessor, so as to obtain matching results corresponding to the plurality of target token streams; and analyzing the matching results, determining vulnerability risk files in the plurality of target code files, and performing corresponding target operations based on the risk levels of the vulnerability risk files. Thus, the coprocessor is combined with the design of an independent storage partition, so that the storage performance is ensured, and efficient and low-delay code security scanning is realized.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a code file scanning method, apparatus, device, and storage medium. Background Technology

[0002] With the increasing prevalence of cybersecurity threats, secure scanning of code files has become increasingly important. However, traditional code security scanning methods typically rely on external code security scanning software or cloud services, which suffer from high scanning latency, high system resource consumption, and dependence on network connectivity. Furthermore, existing storage devices act as passive storage devices, unable to proactively identify potential risks to stored data, especially security threats to code-related data. Moreover, current code security scanning requires the deployment of separate code security scanning software and high-configuration scanning equipment, and scanning generally occurs during software development, targeting source code. Without purchasing software or with insufficient equipment performance, effective scanning of code-related data and mitigation of potential security risks cannot be achieved after deployment.

[0003] Therefore, there is an urgent need for a lightweight code security scanning solution integrated into storage devices that can automatically detect security risks during data writing without affecting the normal storage function of the hard drive. Summary of the Invention

[0004] This application provides a code file scanning method, apparatus, device, and storage medium, which can achieve efficient and low-latency code security scanning while ensuring storage performance through a design that combines a coprocessor with an independent storage partition.

[0005] This application provides a code file scanning method applied to a storage device, wherein the storage device is configured with a target coprocessor built based on logic devices; wherein the code file scanning method includes:

[0006] Using the received scanning signal, and through the target coprocessor, several target code files stored in the storage device are scanned in parallel to convert the character stream source code in the several target code files into several corresponding target token streams;

[0007] The system performs filtering operations on each token in several target token streams based on a preset filter, and then uses a target coprocessor to match the hash value of the filtered target token with a preset risk rule base to obtain several matching results corresponding to several target token streams; the preset risk rule base is a rule base pre-configured in the target coprocessor.

[0008] Analyze several matching results to identify vulnerable files in several target code files and determine the risk level of the vulnerable files.

[0009] Based on the risk level, perform corresponding target operations on the vulnerability risk files; the target operations include any one of the following: direct storage of the file, scanning and verification, and blocking and isolation.

[0010] This application also provides a code file scanning device for use in a storage device, wherein the storage device is configured with a target coprocessor built based on logic devices; wherein the code file scanning device includes:

[0011] The code conversion module is used to use the received scanning signal and the target coprocessor to perform parallel scanning on several target code files stored in the storage device, so as to convert the character stream source code in the several target code files into several corresponding target token streams.

[0012] The risk matching module is used to filter each token in several target token streams based on a preset filter, and then match the hash value of the filtered target token with a preset risk rule base through a target coprocessor to obtain several matching results corresponding to several target token streams; the preset risk rule base is a rule base pre-configured in the target coprocessor.

[0013] The risk level determination module is used to analyze several matching results to identify the vulnerability risk files in several target code files and determine the risk level corresponding to the vulnerability risk files.

[0014] The risk file processing module is used to perform corresponding target operations on vulnerability risk files based on the risk level; among which, the target operations include any one of direct storage, scanning and verification, and blocking and isolation of the file.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described code file scanning methods when executing the computer program.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described code file scanning methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described code file scanning methods.

[0018] The method of this application utilizes received scanning signals and a target coprocessor to perform parallel scanning on several target code files stored in a storage device, converting the character stream source code in the target code files into corresponding target token streams. Based on a preset filter, each token in the target token streams is filtered, and the hash value of the filtered target token is matched with a preset risk rule base by the target coprocessor to obtain several matching results corresponding to the target token streams. The preset risk rule base is a rule base pre-configured in the target coprocessor. The matching results are analyzed to identify vulnerability risk files among the target code files and determine the risk level corresponding to each vulnerability risk file. Based on the risk level, corresponding target operations are performed on the vulnerability risk files. The target operations include any one of direct storage, scanning verification, and blocking / isolation of the file.

[0019] Therefore, the method of this application allows for parallel processing of several target code files stored in the storage device after the storage device receives a scan signal. This is achieved through a coprocessor within the storage device, converting the code files into corresponding token streams. This parallel processing enables the processing of multiple code file blocks, improving scan throughput and meeting the real-time detection requirements of high-speed storage devices. Then, a preset filter can be used to filter the tokens in the token stream. The target coprocessor then matches the hash values ​​of the filtered target tokens with a preset risk rule base to determine vulnerable files based on the matching results. Finally, appropriate processing can be performed based on the risk level of the vulnerable files, such as direct storage, scan verification, and blocking / isolation. In this way, by embedding a coprocessor-accelerated security scanning method in the storage device, real-time scanning during code writing is achieved. Even when storage users do not purchase independent code security scanning software or are unaware of code security, this invention enables secure scanning of code-related data, avoiding potential security risks. Furthermore, the lexical analyzer and filters accurately identify vulnerability types, improving the accuracy of vulnerability scanning. Attached Figure Description

[0020] To more clearly illustrate the embodiments of this application, the accompanying drawings used in 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 these drawings without creative effort.

[0021] Figure 1 A flowchart of a code file scanning method provided in this application embodiment;

[0022] Figure 2This is a schematic diagram illustrating the breakdown of a vulnerability identification process provided in an embodiment of this application;

[0023] Figure 3 An architecture diagram of a code file scanning method provided in this application embodiment;

[0024] Figure 4 This is a schematic diagram of a code file scanning device provided in an embodiment of this application. Detailed Implementation

[0025] 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 some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0026] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0027] Currently, traditional code security scanning methods typically rely on external code security scanning software or cloud services, which suffers from high scanning latency, high system resource consumption, and dependence on network connectivity. Furthermore, existing storage devices act merely as passive storage, unable to proactively identify potential risks to stored data, especially security threats to code-related data. Moreover, current code security scanning requires the deployment of separate code security scanning software and high-configuration scanning equipment, and scanning generally occurs during software development, targeting source code. Without purchasing software or with insufficient equipment performance, effective scanning of code-related data and mitigation of potential security risks are impossible after deployment.

[0028] To overcome the aforementioned technical problems, this application discloses a code file scanning method, apparatus, device, and storage medium. Through the design of a coprocessor combined with an independent storage partition, efficient and low-latency code security scanning is achieved while ensuring storage performance.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The architecture of the code file scanning method in this application mainly consists of three parts: a host interface layer, an acceleration layer, and a storage control layer. The host interface layer receives code files from the host system and stores them based on existing storage protocols. The acceleration layer integrates a coprocessor in the storage controller to perform static code analysis, including lexical analysis and rule matching. The coprocessor can be selected according to user needs; in this application, an FPGA (Field-Programmable Gate Array) coprocessor is used to improve scanning efficiency. The storage control layer controls whether the scanning function is enabled through storage management software and allocates independent storage partitions. Scan results are fed back to the storage management software through a dedicated hard drive interface. Based on the scan results, the file is subjected to one of the following processing methods: direct storage, scan verification, or blocking / isolation.

[0031] See Figure 1 As shown, embodiments of this application provide a code file scanning method applied to a storage device. The storage device is configured with a target coprocessor built based on logic devices. The method is described in detail below, in conjunction with the execution flow of the code file scanning method, including:

[0032] Step S11: Using the received scanning signal, and through the target coprocessor, perform parallel scanning on several target code files stored in the storage device to convert the character stream source code in the several target code files into corresponding target token streams.

[0033] In this embodiment, the target coprocessor only begins scanning and storing code files after receiving the scan signal from the storage device. Therefore, before starting code file scanning, a scan signal needs to be generated first. Specifically, the target command set received from the host needs to be detected. If a preset detection flag exists in the target command set, several target code files corresponding to the target command set are written to the local temporary check cache. It should be noted that during the triggering phase, the host writes files to storage via the NVMe (Non-Volatile Memory Express) protocol, and the NVMe Command Set must contain a custom SCAN_REQ flag. If the storage device detects this flag, a secure scan of the code files is triggered, and several code files corresponding to the command set are written to the local temporary check cache. Furthermore, temporary entries need to be created for several target code files, and the status of several target code files needs to be marked in the temporary entries to mark several target code files as pending scan status. At the same time, a scan signal needs to be generated and sent to the target coprocessor so that the target coprocessor can perform a secure scan of several target code files. It should be noted that the temporary bars are created in the FTL (Flash Translation Layer) to record the file LBA (Logical Block Address) and the scan status (Pending).

[0034] Furthermore, after the storage device receives the scan signal, it reads several target code files from the temporary check buffer based on a preset bus protocol and a preset data block size. The preset bus protocol is AXI (Advanced Dextensible Interface), and the preset data block size can be set according to the request; in this application, it is set to 4KB. Therefore, a target coprocessor, i.e., an FPGA coprocessor, is needed to read file content from the DRAM (Dynamic Random Access Memory) buffer via the AXI bus, processing it in 4KB block streams. Then, a preset lexical analyzer is needed to perform parallel analysis on the several target code files to decompose the code in each file, obtaining corresponding code units, and converting these code units into corresponding target token streams.

[0035] The specific process of parallel analysis of code files using a preset lexical analyzer is as follows: First, identify several code syntax structures corresponding to several target code files and determine several code lexical rules corresponding to these syntax structures. Then, load these code lexical rules into a preset memory located in the target coprocessor. Finally, based on the preset lexical analyzer and utilizing the code lexical rules in the preset memory, perform parallel lexical decomposition on several target code files to obtain corresponding code units. In other words, it is necessary to identify the syntax structure of the code files. For example, if the code file uses C language syntax, it is necessary to determine the corresponding C language code lexical rules and then load these rules into the preset memory of the target coprocessor so that the code files can be lexically decomposed using these lexical rules. It should be noted that the default lexer can convert the source code character stream into a token stream, for example, parsing if(x>5) into [KEYWORD_IF, DELIMITER_LPAREN, IDENTIFIER(x), OPERATOR_GT, NUMBER(5), DELIMITER_RPAREN]. It supports languages ​​such as C, JAVA, Python, Go, and JS. The language types mentioned here are just examples and can be adapted to various development languages ​​according to actual needs.

[0036] This approach, using an FPGA coprocessor for static analysis, offers higher computational efficiency and lower latency compared to traditional CPU software scanning. It also supports parallel processing of multiple code file blocks, increasing scan throughput and meeting the real-time detection requirements of high-speed storage devices. Furthermore, the scanning task is executed independently by the FPGA coprocessor, physically / logically isolated from the storage controller, avoiding the consumption of host processor resources or impacting normal storage read / write performance. Additionally, storing code files in DRAM reduces interference from non-code data, improving scan accuracy.

[0037] Step S12: Filter each token in several target token streams based on a preset filter, and match the hash value of the filtered target token with a preset risk rule base through a target coprocessor to obtain several matching results corresponding to several target token streams; the preset risk rule base is a rule base pre-configured in the target coprocessor.

[0038] In this embodiment, before matching the token with the preset risk rule base, the risk rule base needs to be constructed first. Specifically, the preset risk rules need to be converted into the target hardware description language; the target hardware description language is then saved to the preset memory of the target coprocessor to generate the preset risk rule base based on the target hardware description language in the preset memory. It should be noted that the rule base achieves real-time matching through FPGA hardware acceleration and supports dynamic security policy updates. The rule base primarily focuses on high-risk vulnerabilities, and can be set according to the CWE (Common Weakness Enumeration) Top-class vulnerabilities, stored in the FPGA BRAM (Block Random Access Memory), supporting firmware hot updates. Taking SQL (Structured Query Language) injection as an example, the detection rules are set as follows:

[0039] # Parameterized query detection with support for multiple language variants

[0040] pattern = r"""

[0041] (?:mysql_query|pg_exec|sqlite3_exec)\s*\(

[0042] \s*["'].*? # Start quotation mark

[0043] (?:%s|\{0\}) # String formatting placeholder (Python / C#)

[0044] .*? # Any character in between

[0045] \b(?:OR\s+1=1|UNION\s+SELECT) # Attack characteristics

[0046] .*?["'] # End of quotes

[0047] \s*\) # Function closure

[0048] """ % (r'%[ds]|{\d+}|\?') # Overwrites placeholders such as %s, ?, and {0};

[0049] The above rules need to be broken down as follows:

[0050] {

[0051] "rule_id": "CWE-89-001", # 4-byte encoding

[0052] "func_pattern": ["mysql_query", "pg_exec", "sqlite3_exec"], # List of function names

[0053] "placeholder": ["%s", "{0}", "?"], # Placeholder type

[0054] "attack_sig": ["OR 1=1", "UNION SELECT"], # Attack signature

[0055] "action": "block" # Action to take

[0056] };

[0057] Then, FPGA hardware mapping is required to convert the above rules into a hardware description language:

[0058] module rule_storage (

[0059] input [5:0] rule_addr,

[0060] output reg [191:0] rule_data / / 192bit / rule );

[0062] always @(*) begin

[0063] case(rule_addr)

[0064] 0: rule_data = {32'h89_0001, 24'h6d7973, ...}; / / CWE-89-001 encoding

[0065] endcase

[0066] end

[0067] endmodule.

[0068] As shown in the example above, each rule needs to be converted into its corresponding language. The resulting hardware description language is then saved to the target coprocessor's preset memory. This allows for the construction of a preset risk rule base using the hardware description languages ​​corresponding to different rules. It should be noted that rules can be hot-updated via the NVMe management interface or storage management software. In this way, the constructed risk rule base can accurately match and identify risks in the code, improving the accuracy of code risk and vulnerability identification during code file scanning.

[0069] Furthermore, when performing risk identification on token streams, the token streams first need to be filtered. Specifically, several preset hash functions in the preset filters are used to process each token in several target token streams in parallel to obtain the first hash value corresponding to the target tokens after filtering. The code contains a massive number of tokens, but the security rules only concern a very small number of dangerous functions; therefore, token filtering is necessary. A space needs to be allocated in the high-speed on-chip BRAM of the FPGA, all bits initialized to 0, and then three independent, computationally efficient hash functions are selected to process each token in the target token streams in parallel, mapping each token to three different positions in the array. For example, if the input token is "os.system", the hash function 1 (h1) calculates to obtain position 42, and hash function 2 (h2) calculates to obtain position 7. 89. After hash function 3 (h3) calculates position 1023, the values ​​of these three positions in the bit array need to be set to 1. Then, based on several preset hash functions in the preset filter, the preset risk rules in the preset risk rule base need to be calculated to obtain several second hash values ​​corresponding to each preset risk rule and several preset hash functions. Then, the first hash value needs to be matched with several second hash values ​​respectively. If the first hash value matches the target second hash value among several second hash values, the corresponding first matching result indicating a successful match is generated. Specifically, if the values ​​of positions 42, 789 and 1023 in the second hash value corresponding to the preset risk rule are all 1, it indicates that this token hits a certain risk rule. If the value of any one of the three positions is 1, it indicates that the token may hit a certain risk rule. Therefore, as long as one hash value matches, the token is retained. On the other hand, if the first hash value does not match any of the second hash values, a second matching result indicating a failed match is generated. For example, if the second hash value corresponding to a preset risk rule contains three values ​​of 0 at positions 42, 789, and 1023, it indicates that the token does not match any risk rule, the token is secure, and therefore can be discarded. In this way, the existence of vulnerabilities in a token can be determined by calculating its hash value, thereby effectively improving the accuracy of security scanning.

[0070] It should be noted that vulnerability matching can be summarized as follows: Figure 2 The three stages shown are: the first stage is function call identification to quickly locate sensitive function entry points; the second stage is placeholder detection to identify potentially injected code segments; and the third stage is attack feature matching to accurately capture malicious code patterns.

[0071] Step S13: Analyze several matching results to identify the vulnerability risk files in several target code files and determine the risk level corresponding to the vulnerability risk files.

[0072] In this embodiment, several matching results need to be analyzed to identify vulnerable files in the target code file and determine their corresponding risk levels. Specifically, the code file corresponding to the first matching result is taken as the vulnerable file, and the vulnerability type is determined. It should be noted that the FPGA coprocessor has multiple independent matching units, each responsible for a specific type of vulnerability. For example, one unit might handle CWE-78, while another handles CWE-79. This ensures that each vulnerability is detected using the most suitable hardware circuit. After detection and confirmation, each vulnerability is matched against a preset risk level table to determine its corresponding risk level. The vulnerability risk levels are divided into 0 to 4, where levels 0 to 2 correspond to a safe risk level (which can be ignored), level 3 is a suspicious level, and level 4 is a high-risk level.

[0073] Furthermore, it is necessary to generate vulnerability risk metadata corresponding to the vulnerability risk file. This requires determining the code location information of the vulnerable code in the vulnerability risk file, and then generating the vulnerability risk metadata based on the code location information, vulnerability type, and risk level. This metadata is then written into the vulnerability risk file. The code location information represents the line number of the vulnerability in the vulnerability risk file, the vulnerability type is the vulnerable code, and the risk level is the level corresponding to the vulnerability in the preset risk level table. It should also be noted that the vulnerability risk metadata also contains other data, such as version identifiers and anti-tampering verification identifiers. The metadata format of the vulnerability risk metadata is shown in Table 1, and Table 1 is as follows:

[0074] Table 1. Metadata Format of Vulnerability Risk Metadata

[0075] .

[0076] Step S14: Perform corresponding target operations on the vulnerability risk files based on the risk level; wherein, the target operations include any one of direct storage, scanning and verification, and blocking and isolation of the files.

[0077] In this embodiment, corresponding operations need to be performed on the vulnerability risk files according to the risk level of the vulnerability. Specifically, the risk levels include Level 1, Level 2, and Level 3. Level 1 corresponds to levels 0 to 2, which is a safe risk level. The target operation for Level 1 is to directly store the vulnerability risk files. Level 2 corresponds to level 3, which is a suspicious risk level. The target operation for Level 2 is to scan and verify the vulnerability risk files to determine whether to store them based on the verification results. Level 3 corresponds to level 4, which is a high-risk risk level. The target operation for Level 3 is to block and isolate the vulnerability risk files and issue an alert.

[0078] Specifically, for vulnerability risk files with a risk level of Level 2, the vulnerability risk file needs to be saved to a preset sandbox, and it needs to be determined whether the current load meets the preset low load conditions. If the current load meets the preset low load conditions, a preset deep scan is performed on the vulnerability risk file to reconfirm the target risk level corresponding to the vulnerability in the vulnerability risk file. If the target risk level is Level 1, the vulnerability risk file is directly stored. If the target risk level is Level 3, the vulnerability risk file is blocked and isolated, and an alarm is issued. Specifically, for Level 2 vulnerability risk files, the storage controller adopts a delayed processing strategy, temporarily keeping the file data in the DRAM buffer, but not writing it to the disk, to avoid immediately intercepting files that may be falsely reported. The controller records the file hash and suspicious markers. During the storage device's idle period, such as during low-load IO (Input / Output), a deep scan is triggered to reload the file content and perform more complex static analysis, such as data flow tracing and implicit vulnerability detection. If the deep scan confirms the risk, it is processed according to Level 3, blocked and isolated, and an alarm is issued. If it is a false alarm, it is processed according to Level 1, and written to the disk normally. On the other hand, for vulnerability files with a risk level of three, these files need to be transferred to a pre-defined isolation partition, and real-time blocking should be implemented to generate corresponding alert logs. This requires notifying the host driver of write failures via a PCIe MSI-X interrupt, and copying the file content from DRAM to the isolation zone. This isolation zone is a separate block reserved by the storage system, accessible only to security administrators. After isolation, alert logs must be generated to notify the administrator of the high-risk vulnerability.

[0079] Therefore, the method of this application allows for parallel processing of several target code files stored in the storage device after the storage device receives a scan signal. This parallel processing enables the processing of multiple code file blocks, improving scan throughput and meeting the real-time detection requirements of high-speed storage devices. Then, a preset filter can be used to filter the tokens in the token stream. The target coprocessor then matches the hash values ​​of the filtered target tokens with a preset risk rule base to determine vulnerable files based on the matching results. Finally, appropriate processing can be performed based on the risk level of the vulnerable files, such as direct storage, scan verification, or blocking / isolation. In this way, on the one hand, by embedding a coprocessor-accelerated security scanning method in the storage device, real-time scanning can be achieved during code writing. Even if the storage user has not purchased independent code security scanning software or is unaware of code security, the solution of this invention can achieve secure scanning of code-type data and avoid potential security risks. On the other hand, the lexical analyzer and filters can accurately identify vulnerability types and improve the accuracy of vulnerability scanning. Furthermore, high-risk files are intercepted in real time during the data writing stage to prevent them from polluting the storage system. This approach does not rely on cloud-based scanning or network connections and is suitable for isolated environments.

[0080] In a preferred embodiment, a preset interface can be used to collect scan information corresponding to several target code files, and the scan information can be fed back to the upper-layer application corresponding to the storage device. The scan information includes the total number of files corresponding to several target code files, the number of files corresponding to each risk level, the vulnerability type, and the scan time. The preset interface is SMART (Self-Monitoring Analysis and Reporting Technology), which can inject scan information into SMART attributes, and REST (Representational State Transfer) or gRPC (Google Remote Procedure Call) interfaces for upper-layer applications to query.

[0081] As a preferred embodiment, such as Figure 3The diagram illustrates the overall architecture of the code file scanning method. After receiving code files from the host system, the host interface layer stores them based on existing storage protocols. If a detection flag is detected in the target command set sent by the host, several target code files corresponding to the target command set are written to a local temporary check cache, triggering a security scan. Then, the code files are analyzed in parallel by the lexical analyzer in the lexical analysis module to obtain the token stream corresponding to the code files. The tokens in the token stream are then matched against a preset risk rule base in the rule matching module to determine which tokens successfully match the risk rules in the risk rule base. The successfully matched code files are then designated as vulnerability risk files, and appropriate handling schemes are determined based on the vulnerability risk level, such as direct storage, scan verification, or blocking and isolation. Finally, the scan information corresponding to several target code files can be statistically analyzed through a preset interface, and the scan information is fed back to the upper-layer application corresponding to the storage device.

[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0083] See Figure 4 As shown, embodiments of this application also provide a code file scanning device applied to a storage device, wherein the storage device is configured with a target coprocessor built based on logic devices; wherein, the code file scanning device includes:

[0084] The code conversion module 11 is used to use the received scanning signal and the target coprocessor to perform parallel scanning on several target code files stored in the storage device, so as to convert the character stream source code in the several target code files into several corresponding target token streams.

[0085] The risk matching module 12 is used to filter each token in several target token streams based on a preset filter, and to match the hash value of the filtered target token with a preset risk rule base through a target coprocessor to obtain several matching results corresponding to several target token streams; the preset risk rule base is a rule base pre-configured in the target coprocessor.

[0086] The risk level determination module 13 is used to analyze several matching results to identify the vulnerability risk files in several target code files and determine the risk level corresponding to the vulnerability risk files.

[0087] The risk file processing module 14 is used to perform corresponding target operations on vulnerability risk files based on risk level; wherein, the target operations include any one of direct storage, scanning and verification, and blocking and isolation of the file.

[0088] The method described in this application allows for parallel processing of several target code files stored in the storage device after the storage device receives a scan signal. This is achieved through a coprocessor within the storage device, converting the code files into corresponding token streams. This parallel processing enables the processing of multiple code file blocks, improving scan throughput and meeting the real-time detection requirements of high-speed storage devices. Then, a preset filter is used to filter the tokens in the token stream. The target coprocessor then matches the hash values ​​of the filtered target tokens with a preset risk rule base to identify vulnerable files based on the matching results. Finally, appropriate processing is performed based on the risk level of the vulnerable files, such as direct storage, scan verification, and blocking / isolation. This method, by embedding a coprocessor-accelerated security scanning method into the storage device, enables real-time scanning during code writing. Even when storage users do not purchase independent code security scanning software or are unaware of code security, this invention provides a secure scanning solution for code-related data, avoiding potential security risks. Furthermore, the lexical analyzer and filters accurately identify vulnerability types, improving the accuracy of vulnerability scanning.

[0089] In some embodiments, the code file scanning device may further include:

[0090] The command set detection unit is used to detect the target command set received from the host.

[0091] The file writing unit is used to write several target code files corresponding to the target command set into the local temporary check cache if a preset detection flag exists in the target command set.

[0092] The file marking unit is used to create temporary entries for several target code files and mark the status of several target code files in the temporary entries to mark several target code files as being to be scanned;

[0093] The signal generation unit is used to generate a scan signal and send the scan signal to the target coprocessor so that the target coprocessor can perform a security scan on several target code files.

[0094] In some embodiments, the code conversion module 11 may specifically include:

[0095] The file reading submodule is used to read several target code files from the temporary inspection cache based on a preset data block size via a preset bus protocol if the target coprocessor receives a scan signal.

[0096] The code decomposition submodule is used to perform parallel analysis on several target code files based on a preset lexical analyzer, so as to decompose the code in several target code files respectively and obtain several corresponding code units;

[0097] The code transformation submodule is used to convert several code units into several corresponding target token streams.

[0098] In some embodiments, code decomposition into submodules may specifically include:

[0099] The rule determination unit is used to identify several code syntax structures corresponding to several target code files and determine several code lexical rules corresponding to the several code syntax structures;

[0100] The rule loading unit is used to load several code lexical rules into a preset memory located in the target coprocessor;

[0101] The syntax decomposition unit is used to perform parallel syntax decomposition on several target code files based on a preset lexical analyzer and using several code lexical rules in a preset memory, so as to obtain several code units corresponding to the target code files respectively.

[0102] In some embodiments, the code file scanning device may further include:

[0103] The rule conversion unit is used to convert preset risk rules into the target hardware description language;

[0104] The rule base generation unit is used to save the target hardware description language to the preset memory of the target coprocessor, so as to generate a preset risk rule base in the preset memory based on the target hardware description language.

[0105] In some embodiments, the risk matching module 12 may specifically include:

[0106] The first hash value calculation unit is used to process each token in several target token streams in parallel through several preset hash functions in the preset filter, so as to obtain the first hash value corresponding to the target tokens obtained after filtering in the several target token streams.

[0107] The second hash value calculation unit is used to calculate the preset risk rules in the preset risk rule base based on a number of preset hash functions in the preset filter, so as to obtain a number of second hash values ​​corresponding to each preset risk rule and a number of preset hash functions.

[0108] A hash value matching unit is used to match a first hash value with several second hash values ​​respectively;

[0109] The first matching result generation unit is used to generate a corresponding first matching result indicating a successful match if the first hash value matches a target second hash value among a plurality of second hash values; the target second hash value is any hash value among a plurality of second hash values.

[0110] The second matching result generation unit is used to generate a second matching result indicating a matching failure if the first hash value does not match any of the second hash values.

[0111] In some embodiments, the risk level determination module 13 may specifically include:

[0112] The vulnerability type determination unit is used to take the code file corresponding to the first matching result among several matching results as the vulnerability risk file and determine the vulnerability type corresponding to the vulnerability risk file.

[0113] The risk matching unit is used to match vulnerability types with a preset vulnerability risk level table to determine the risk level corresponding to a vulnerability type.

[0114] In some embodiments, the code file scanning device may further include:

[0115] Location information determination unit, used to determine the code location information of vulnerable code in vulnerability risk files;

[0116] The metadata writing unit is used to generate vulnerability risk metadata for the vulnerability risk file based on code location information, vulnerability type, and risk level, and then write the vulnerability risk metadata into the vulnerability risk file.

[0117] In some embodiments, the risk levels include a first level, a second level, and a third level.

[0118] In some embodiments, the risk document processing module 14 may specifically include:

[0119] The first processing submodule is used for the target operation corresponding to the first level, which is to directly store the vulnerability risk file;

[0120] The second processing submodule is used for the target operation corresponding to the second level, which is to scan and verify the vulnerability risk file, and determine whether to store the vulnerability risk file based on the verification result.

[0121] The third processing submodule is used for the target operation corresponding to the third level, which is to block and isolate the vulnerable risk files and issue an alert.

[0122] In some embodiments, the first processing submodule may specifically include:

[0123] The condition judgment unit is used to save the vulnerability risk file to the preset sandbox and determine whether the current load meets the preset low load condition.

[0124] The file scanning unit is used to perform a preset depth scan on the vulnerability risk file if the current load meets the preset low load condition, so as to reconfirm the target risk level corresponding to the vulnerability in the vulnerability risk file.

[0125] The first operation unit is used to directly store the vulnerability risk file if the target risk level is level one.

[0126] The second operation unit is used to block and isolate the vulnerable files and issue an alert if the target risk level is level three.

[0127] In some embodiments, the third processing submodule may specifically include:

[0128] The file transfer unit is used to transfer vulnerable files to a preset isolation partition;

[0129] The alarm unit is used to block vulnerable files in real time and generate alarm logs corresponding to the vulnerable files.

[0130] In some embodiments, the code file scanning device may further include:

[0131] The information feedback unit is used to collect scan information corresponding to several target code files through a preset interface and feed the scan information back to the upper-layer application corresponding to the storage device. The scan information includes the total number of files corresponding to several target code files, the number of files corresponding to each risk level, the vulnerability type, and the scan time.

[0132] For a description of the features in the embodiment corresponding to the code file scanning device, please refer to the relevant description of the embodiment corresponding to the code file scanning method, which will not be repeated here.

[0133] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described code file scanning method embodiments.

[0134] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described code file scanning method embodiments at runtime.

[0135] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0136] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described code file scanning method embodiments.

[0137] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described code file scanning method embodiments.

[0138] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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.

[0139] The foregoing has provided a detailed description of a code file scanning method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A code file scanning method, characterized in that, Applied to a storage device, wherein the storage device is configured with a target coprocessor built based on logic devices; wherein the method includes: The received scanning signal is used to perform parallel scanning on several target code files stored in the storage device through the target coprocessor, so as to convert the character stream source code in the several target code files into several corresponding target token streams; the target coprocessor is a coprocessor built based on FPGA; The target token streams are filtered based on a preset filter, and the hash values ​​of the filtered target tokens are matched with a preset risk rule base by the target coprocessor to obtain several matching results corresponding to the target token streams. The preset risk rule base is a rule base pre-configured in the target coprocessor. The matching results are analyzed to identify the vulnerability risk files in the target code files and to determine the risk level corresponding to the vulnerability risk files. Based on the risk level, perform corresponding target operations on the vulnerability risk files; wherein, the target operations include any one of directly storing the files, scanning and verifying, and blocking and isolating them; The method further includes, before using the received scanning signal and performing parallel scanning of several target code files stored in the storage device through the target coprocessor to convert the character stream source code in the several target code files into corresponding several target token streams: Detect the target command set sent by the host; If a preset detection flag exists in the target command set, then several target code files corresponding to the target command set will be written into the local temporary check cache area; Temporary entries are created for the target code files, and status markers are applied to the target code files in the temporary entries to mark the target code files as pending scanning. A scan signal is generated and sent to the target coprocessor to perform a security scan on the plurality of target code files. The step of using the received scanning signal and performing parallel scanning of several target code files stored in the storage device through the target coprocessor to convert the character stream source code in the several target code files into several corresponding target token streams includes: If the target coprocessor receives a scan signal, it reads the plurality of target code files from the temporary inspection cache based on a preset data block size using a preset bus protocol; the preset bus protocol is the AXI protocol, and the preset data block size is 4KB. The target code files are analyzed in parallel using a preset lexical analyzer to decompose the code in the target code files and obtain corresponding code units. The code units are converted into corresponding target token streams.

2. The code file scanning method according to claim 1, characterized in that, The method involves parallel analysis of the target code files based on a preset lexical analyzer to decompose the code in each target code file into corresponding code units, including: Identify several code syntax structures corresponding to the several target code files, and determine several code lexical rules corresponding to the several code syntax structures; The aforementioned lexical rules are loaded into a preset memory located in the target coprocessor; Based on a preset lexical analyzer and utilizing the several code lexical rules in the preset memory, the several target code files are parsed in parallel to obtain several code units corresponding to the several target code files.

3. The code file scanning method according to claim 2, characterized in that, Before the step of filtering each token in the plurality of target token streams based on a preset filter, and matching the hash value of the filtered target token with a preset risk rule base through the target coprocessor to obtain a plurality of matching results corresponding to the plurality of target token streams, the method further includes: Convert the preset risk rules into the target hardware description language; The target hardware description language is saved to the preset memory of the target coprocessor to generate a preset risk rule base in the preset memory based on the target hardware description language.

4. The code file scanning method according to claim 1, characterized in that, The process involves filtering each token in the plurality of target token streams based on a preset filter, and then matching the hash values ​​of the filtered target tokens with a preset risk rule base using the target coprocessor to obtain several matching results corresponding to the plurality of target token streams, including: The tokens in the target token streams are processed in parallel using several preset hash functions in the preset filter to obtain the first hash value corresponding to the target tokens after filtering in the target token streams. Based on several preset hash functions in the preset filter, the preset risk rules in the preset risk rule base are calculated to obtain several second hash values ​​corresponding to each preset risk rule and the several preset hash functions; The first hash value is matched with each of the plurality of second hash values; If the first hash value matches a target second hash value among the plurality of second hash values, a corresponding first matching result representing a successful match is generated; the target second hash value is any hash value among the plurality of second hash values. If the first hash value does not match any of the several second hash values, a second matching result representing a failed match is generated.

5. The code file scanning method according to claim 4, characterized in that, The analysis of the several matching results to identify the vulnerability risk files among the several target code files, and the determination of the risk level corresponding to the vulnerability risk files, includes: The code file corresponding to the first matching result among the plurality of matching results is taken as the vulnerability risk file, and the vulnerability type corresponding to the vulnerability risk file is determined; The risk level corresponding to the vulnerability type is determined by matching the vulnerability type with a preset vulnerability risk level table.

6. The code file scanning method according to claim 5, characterized in that, Before performing the corresponding target operation on the vulnerability risk file based on the risk level, the method further includes: Determine the code location information of the vulnerable code in the vulnerability risk file; Based on the code location information, the vulnerability type, and the risk level, vulnerability risk metadata is generated for the vulnerability risk file, and the vulnerability risk metadata is written into the vulnerability risk file.

7. The code file scanning method according to any one of claims 1 to 6, characterized in that, The risk levels include a first level, a second level, and a third level; wherein, the target operation corresponding to the first level is to directly store the vulnerability risk file; the target operation corresponding to the second level is to scan and verify the vulnerability risk file to determine whether to store the vulnerability risk file based on the verification result; and the target operation corresponding to the third level is to block and isolate the vulnerability risk file and issue an alarm.

8. The code file scanning method according to claim 7, characterized in that, The vulnerability risk file is scanned and verified to determine whether to store it based on the verification results, including: Save the vulnerability risk file to a preset sandbox and determine whether the current load meets the preset low load condition; If the current load meets the preset low load condition, then a preset deep scan is performed on the vulnerability risk file to reconfirm the target risk level corresponding to the vulnerability in the vulnerability risk file; If the target risk level is the first level, then the vulnerability risk file is stored directly; If the target risk level is the third level, the vulnerability risk file will be blocked and isolated, and an alert will be issued.

9. The code file scanning method according to claim 7, characterized in that, The vulnerable files are blocked and isolated, and alerts are issued, including: Transfer the vulnerability risk files to a preset isolation partition; The vulnerability risk file is blocked in real time, and an alarm log corresponding to the vulnerability risk file is generated.

10. The code file scanning method according to claim 7, characterized in that, Also includes: The scanning information corresponding to the several target code files is statistically analyzed through a preset interface, and the scanning information is fed back to the upper-layer application corresponding to the storage device; The scanning information includes the total number of files corresponding to several target code files, the number of files corresponding to each risk level, the vulnerability type, and the scanning time.

11. A code file scanning device, characterized in that, An apparatus for use in a storage device, wherein the storage device is configured with a target coprocessor built based on logic devices; wherein the apparatus includes: The code conversion module is used to use the received scanning signal and the target coprocessor to perform parallel scanning on several target code files stored in the storage device, so as to convert the character stream source code in the several target code files into several corresponding target token streams; the target coprocessor is a coprocessor built based on FPGA; The risk matching module is used to filter each token in the plurality of target token streams based on a preset filter, and to match the hash value of the filtered target token with a preset risk rule base through the target coprocessor to obtain a plurality of matching results corresponding to the plurality of target token streams; the preset risk rule base is a rule base pre-configured in the target coprocessor. The risk level determination module is used to analyze the several matching results to determine the vulnerability risk files in the several target code files and determine the risk level corresponding to the vulnerability risk files; The risk file processing module is used to perform corresponding target operations on the vulnerability risk file based on the risk level; wherein, the target operation includes any one of direct storage, scanning and verification, and blocking and isolation of the file; The code file scanning device also includes: The command set detection unit is used to detect the target command set received from the host. The file writing unit is used to write several target code files corresponding to the target command set into the local temporary check cache if a preset detection flag exists in the target command set. The file marking unit is used to create temporary entries for several target code files and mark the status of several target code files in the temporary entries to mark several target code files as being to be scanned; The signal generation unit is used to generate a scan signal and send the scan signal to the target coprocessor so that the target coprocessor can perform a security scan on several target code files. The code conversion module includes: The file reading submodule is used to read several target code files from the temporary inspection cache based on a preset data block size via a preset bus protocol if the target coprocessor receives a scan signal; the preset bus protocol is the AXI protocol and the preset data block size is 4KB. The code decomposition submodule is used to perform parallel analysis on several target code files based on a preset lexical analyzer, so as to decompose the code in several target code files respectively and obtain several corresponding code units; The code transformation submodule is used to convert several code units into several corresponding target token streams.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to perform the steps of the code file scanning method as described in any one of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the code file scanning method as described in any one of claims 1 to 10.

Images