Code scanning method and apparatus, electronic device, and computer readable medium

Abstract

This invention discloses a code scanning method, apparatus, electronic device, and computer-readable medium, relating to the field of software development technology. One specific embodiment of the method includes: scanning each source code package under a source code package directory to obtain the code size, name, and directory structure of each source code package; retrieving each JAR file referenced in each source code package and cutting and pasting each JAR file into a JAR file folder; allocating memory units for each source code package according to its code size; wherein, a larger code size in a source code package is positively correlated with the memory units allocated to that source code package; and, based on the memory units allocated to each source code package, batch scanning the source code packages to obtain code scanning results. This embodiment can solve the technical problems of inaccurate vulnerability scanning results and slow scanning speed.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a code scanning method, apparatus, electronic device, and computer-readable medium. Background Technology

[0002] Microservices consist of many loosely coupled and independently deployable components or services. Therefore, a Java microservice project often contains a dozen or even dozens of Java source code packages. Fortify, being a standalone software, consumes significant memory resources when scanning projects with dozens of source code packages, and may even fail due to insufficient server resources. Even with server support, Fortify has certain requirements for the code being scanned. Ideally, the code should be an uncompiled, deployable set of source code. During code scanning, Fortify dynamically tracks dependent files such as JAR files. Because each component or service in a microservice project can be deployed independently, it will have its own dependent JAR files. These JAR files may be duplicated or have different versions. In either case, Fortify may not know which JAR file to scan. If the corresponding class or method cannot be found during code analysis, the analysis will be interrupted, leading to problems in vulnerability analysis and affecting the vulnerability scan results.

[0003] Fortify is a standalone tool. When scanning code, if memory usage isn't limited, it can consume a significant amount of server resources, potentially causing server lag or slow response times. This results in Fortify scanning only one project at a time, leading to multiple projects queuing and wasting considerable time. Scanning all the code together can also cause problems like JAR version conflicts and large code volumes, resulting in lengthy scans or even failures. Therefore, using Fortify to scan such projects is time-consuming, slow, inefficient, and produces inaccurate results. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a code scanning method, apparatus, electronic device, and computer-readable medium to solve the technical problems of inaccurate vulnerability scanning results and slow scanning speed.

[0005] To achieve the above objectives, according to one aspect of the present invention, a code scanning method is provided, comprising:

[0006] Scan each source code package in the source code package directory to obtain the code size, name, and directory structure of each source code package;

[0007] Retrieve the JAR files referenced in each of the source code packages, and cut and paste each JAR file into the JAR file folder;

[0008] Based on the code size of each source code package, memory units are allocated to each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package;

[0009] Based on the memory units allocated to each source code package, the source code packages are scanned in batches to obtain code scanning results.

[0010] Optionally, retrieve the JAR files referenced in each of the source code packages, and cut and paste each JAR file into the JAR file folder, including:

[0011] The source code packages are traversed one by one. If the first jar package is found, it is determined whether a second jar package with the same name as the first jar package exists in the jar package folder.

[0012] If it exists, cut the first JAR file into the JAR file folder and overwrite the second JAR file;

[0013] If it does not exist, cut and paste the first JAR file into the JAR file folder.

[0014] Optionally, cutting and pasting the first JAR file into the JAR file folder and overwriting the second JAR file includes:

[0015] Compare the file sizes of the first JAR file and the second JAR file;

[0016] If the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then the first JAR file is cut and pasted into the JAR file folder and the second JAR file is overwritten;

[0017] If the file size of the first JAR file is smaller than the file size of the second JAR file, then the first JAR file will be deleted.

[0018] Optionally, based on the memory units allocated to each source code package, the source code packages are scanned in batches to obtain code scanning results, including:

[0019] For each source code package, convert the source code package into an NST file;

[0020] Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

[0021] Optionally, after obtaining the FPR result file containing vulnerability information, it also includes:

[0022] The FPR result files corresponding to each source code package are merged into a single code scanning result file.

[0023] Optionally, the various source code packages belong to the same microservice project, and the various source code packages are stored in the same microservice directory.

[0024] Optionally, the JAR file folder is located in the microservice directory.

[0025] Additionally, according to another aspect of the present invention, a code scanning apparatus is provided, comprising:

[0026] The first scanning module is used to scan each source code package under the source code package directory to obtain the code size, name and directory structure of each source code package.

[0027] The retrieval module is used to retrieve the JAR files referenced in each of the source code packages and cut and paste each JAR file into the JAR file folder;

[0028] The allocation module is used to allocate memory units to each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package;

[0029] The second scanning module is used to scan each source code package in batches based on the memory units allocated to each source code package, thereby obtaining code scanning results.

[0030] Optionally, the retrieval module is further configured to:

[0031] The source code packages are traversed one by one. If the first jar package is found, it is determined whether a second jar package with the same name as the first jar package exists in the jar package folder.

[0032] If it exists, cut the first JAR file into the JAR file folder and overwrite the second JAR file;

[0033] If it does not exist, cut and paste the first JAR file into the JAR file folder.

[0034] Optionally, the retrieval module is further configured to:

[0035] Compare the file sizes of the first JAR file and the second JAR file;

[0036] If the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then the first JAR file is cut and pasted into the JAR file folder and the second JAR file is overwritten;

[0037] If the file size of the first JAR file is smaller than the file size of the second JAR file, then the first JAR file will be deleted.

[0038] Optionally, the second scanning module is further configured to:

[0039] For each source code package, convert the source code package into an NST file;

[0040] Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

[0041] Optionally, the second scanning module is further configured to:

[0042] After obtaining the FPR result file containing vulnerability information, the FPR result files corresponding to each source code package are merged into a single code scanning result file.

[0043] Optionally, the various source code packages belong to the same microservice project, and the various source code packages are stored in the same microservice directory.

[0044] Optionally, the JAR file folder is located in the microservice directory.

[0045] According to another aspect of the present invention, an electronic device is also provided, comprising:

[0046] One or more processors;

[0047] Storage device for storing one or more programs.

[0048] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0049] According to another aspect of the present invention, a computer-readable medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in any of the above embodiments.

[0050] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0051] One embodiment of the above invention has the following advantages or beneficial effects: By employing the technique of retrieving each JAR file referenced in each source code package, cutting and pasting each JAR file into a JAR file folder, allocating memory units for each source code package according to its code size, and then batch scanning each source code package based on the allocated memory units to obtain code scanning results, the technical problems of inaccurate vulnerability scanning results and slow scanning speed in the prior art are overcome. This invention can automatically analyze the source code file structure, handle messy or duplicate JAR files in the source code, improve the accuracy of vulnerability scanning results, and automatically allocate appropriate memory space for each source code package, improving code scanning efficiency. Therefore, it performs code security scanning quickly and effectively without manual intervention.

[0052] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

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

[0054] Figure 1 This is a flowchart of a code scanning method according to an embodiment of the present invention;

[0055] Figure 2 This is a flowchart of a code scanning method according to a possible embodiment of the present invention;

[0056] Figure 3 This is a flowchart of a code scanning method according to another possible embodiment of the present invention;

[0057] Figure 4 This is a flowchart of a code scanning method according to another possible embodiment of the present invention;

[0058] Figure 5 This is a schematic diagram of a code scanning device according to an embodiment of the present invention;

[0059] Figure 6 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0060] Figure 7 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0061] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0062] It should be noted that the collection, analysis, use, transmission, and storage of user personal information involved in the technical solution of this invention all comply with relevant laws and regulations, are used for legitimate and reasonable purposes, and are not shared, disclosed, or sold outside of these legitimate uses, and are subject to supervision and management by regulatory authorities. Necessary measures should be taken to prevent unauthorized access to such personal information data, ensure that personnel authorized to access personal information data comply with relevant laws and regulations, and ensure the security of user personal information. Once this user personal information data is no longer needed, the risk should be minimized by restricting or even prohibiting data collection and / or deleting the data.

[0063] When applicable, including in certain relevant applications, user privacy is protected by de-identifying data, such as by removing specific identifiers (e.g., date of birth, name, gender, account number, etc.), controlling the amount or specificity of stored data, controlling how data is stored, and / or other methods of de-identification.

[0064] Figure 1 This is a flowchart of a code scanning method according to an embodiment of the present invention. As one embodiment of the present invention, such as... Figure 1 As shown, the code scanning method may include:

[0065] Step 101: Scan each source code package in the source code package directory to obtain the code size, name and directory structure of each source code package.

[0066] First, obtain the source code package directory. The source code package directory can be entered by the operations and maintenance personnel or the developers. The source code package directory points to the directory where each source code package is located. Then, scan each source code package under the entire source code package directory, analyze the code as a whole, and obtain information such as the amount of code (e.g., number of lines of code), name, and directory structure of each source code package.

[0067] Optionally, the various source code packages belong to the same microservice project and are stored in the same microservice directory. For example, a microservice consists of many loosely coupled and independently deployable components or services, so a Java microservice project often contains a dozen or more Java source code packages.

[0068] Java: An object-oriented programming language that allows you to write cross-platform applications.

[0069] JAR files: JAR files are archives of classes, a platform-independent file format that allows many files to be combined into a single compressed file. However, unlike ordinary compressed files, JAR files are not only used for compression and distribution, but also for deploying and packaging libraries, components, and plugins, and can be directly used by tools like compilers and the JVM.

[0070] Microservices: A software development technique—a variation of Service-Oriented Architecture (SOA)—that advocates dividing a single application into a set of small services that coordinate and cooperate with each other to provide end-value to the user. Each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms (typically HTTP-based RESTful APIs). Each service is built around a specific business function and can be independently deployed to production, pre-production, and other environments.

[0071] Step 102: Retrieve the JAR files referenced in each source code package and cut each JAR file into the JAR folder.

[0072] After analyzing the code size, name, and directory structure of each source code package, a new JAR file folder is created under the source code package directory, and all JAR files referenced by each source code package are cut and pasted into this JAR file folder. Optionally, the JAR file folder is located under the microservice directory.

[0073] Optionally, step 102 may include: traversing each source code package one by one; if a first JAR package is found, determining whether a second JAR package with the same name as the first JAR package exists in the JAR package folder; if it exists, cutting the first JAR package into the JAR package folder and overwriting the second JAR package; if it does not exist, cutting the first JAR package into the JAR package folder. Each source code package in the source code package directory is traversed one by one, and each JAR package is cut into the JAR package folder. If multiple JAR packages with the same name exist, only one JAR package is saved in the JAR package folder; other JAR packages can either overwrite the first JAR package or delete it. In other words, each source code package in the source code package directory is checked to determine if there are duplicate JAR packages; if so, the duplicate JAR packages are overwritten.

[0074] Optionally, cutting and pasting the first JAR file into the JAR file folder and overwriting the second JAR file includes: comparing the file sizes of the first JAR file and the second JAR file; if the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then cutting and pasting the first JAR file into the JAR file folder and overwriting the second JAR file; if the file size of the first JAR file is less than the file size of the second JAR file, then deleting the first JAR file. If multiple JAR files with the same name exist, then comparing the file sizes of these JAR files, such that only the JAR file with the largest file size is kept in the JAR file folder, and other JAR files with the same name are deleted or overwritten.

[0075] Step 103: Allocate memory units for each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package.

[0076] Based on the code size of each source code package obtained in step 101, memory units are allocated to each source code package, such that the larger the code size of the source code package, the larger the memory unit allocated to the source code package, and the smaller the code size of the source code package, the smaller the memory unit allocated to the source code package.

[0077] This invention is based on the Fortify tool, and makes the best use of and allocates memory resources to improve the scanning efficiency of Fortify for microservice projects with multiple packages and large amounts of code.

[0078] Step 104: Based on the memory units allocated to each source code package, scan each source code package in batches to obtain code scanning results.

[0079] After allocating appropriate memory units to each source code, the size of the memory units allocated to each source code, the amount of code in each source code package, its name, and directory structure are passed to the Fortify tool by calling the sourceanalyzer-b command. The code scanning command is then executed using the os.system(cmd) Python function. The Fortify tool scans each source code package in batches, thus obtaining the code scanning results.

[0080] Optionally, step 104 may include: for each source code package, converting the source code package into an NST file; based on the memory units allocated to each source code package, analyzing the NST file using a static analysis engine, and simultaneously matching vulnerability features in the rule base to obtain an FPR result file containing vulnerability information. To enable the static analysis engine (such as the Fortify tool) to quickly analyze each source code, each source code is first converted into an NST file, and then the static analysis engine analyzes each NST file while matching vulnerability features in the rule base to obtain an FPR result file containing vulnerability information.

[0081] Fortify converts the front-end language code (such as Java) into an intermediate media file, NST (Normal Syntax Tree), by calling the language's compiler or interpreter, clarifying the call relationships between its source code. It then analyzes the NST file using a static analysis engine that analyzes different types of problems, matching vulnerability characteristics across all rule bases to assess vulnerabilities. Finally, it generates an FPR (Fault Reporting) result file containing detailed vulnerability information, which can be opened to view the scan analysis results.

[0082] Optionally, after obtaining the FPR result file containing vulnerability information, the method further includes merging the FPR result files corresponding to each source code package into a single code scanning result file. The static analysis engine obtains the FPR result files corresponding to each source code package by analyzing each NST file, and finally merges the FPR result files into a single code scanning result file, which is the final code scanning result.

[0083] Therefore, embodiments of the present invention utilize Python scripts for code analysis, JAR package replacement, calling the Fortify tool to scan files, and automatically synthesizing the final code scanning results.

[0084] Based on the various embodiments described above, it can be seen that the present invention solves the technical problems of inaccurate vulnerability scanning results and slow scanning speed in the prior art by retrieving the JAR files referenced in each source code package, cutting and pasting the JAR files into a JAR file folder, allocating memory units for each source code package according to the code size of each source code package, and batch scanning each source code package based on the allocated memory units, thereby obtaining code scanning results. The present invention can automatically analyze the source code file structure, handle messy or duplicate JAR files in the source code, improve the accuracy of vulnerability scanning results, and automatically allocate appropriate memory space for each source code package, improving code scanning efficiency. Therefore, it performs code security scanning quickly and effectively without manual intervention.

[0085] Figure 2 This is a flowchart of a code scanning method according to a possible embodiment of the present invention. As another embodiment of the present invention, such as... Figure 2 As shown, the code scanning method may include:

[0086] Step 201: Scan each source code package in the source code package directory to obtain the code size, name and directory structure of each source code package.

[0087] Step 202: Iterate through each source code package one by one. If the first jar package is found, determine whether there is a second jar package with the same name as the first jar package in the jar package folder. If it exists, proceed to step 203; if it does not exist, proceed to step 204.

[0088] Step 203: Cut the first jar file into the jar file folder and overwrite the second jar file.

[0089] Step 204: Cut the first jar file into the jar file folder.

[0090] Step 205: Allocate memory units for each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package.

[0091] Step 206: Based on the memory units allocated to each source code package, scan each source code package in batches to obtain code scanning results.

[0092] Furthermore, the specific implementation details of the code scanning method in one of the reference embodiments of the present invention have been described in detail in the code scanning method described above, so the details will not be repeated here.

[0093] Figure 3This is a flowchart of a code scanning method according to another possible embodiment of the present invention. As another embodiment of the present invention, such as... Figure 3 As shown, the code scanning method may include:

[0094] Step 301: Scan each source code package in the source code package directory to obtain the code size, name and directory structure of each source code package.

[0095] Step 302: Iterate through each source code package one by one. If the first jar package is found, determine whether there is a second jar package with the same name as the first jar package in the jar package folder. If it exists, proceed to step 303; if it does not exist, proceed to step 306.

[0096] Step 303: Compare the file sizes of the first JAR file and the second JAR file; if the file size of the first JAR file is greater than or equal to the file size of the second JAR file, proceed to step 304; if the file size of the first JAR file is less than the file size of the second JAR file, proceed to step 305.

[0097] Step 304: Cut the first jar file into the jar file folder and overwrite the second jar file.

[0098] Step 305: Delete the first JAR file.

[0099] Step 306: Cut the first jar file into the jar file folder.

[0100] Step 307: Allocate memory units for each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package.

[0101] Step 308: Based on the memory units allocated to each source code package, scan each source code package in batches to obtain code scanning results.

[0102] In addition, the specific implementation details of the code scanning method in another reference embodiment of the present invention have been described in detail in the code scanning method described above, so the details will not be repeated here.

[0103] Figure 4 This is a flowchart of a code scanning method according to another possible embodiment of the present invention. As another embodiment of the present invention, such as... Figure 4 As shown, the code scanning method may include:

[0104] Step 401: Scan each source code package in the source code package directory to obtain the code size, name and directory structure of each source code package.

[0105] Step 402: Retrieve the JAR files referenced in each source code package and cut each JAR file into the JAR folder.

[0106] Step 403: Allocate memory units for each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package.

[0107] Step 404: For each source code package, convert the source code package into an NST file.

[0108] Step 405: Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

[0109] Step 406: Merge the FPR result files corresponding to each source code package into a single code scanning result file.

[0110] Furthermore, the specific implementation details of the code scanning method in another reference embodiment of the present invention have been described in detail in the code scanning method described above, so the details will not be repeated here.

[0111] Figure 5 This is a schematic diagram of a code scanning apparatus according to an embodiment of the present invention. Figure 5 As shown, the code scanning device 500 includes a first scanning module 501, a retrieval module 502, an allocation module 503, and a second scanning module 504. The first scanning module 501 scans each source code package under the source code package directory to obtain the code size, name, and directory structure of each source code package. The retrieval module 502 retrieves each JAR file referenced in each source code package and cuts and pastes each JAR file into a JAR file folder. The allocation module 503 allocates memory units to each source code package based on its code size; the larger the code size of the source code package, the more memory units are allocated to it. The second scanning module 504 scans each source code package in batches based on the memory units allocated to it, thereby obtaining code scanning results.

[0112] Optionally, the retrieval module 502 is further configured to:

[0113] The source code packages are traversed one by one. If the first jar package is found, it is determined whether a second jar package with the same name as the first jar package exists in the jar package folder.

[0114] If it exists, cut the first JAR file into the JAR file folder and overwrite the second JAR file;

[0115] If it does not exist, cut and paste the first JAR file into the JAR file folder.

[0116] Optionally, the retrieval module 502 is further configured to:

[0117] Compare the file sizes of the first JAR file and the second JAR file;

[0118] If the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then the first JAR file is cut and pasted into the JAR file folder and the second JAR file is overwritten;

[0119] If the file size of the first JAR file is smaller than the file size of the second JAR file, then the first JAR file will be deleted.

[0120] Optionally, the second scanning module 504 is further configured to:

[0121] For each source code package, convert the source code package into an NST file;

[0122] Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

[0123] Optionally, the second scanning module 504 is further configured to:

[0124] After obtaining the FPR result file containing vulnerability information, the FPR result files corresponding to each source code package are merged into a single code scanning result file.

[0125] Optionally, the various source code packages belong to the same microservice project, and the various source code packages are stored in the same microservice directory.

[0126] Optionally, the JAR file folder is located in the microservice directory.

[0127] It should be noted that the specific implementation details of the code scanning device described in this invention have been described in detail in the code scanning method described above, so the details will not be repeated here.

[0128] Figure 6An exemplary system architecture 600 is shown that can be applied to the code scanning method or code scanning apparatus of embodiments of the present invention.

[0129] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 serves as the medium for providing communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0130] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0131] Terminal devices 601, 602, and 603 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0132] Server 605 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 601, 602, and 603 (this is just an example). The backend management server can analyze and process data such as received item information query requests, and then feed the processing results back to the terminal devices.

[0133] It should be noted that the code scanning method provided in this embodiment of the invention is generally executed by server 605, and correspondingly, the code scanning device is generally installed in server 605. The code scanning method provided in this embodiment of the invention can also be executed by terminal devices 601, 602, and 603, and correspondingly, the code scanning device can be installed in terminal devices 601, 602, and 603.

[0134] It should be understood that Figure 6 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0135] The following is for reference. Figure 7 It shows a schematic diagram of the structure of a computer system 700 suitable for implementing a terminal device of the present invention. Figure 7 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0136] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0137] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0138] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined above in the system of this invention.

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

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

[0141] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including a first scanning module, a retrieval module, an allocation module, and a second retrieval module. The names of these modules do not necessarily limit the functionality of the module itself.

[0142] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the device, the device performs the following method: scanning each source code package under the source code package directory to obtain the code size, name, and directory structure of each source code package; retrieving each JAR package referenced in each source code package and cutting and pasting each JAR package into a JAR package folder; allocating memory units for each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more positively correlated the memory units allocated to the source code package; and based on the memory units allocated to each source code package, batch scanning the source code packages to obtain code scanning results.

[0143] In another aspect, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0144] According to the technical solution of this invention, by retrieving the JAR files referenced in each source code package, cutting and pasting the JAR files into a JAR folder, allocating memory units for each source code package based on its code size, and then batch scanning each source code package based on the allocated memory units, thereby obtaining code scanning results, this invention overcomes the technical problems of inaccurate vulnerability scanning results and slow scanning speed in the prior art. This invention can automatically analyze the source code file structure, handle messy or duplicate JAR files in the source code, improve the accuracy of vulnerability scanning results, and automatically allocate appropriate memory space for each source code package, improving code scanning efficiency. Therefore, it performs code security scanning quickly and effectively without manual intervention.

[0145] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A code scanning method, characterized in that, include: Scan each source code package in the source code package directory to obtain the code size, name, and directory structure of each source code package; Retrieve the JAR files referenced in each of the source code packages, and cut and paste each JAR file into the JAR file folder; Based on the code size of each source code package, memory units are allocated to each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package; Based on the memory units allocated to each source code package, the source code packages are scanned in batches to obtain code scanning results; Retrieve each JAR file referenced in each of the source code packages, and cut and paste each JAR file into the JAR file folder, including: The source code packages are traversed one by one. If the first jar package is found, it is determined whether a second jar package with the same name as the first jar package exists in the jar package folder. If it exists, cut the first JAR file into the JAR file folder and overwrite the second JAR file; If it does not exist, cut the first jar file into the jar file folder; Cut the first JAR file into the JAR file folder and overwrite the second JAR file, including: Compare the file sizes of the first JAR file and the second JAR file; If the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then the first JAR file is cut and pasted into the JAR file folder and the second JAR file is overwritten; If the file size of the first JAR file is smaller than the file size of the second JAR file, then the first JAR file will be deleted.

2. The method according to claim 1, characterized in that, Based on the memory units allocated to each source code package, the source code packages are scanned in batches to obtain code scanning results, including: For each source code package, convert the source code package into an NST file; Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

3. The method according to claim 2, characterized in that, After obtaining the FPR result file containing vulnerability information, it also includes: The FPR result files corresponding to each source code package are merged into a single code scanning result file.

4. The method according to claim 1, characterized in that, The various source code packages belong to the same microservice project, and the various source code packages are stored in the same microservice directory.

5. The method according to claim 4, characterized in that, The JAR file folder is located in the microservice directory.

6. A code scanning device, characterized in that, include: The first scanning module is used to scan each source code package under the source code package directory to obtain the code size, name and directory structure of each source code package. The retrieval module is used to retrieve the JAR files referenced in each of the source code packages and cut and paste each JAR file into the JAR file folder; The allocation module is used to allocate memory units to each source code package according to the code size of each source code package; wherein, the larger the code size of the source code package, the more memory units are allocated to the source code package; The second scanning module is used to scan each source code package in batches based on the memory units allocated to each source code package, thereby obtaining code scanning results; The retrieval module is also used for: The source code packages are traversed one by one. If the first jar package is found, it is determined whether a second jar package with the same name as the first jar package exists in the jar package folder. If it exists, cut the first JAR file into the JAR file folder and overwrite the second JAR file; If it does not exist, cut the first jar file into the jar file folder; The retrieval module is also used for: Compare the file sizes of the first JAR file and the second JAR file; If the file size of the first JAR file is greater than or equal to the file size of the second JAR file, then the first JAR file is cut and pasted into the JAR file folder and the second JAR file is overwritten; If the file size of the first JAR file is smaller than the file size of the second JAR file, then the first JAR file will be deleted.

7. The apparatus according to claim 6, characterized in that, The second scanning module is also used for: For each source code package, convert the source code package into an NST file; Based on the memory units allocated to each source code package, the NST file is analyzed by a static analysis engine, and vulnerability features in the rule base are matched to obtain an FPR result file containing vulnerability information.

8. The apparatus according to claim 7, characterized in that, The second scanning module is also used for: After obtaining the FPR result file containing vulnerability information, the FPR result files corresponding to each source code package are merged into a single code scanning result file.

9. The apparatus according to claim 6, characterized in that, The various source code packages belong to the same microservice project, and the various source code packages are stored in the same microservice directory.

10. The apparatus according to claim 9, characterized in that, The JAR file folder is located in the microservice directory.

11. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-5.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-5.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

Images