Software bill of material analysis method and system, medium and processor

Abstract

The invention provides a software bill of material analysis method, which comprises the following steps: S1, selecting a software project to be evaluated, and ensuring that a code library of the software project is complete and accessible; s2, scanning the code library and the dependency relationship by adopting an analysis tool, and generating a software component report; s3, identifying a three-party service used in the software project according to the information obtained by scanning the code library and the dependency relationship; s4, according to all the content of the code library obtained through scanning and in combination with the recognized three-party service, self-research codes are accurately distinguished, and the code self-research rate is calculated; and S5, identifying key elements, structures, defects or security vulnerabilities of the codes, comparing the key elements, the structures, the defects or the security vulnerabilities with known correct results or expected results for analysis, and judging the quality of the self-research codes. According to the method, bill of material analysis can be comprehensively and accurately carried out on software projects, self-research codes are clearly defined, three-party services are effectively identified, and code quality is accurately evaluated.

Description

Technical Field

[0001] The present invention relates to the technical field of hose project analysis, and particularly to a software bill of materials analysis method, system, medium and processor. Background Art

[0002] In today's digital age, the software industry is booming, and the scale and complexity of software projects are increasing day by day. Many software projects widely use external resources such as third-party services and open-source libraries during the development process. Although this improves the development efficiency, it also brings many problems to software project management, quality control, and intellectual property protection.

[0003] On the one hand, the code library of software projects is complex, including self-developed code, third-party library code, and various configuration files, resource files, etc. It is difficult for the development team to quickly and accurately grasp the actual composition of the software project and clearly define the scope of self-developed code. For example, in large enterprise-level software projects, there may be hundreds or thousands of dependent libraries, and it is very difficult for developers to sort out the specific uses of each library and its relationship with the self-developed code, which brings great troubles to the subsequent maintenance and upgrade of the project. If the self-developed code and third-party code cannot be accurately distinguished, enterprises will face huge risks when conducting software property rights evaluation and copyright dispute handling.

[0004] On the other hand, software quality problems are becoming increasingly prominent. Due to the lack of effective analysis means, it is difficult to comprehensively evaluate the quality of software code. Existing methods have deficiencies in detecting code defects and security vulnerabilities and cannot detect potential risks in a timely manner. For some common security vulnerabilities, such as SQL injection and cross-site scripting attacks, if not detected before the software goes online, it may lead to serious consequences such as user data leakage and system attacks. At the same time, the evaluation of the rationality of the code structure, such as the coupling degree between modules and the nesting depth of the code, is not accurate enough, affecting the maintainability and scalability of the software.

[0005] In addition, with the wide attention paid to software supply chain security issues, enterprises urgently need to effectively identify and manage the third-party services used in software projects. However, most traditional analysis methods rely on static code analysis and cannot accurately identify third-party services that are only called during dynamic runtime. In actual applications, the invocation of many third-party services depends on specific user operations or running environments, and static analysis is difficult to discover these potential third-party service dependencies, making it impossible for enterprises to comprehensively grasp the security status of software projects and vulnerable to supply chain attacks.

[0006] In summary, there is currently a lack of a method that can comprehensively and accurately perform a bill of materials analysis on software projects, clearly define self-developed code, effectively identify third-party services, and accurately evaluate code quality, and there is an urgent need for new technical solutions to solve these problems.

[0007] In view of this, a software bill of materials analysis method, system, medium and processor are needed. Summary of the Invention

[0008] Aiming at the problem in the prior art that there is a lack of a method for comprehensively and accurately analyzing the bill of materials of software projects, clearly defining self-developed code, effectively identifying third-party services, and accurately evaluating code quality, the present invention provides a software bill of materials analysis method, system, medium and processor, which can comprehensively and accurately analyze the bill of materials of software projects, clearly define self-developed code, effectively identify third-party services, and accurately evaluate code quality. The specific technical solutions are as follows:

[0009] A software bill of materials analysis method includes:

[0010] S1: Select the software project to be evaluated, and ensure that the code library of the software project is complete and accessible;

[0011] S2: Use an analysis tool to scan the code library and dependencies and generate a software component report;

[0012] S3: According to the information obtained by scanning the code library and dependencies, identify the third-party services used in the software project;

[0013] S4: According to all the contents of the scanned code library and in combination with the identified third-party services, accurately distinguish self-developed code and calculate the self-developed code rate;

[0014] S5: Identify the key elements, structures, defects or security vulnerabilities of the code and compare and analyze them with the known correct results or expected results, and judge the quality of the self-developed code.

[0015] Further, in step S3, the identifying the third-party services used in the software project includes the following steps:

[0016] S31: Perform static analysis on the code to construct the control flow graph and data flow graph of the code;

[0017] S32: Design a dynamic execution simulator to simulate the execution process of the code and record key behavior information;

[0018] S33: Define a behavior pattern template for third-party service calls, and match the simulated behavior with the template;

[0019] S34: Make predictions about third-party services according to the matching results.

[0020] Further, in step S33, the matching the simulated behavior with the template includes the following steps:

[0021] S331: Perform symbolic execution or emulation execution on the code, and record various behaviors of the code during runtime in this process;

[0022] S332: A predefined behavior pattern template representing the invocation of third-party services;

[0023] S333: Match the simulated behavior with the template by checking one by one whether the simulated behavior meets the behavior characteristics specified in the template.

[0024] Further, in step S333, the calculation formula for matching the simulated behavior with the template is as follows:

[0025]

[0026] Where M is the matching degree; f sim and n sim are respectively the network request frequency and the number of request parameters in the simulated behavior; f pattern and n pattern are the corresponding values of the network request frequency and the number of request parameters in the third-party service invocation behavior template; α and β are weight coefficients used to adjust the importance of different features in the calculation of the matching degree.

[0027] Further, the calculation formula for the self-developed code rate is as follows:

[0028] Self-developed code rate = (Number of self-developed code lines / Total number of code lines) × 100%.

[0029] Further, the judgment of the quality of self-developed code refers to evaluating the quality of self-developed code by identifying key elements, structures, defects, and security vulnerabilities in the self-developed code.

[0030] Further, the evaluation of the quality of self-developed code by identifying key elements, structures, defects, and security vulnerabilities in the self-developed code includes the following steps:

[0031] S51: Calculate the defect evaluation score, and the formula is as follows:

[0032]

[0033] In the above formula, DS is the defect evaluation score; DD weight is the weight of the defect density, and DD [[ID=:47]] weight + DRR weight = 1; DD is the defect density; DD max is the maximum value of the defect density; DRR weight is the weight of the defect repair rate; DN represents the number of self-developed code defects; CS represents the code scale; RDN represents the number of repaired defects;

[0034] S52: Calculate the structural evaluation score, with the formula as follows:

[0035]

[0036] In the above formula, SS is the structural evaluation score; MD weight is the weight of the modularity degree and satisfies MD weight +ACD weight = 1; MD norm is the modularity degree after standardization; ACD weight is the weight of the average code nesting depth; ACD is the average code nesting depth; ACD max is the maximum value of the average code nesting depth;

[0037] S53: Calculate the security vulnerability evaluation score, with the formula as follows:

[0038]

[0039] In the above formula, SVS is the security vulnerability evaluation score; n is the total number of discovered security vulnerabilities; S i is the severity score of the i-th security vulnerability; W i is the impact scope weight of the i-th security vulnerability;

[0040] S54: Calculate the comprehensive quality score, with the formula as follows:

[0041] CQS = DS × DW + SS × SW + SVS × SVW;

[0042] In the above formula, CQS represents the comprehensive quality score; DW represents the defect weight; SW represents the structural weight; SVW represents the security weight.

[0043] A software bill of materials analysis system, applied to the software bill of materials analysis method described above, includes:

[0044] A selection module, which is used to select a software project to be evaluated, ensuring that the code library of the software project is complete and accessible;

[0045] A scanning module, which is used to scan the code library and dependencies using an analysis tool and generate a software component report;

[0046] An identification module, which is used to identify the third-party services used in the software project according to the information obtained by scanning the code library and dependencies;

[0047] A differentiation module, which is used to accurately differentiate the self-developed code and calculate the self-developed code rate according to all the contents of the scanned code library and in combination with the identified third-party services;

[0048] An analysis module, which is used to identify key code elements, structures, defects or security vulnerabilities, compare and analyze them with known correct results or expected results, and judge the quality of self-developed code.

[0049] A computer-readable storage medium, which includes a stored program. When the program runs, it controls the device where the computer-readable storage medium is located to execute the software bill of materials analysis method described above.

[0050] A processor, which is used to run a program. When the program runs, it executes the software bill of materials analysis method described above.

[0051] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0052] 1. Accurately analyze software components and clarify property rights: In the prior art, it is difficult to clearly define the boundary between self-developed code and third-party code in a software project. However, this solution can accurately distinguish self-developed code by comprehensively scanning the code library and dependency relationships, and combining specific rules to identify third-party services. According to the formula "self-developed code rate = (number of self-developed code lines / total number of code lines) × 100%", it can accurately calculate the self-developed code rate. Taking a complex enterprise-level software project as an example, this solution can quickly sort out a large number of dependency libraries, clarify the ownership of each part of the code, avoid copyright disputes, provide a solid basis for the enterprise's intellectual property protection, and enable the enterprise to clearly master its own technical assets in the market competition.

[0053] 2. Deeply detect software quality and reduce security risks: Traditional methods have shortcomings in detecting code defects and security vulnerabilities and are difficult to comprehensively evaluate software quality. This solution uses analysis tools, based on built-in algorithms and rules, to deeply identify key code elements, structures, defects and security vulnerabilities, and calculates a comprehensive quality score through defect assessment scores, structure assessment scores, security vulnerability assessment scores, etc. For example, it can accurately detect security risks such as SQL injection and cross-site scripting attacks, and timely discover defects such as code logic errors and syntax errors, helping enterprises prevent risks in advance, ensure the safe and stable operation of software, and improve user experience and corporate reputation.

[0054] 3. Efficiently identify third-party services and strengthen supply chain management: Previous methods relying on static code analysis cannot effectively identify third-party services called during dynamic runtime. This solution uses dynamic behavior simulation and third-party service prediction algorithms. By constructing control flow graphs and data flow graphs, simulating code execution, matching behavior pattern templates, etc., it can accurately predict the usage of third-party services before the code actually runs. This enables enterprises to comprehensively master the software supply chain, timely discover potential risks, ensure the security of the software supply chain, and avoid security incidents and business interruptions caused by third-party service problems.

[0055] 4. Provide comprehensive decision-making support and optimize project management: The existing technologies cannot provide comprehensive and systematic data support for software project management. This solution generates detailed software component reports covering all aspects of software projects. Through the close collaboration among various analysis steps, it provides all-round support for project management, maintenance, and optimization. Managers can understand the overall situation of the project based on the reports and make scientific decisions, such as reasonably arranging development resources, optimizing code structures, formulating security strategies, etc., improving project management efficiency, reducing development costs, and promoting the continuous optimization and upgrading of software projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0057] Figure 1 It is a schematic flowchart of a method for software bill of materials analysis;

[0058] Figure 2 It is a schematic structural diagram of a software bill of materials analysis system. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0060] It should be understood that when used in this specification and the appended claims, the terms "comprises" and "comprising" indicate the presence of the described features, wholes, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0061] It should also be understood that the terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" are intended to include the plural forms.

[0062] It should also be further understood that the term "and / or" used in the specification and appended claims of the present invention refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0063] Example 1

[0064] As Figure 1 shown is a schematic flowchart of a method for software bill of materials analysis, including the following specific steps:

[0065] S1: Select the software project to be evaluated, ensuring that the code library of the software project is complete and accessible; install and configure a suitable analysis tool, and perform corresponding parameter settings according to the programming language and characteristics of the software project.

[0066] Select the software project to be evaluated, ensuring that the code library of the software project is complete and accessible. Install and configure a suitable analysis tool, which should have the ability to comprehensively scan the code library and dependencies. For example, well-known code analysis tools in the current market such as SonarQube, Nessus, Black Duck, JFrog Xray, and Pylint can be selected, and corresponding parameter settings are made according to the programming language and characteristics of the software project.

[0067] SonarQube: This is an open-source code quality management platform that supports multiple programming languages such as Java, C#, Python, JavaScript, etc. It can perform static analysis on the code, detect bugs, vulnerabilities, and code smells (such as methods with too high complexity, duplicate code, etc.) in the code. In software bill of materials analysis, SonarQube can help identify potential problems in the code library, and at the same time, through plugin extensions, it can analyze the dependencies of the code, and can also detect and report the usage of some open-source libraries to provide partial data support for the software component report. For example, it can indicate whether there are known security vulnerabilities in a certain third-party library used in the project, or whether the code quality of a self-developed module meets the standards.

[0068] Nessus: It is mainly used in the field of network security, but can also scan and analyze security vulnerabilities in software code. It has a large vulnerability library and can detect various types of security vulnerabilities such as SQL injection, cross-site scripting attack (XSS), buffer overflow, etc. It is very effective in identifying security vulnerabilities in software projects. For software projects that use external APIs or third-party services, Nessus can check whether there are security risks in these interfaces and services, so as to improve the information about security in the software bill of materials.

[0069] Black Duck: Focuses on software composition analysis and open source license compliance management. It can scan code repositories, identify open source software components used therein, including libraries, frameworks, etc., and provide detailed component information such as names, versions, license types, etc. It is very useful for identifying third-party services in software projects, being able to accurately determine which are open source third-party libraries and whether the use of these libraries complies with license requirements. At the same time, it can also generate comprehensive software composition reports, clearly showing the composition structure of software projects, and is one of the important tools for software bill of materials analysis.

[0070] JFrog Xray: Mainly used for managing software supply chain security and compliance. It can scan dependencies in software projects, including binary files, container images, etc., identify open source components and potential security vulnerabilities therein. By integrating with Artifactory (JFrog's artifact repository management tool), it can monitor and analyze all software components during the process from software development to deployment, helping to generate accurate software composition reports, and plays an important role in identifying third-party services and ensuring the security and compliance of software.

[0071] Pylint: A code analysis tool specifically for the Python language. It can check for syntax errors, code style issues (following PEP 8 specifications, etc.), potential logical errors, etc. in Python code. When analyzing software projects written in the Python language, Pylint can accurately analyze the quality of self-developed code, which is helpful for evaluating the quality of self-developed code when calculating the code self-developed rate, and can also discover possible problems that may occur during the invocation of third-party libraries used in the code.

[0072] Tool selection strategy: For small software projects, if the main focus is on code quality detection and simple dependency analysis, and the project uses a single programming language such as Python, Pylint can be preferred first. It can quickly check the syntax and style of Python code and is helpful for a preliminary assessment of code quality. If the project is of medium size, involves multiple programming languages, and has requirements for code quality management and security vulnerability detection, SonarQube combined with Nessus is a better choice. SonarQube can comprehensively analyze code in multiple languages, and Nessus focuses on security vulnerability scanning. The two working together can meet various requirements. For large and complex projects, especially those involving numerous third-party services and open source components and having high requirements for software composition analysis and license compliance management, Black Duck and JFrog Xray are more suitable. Black Duck can deeply analyze software composition and license compliance, and JFrog Xray can effectively manage software supply chain security to ensure the safe and stable operation of the project.

[0073] Parameter Configuration Example: Taking SonarQube as an example, when analyzing a Java project, for code complexity detection, the "sonar.cpd.exclusions" parameter can be configured as " / test / , / generated / " to exclude the interference of test code and generated code on complexity calculation, making the results more accurately reflect the actual business code complexity. When using Nessus to scan for Web application security vulnerabilities, the "pluginset" parameter can select the "web_app_vuln" plugin set to focus on scanning vulnerabilities related to Web applications, such as SQL injection, XSS attacks, etc., improving the scanning pertinence and efficiency.

[0074] S2: Scan the code repository and dependencies and generate a software composition report

[0075] This is the basic step of the entire software bill of materials analysis. Use the configured analysis tool to comprehensively scan the code repository of the software project to be evaluated. During the scanning process, the analysis tool will traverse all files in the code repository, including source code files, configuration files, resource files, etc. At the same time, the analysis tool will identify the dependencies in the code repository. For example, for a software project developed in the Java language, the analysis tool will identify various Java libraries introduced in the project (such as the Spring framework, Hibernate framework, etc.) and their dependency hierarchy.

[0076] The analysis tool generates a software composition report based on the scanning results. The report content should include detailed information about all software components used in the software project, such as the name, version number, license information, source (self-developed or third-party) of the software component. For example, for a third-party library [library name], the report should clearly show that its version number is [specific version number], the license is [license type], and the source is third-party. The information obtained in this step will provide data support for subsequent analyses.

[0077] Furthermore, the code repository contains all relevant files used to implement software functions during the software development process. The following are detailed listings and descriptions of common code repository file types:

[0078] 1. Source code files, which are the core part of the code repository and contain the specific code to implement software functions. According to different programming languages, source code files have different extensions.

[0079] Java:.java files, such as Main.java, which contain definitions of classes, methods, variables, etc. and are used to implement business logic and functions.

[0080] Python:.py files, such as app.py, which can write functions, classes, and scripts to implement functions such as data processing and algorithm logic.

[0081] JavaScript:.js files, such as script.js, are commonly used in front - end development to implement web page interaction functions and can also be used in back - end development in a Node.js environment.

[0082] C++:.cpp files, such as main.cpp, are used to write complex system - level programs and applications, containing definitions of various classes, functions, and data structures.

[0083] 2. Header files: In some programming languages (such as C and C++), header files are used to declare functions, classes, and variables so that other source files can reference them. The extensions of header files are.h or.hpp. For example, stdio.h is the standard input - output header file in C language, and iostream is the header file for input - output operations in C++.

[0084] 3. Configuration files: Configuration files are files that contain the settings and parameter information required for software or system operation. They allow users or developers to customize and adjust aspects such as the behavior, appearance, and functions of software or systems without modifying the code. For example, in a database management software, through the configuration file, information such as the address, port, username, and password for connecting to different database servers (such as MySQL, Oracle, etc.) can be set, enabling flexible interaction with different databases; the logging level of a website application, originally set to only record important information, can be directly modified in the configuration file if more detailed debugging information is needed later; in a game software, settings such as the game's screen resolution and sound volume can be managed through the configuration file, and the code only responsible for rendering and playing operations according to the settings in the configuration file.

[0085] .properties (commonly used in Java): For example, application.properties, can configure database connection information, system parameters, etc.

[0086] .json: Commonly used in various programming languages, such as config.json, stores configuration information in the form of key - value pairs, with a clear structure and easy to parse.

[0087] .yaml: Such as config.yaml, is also a commonly used configuration file format, representing data structures and configuration information in a concise way.

[0088] 4. Resource files: Contain various non - code resources required for software operation.

[0089] Image files: Images in formats such as.jpg,.png,.gif, etc., are used for interface display, icons, etc.

[0090] Audio files: such as.mp3,.wav, etc., used for the audio playback function in the software.

[0091] Video files: such as.mp4,.avi, etc., used in some video playback software or applications with video functions.

[0092] Text files: such as.txt, may be used to store information such as help documents and log records.

[0093] 5. Library files: Divided into static libraries and dynamic libraries, used for code reuse and providing specific functions.

[0094] Static libraries: In C / C++, the common static library file extensions are.lib (for Windows) or.a (for Linux). They are linked to the executable file during compilation and become part of the executable file.

[0095] Dynamic libraries: The dynamic library file extensions are.dll in Windows,.so in Linux, and.dylib in macOS. Dynamic libraries are loaded at runtime and can be shared by multiple programs.

[0096] 6. Data files: Store the data required for software operation or the data generated.

[0097] Database files: such as the.db file of SQLite, used to store structured data, and the software can perform data addition, deletion, modification, and query operations through database operation statements.

[0098] Log files: such as.log files, record various events and information during software operation, and are used for debugging and troubleshooting.

[0099] These different types of files together constitute the code library. When performing software bill of materials analysis, the analysis tool needs to comprehensively scan and process these files to obtain the complete information of the software.

[0100] In specific implementation, after the analysis tool identifies the dependency relationships in the code library, it presents them in various ways to meet the needs of different users and scenarios. The following are some presentation forms:

[0101] 1. The analysis tool will generate a simple dependency list, clearly listing the names, version numbers, and other basic information of the various libraries or components on which the project depends. This list form is concise and clear, enabling developers to quickly understand the main dependencies of the project.

[0102] 2. Display the dependency relationship in a tree structure to more detailedly reflect the hierarchy of dependencies. The root node is the current project, the child nodes are the directly dependent libraries, and there may be its own dependencies (transitive dependencies) under the child nodes. Through this tree structure, developers can clearly see each dependent library and its underlying dependencies, which helps analyze dependency conflicts and manage transitive dependencies.

[0103] 3. Generate a visual dependency graph, using nodes and edges to represent the relationship between projects and dependent libraries. Nodes represent projects or libraries, and edges represent dependency relationships. For example, in a JavaScript project, the dependency graph generated by the dependency-cruiser tool may show the dependency connections between various modules in the project and between them and external libraries. The dependency graph intuitively presents the overall picture of dependencies, and developers can quickly discover complex dependency relationships and potential problems, such as circular dependencies.

[0104] 4. Display the dependency relationship in the form of a hierarchical chart, arranging the project and dependent libraries in a hierarchy, and representing dependent libraries at different levels with different positions and colors. For example, in a large enterprise-level Java project, the hierarchical chart generated by tools such as SonarQube can clearly show the hierarchical relationship of the project from the top-level module to each sub-module and the external libraries it depends on. This kind of chart helps developers understand the overall architecture of the project and the organization method of dependencies.

[0105] 5. The analysis tool stores the identified dependency relationships in a database, recording the detailed information of each dependency in a structured table form, including project name, dependent library name, version number, dependency type (direct dependency or transitive dependency), introduction time, etc. For example, in a Django project using Python, by using the pipdeptree tool combined with the database storage function, the dependency information of the project can be stored in a MySQL database. This way is convenient for long-term management and query of dependency relationships. Enterprises can analyze the trend of dependency changes in the project and count the usage frequency of dependent libraries through the database query function.

[0106] 6. Some analysis tools are integrated into the integrated development environment (IDE) in the form of plugins to display dependency relationships within the IDE interface. For example, in IntelliJ IDEA, the Maven Helper plugin can display the dependency tree of the project within the IDE. Developers can directly view and analyze dependency relationships in the IDE and can conveniently troubleshoot and resolve dependency conflicts. This integration method allows developers to understand the dependency situation of the project in a timely manner without switching tools during the development process.

[0107] S3: Identify the third-party services used in the software project based on the information obtained from the scanned code library and dependencies.

[0108] Identifying third-party services depends on the information obtained from scanning the code library and dependencies. During the process of scanning the code library, specific rules and algorithms are designed in the analysis tool to identify the third-party services used in the software project.

[0109] For example, for cloud services, the analysis tool will identify the cloud service interfaces called in the project, such as the S3 storage service interface of AWS and the ECS service interface of Alibaba Cloud. By analyzing the call statements of the cloud service interfaces in the code, information such as the name, version, and usage method of the cloud service is determined. These call statements are obtained when scanning the code library. Without a comprehensive scan of the code library, the use of these cloud services cannot be discovered. For external APIs, the analysis tool will identify the call statements of external APIs in the code, such as the call to the Google Maps API. By analyzing the parameters and return values in the call statements, the functions and usage of the external API are determined. Similarly, the discovery of these call statements depends on the scan of the code library. For third-party libraries, the analysis tool will match the information such as the name and version number of the library in the known list of third-party libraries to determine it as a third-party library and record the relevant information. For example, for a third-party library named requests for network requests, the analysis tool will record information such as its reference location and usage frequency in the code library. The identified third-party service information will be supplemented to the software composition report to make the report more complete.

[0110] In specific implementation, when using rules and algorithms to identify the third-party services used in the software project, a dynamic behavior simulation and third-party service prediction algorithm can be used to identify the third-party services. Traditional analysis is mostly based on static code analysis, while the algorithm of this solution will simulate the dynamic execution process of the code. By performing symbolic execution or simulation execution on the code, various behaviors during the execution process of the code are recorded, such as changes in variables, the order of function calls, and the triggering conditions of network requests. Based on these dynamic behavior patterns, it is predicted whether the code will use third-party services at runtime.

[0111] Example: In an Android application, the call of some third-party services may depend on specific user operations (such as clicking a certain button). By simulating the user interaction process of the application and observing the dynamic execution of the code, when a specific operation is triggered, it is analyzed whether a network request to a third-party service will be initiated. If a behavior pattern that conforms to the call of a third-party service is found, it is predicted that the application uses the corresponding third-party service.

[0112] Specifically, it includes the following implementation steps:

[0113] S31: Perform static analysis on the code to construct the control flow graph and data flow graph of the code.

[0114] Control flow graph and data flow graph construction algorithms: When constructing the control flow graph, the depth-first search algorithm can be used. Starting from the program entry point, recursively traverse the code along the function call relationship, record the basic blocks (sequentially executed code segments) of each function and control transfer situations, such as conditional branches, loop structures, etc., so as to construct a complete control flow graph. For the data flow graph, based on the control flow graph, analyze the definition, use, and transfer of variables in each basic block. By solving the data flow equations, determine the data flow information of variables, such as the scope of variables, the points of variable definition, and the points of variable reference, etc., to accurately reflect the flow path of data in the code.

[0115] S32: Design a dynamic execution simulator to simulate the execution process of the code and record key behavior information.

[0116] S33: Define a behavior pattern template for the three-party service call and match the simulated behavior with the template.

[0117] Definition of the behavior pattern template: Taking the common three-party payment service as an example, the behavior pattern template can be defined as follows: The target address of the network request must be a specific interface address of the payment service, such as a certain payment connection "https: / / pay.example.com / api"; the request parameters must include key parameters such as "order_amount" (order amount), "order_id" (order number), "payment_method" (payment method), etc.; before initiating a payment request, a specific initialization function "initPayment()" must be called to initialize the payment environment. These characteristics constitute the behavior pattern template of the payment service and are used to match the simulated behavior.

[0118] S34: Make predictions about the three-party service based on the matching results.

[0119] Furthermore, the matching of the simulated behavior with the template refers to comparing and analyzing various behavior information observed and recorded through the simulation of the code execution process with the pre-set behavior pattern template representing the three-party service call, and judging whether the simulated behavior conforms to the characteristics defined by these templates, so as to determine whether the code uses the corresponding three-party service. It specifically includes the following steps:

[0120] S331: Perform symbolic execution or emulation execution on the code. During this process, various behaviors of the code during runtime are recorded. These behaviors include, but are not limited to, the changes in variables (such as variable assignment and value retrieval operations), the order of function calls (which function is called first, which function is called later, and the nested call relationships between functions), the triggering conditions of network requests (under what circumstances a network request is initiated, such as when the user clicks a certain button or specific conditional judgments are met), the parameters of the network request (the specific data carried in the request), and the target address of the request (to which server the request is sent), etc. For example, during the emulation execution of the code of a mobile application, it is observed that when the user clicks the "Login" button, the code initiates a network request to a specific server address and carries parameters such as the username and password. These information constitute the emulated behaviors.

[0121] S332: A pre-defined behavior pattern template representing the invocation of third-party services. These templates are summaries and abstractions based on the invocation characteristics and behavior rules of known third-party services. Each template contains a series of behavior feature descriptions. For example, the template of a certain third-party payment service may stipulate that the target address of the network request is a specific interface address of this payment service, the request parameters must include information such as the order amount, order number, payment method, etc., and a specific initialization function will be called before the request. These feature descriptions are like a standard pattern used to compare with the emulated behaviors.

[0122] S333: Matching the emulated behaviors with the templates means checking one by one whether the emulated behaviors meet the behavior characteristics stipulated in the templates. If the information such as the network request address, parameters, and triggering conditions in the emulated behaviors match the characteristics described in the templates, or within a certain error range (because there may be some minor differences in actual situations), it is considered that the emulated behaviors match the templates successfully, and thus it is speculated that the corresponding third-party service is used by the code during runtime. For example, if the target address of the network request in the emulated behaviors is the same as the API address of a certain third-party map service and the request parameters also meet the requirements of this map service API, then it can be judged that the code may use this third-party map service.

[0123] By matching the emulated behaviors with the templates, it is possible to predict whether the code will use third-party services based on the results of emulation execution before the code actually runs, providing valuable information for software component analysis and security assessment, etc.

[0124] Furthermore, in step S333, the calculation formula for matching the emulated behaviors with the templates is as follows:

[0125]

[0126] where M is the matching degree; f sim and n sim are respectively the network request frequency and the number of request parameters in the simulated behavior, f pattern and n pattern are the corresponding values in the behavior pattern of the third-party service call. α and β are weight coefficients used to adjust the importance of different features in the calculation of the matching degree. By calculating the matching degree, the similarity between the simulated behavior and the behavior pattern of the third-party service call is judged, and then it is predicted whether the third-party service is used. Method for determining the weight coefficients: The weight coefficients α and β can be determined by the Analytic Hierarchy Process (AHP). First, construct a hierarchical structure model, taking the calculation of the matching degree as the target layer, and the network request frequency and the number of request parameters as the criterion layer. Then, through expert scoring or pairwise comparison, determine the importance weights of the elements in the criterion layer relative to the target layer. For example, after expert evaluation, it is considered that the network request frequency is more critical for judging the third-party service call. α can be set to 0.6 and β can be set to 0.4 to make the calculation of the matching degree more in line with the actual situation.

[0127] S4: Based on the entire content of the scanned code library and combined with the identified third-party services (i.e., non-self-developed parts), accurately distinguish the self-developed code and calculate the code self-developed rate.

[0128] After scanning the entire content of the code library, combined with the identified third-party services (i.e., non-self-developed parts), can the self-developed code be accurately distinguished. Analyzing the self-developed code and calculating the code self-developed rate depends on the results of scanning the code library and the dependency relationships as well as identifying the third-party services. <Q

[0129] The analysis tool classifies the code into self-developed code and third-party code through scanning and analyzing the code library. For the self-developed code, the analysis tool will identify it according to information such as the code structure, naming convention, and comments. For example, for a software project developed in the Python language, the analysis tool will identify the custom functions, classes, and modules in the project as self-developed code.

[0130] Calculate the code self-developed rate of the software. The calculation formula is: code self-developed rate = (number of self-developed code lines / total number of code lines) × 100%. The analysis tool will count the number of self-developed code lines and the total number of code lines and calculate the code self-developed rate according to the formula. For example, if the total number of code lines is 10,000 and the number of self-developed code lines is 6,000, then the code self-developed rate is (6,000 / 10,000) × 100% = 60%. If the third-party services are not accurately identified, the self-developed code part cannot be accurately divided, which will affect the calculation of the code self-developed rate.

[0131] S5: Identify the key elements, structure, defects, or security vulnerabilities of the code and compare and analyze them with the known correct results or expected results, and judge the quality of the self-developed code.

[0132] Use analysis tools to identify key elements in the code (such as core functions, important classes, key variables, etc.), the overall structure of the code (including the call relationships between modules, hierarchical structures, etc.), potential code defects (such as logical errors, syntax errors, null pointer references, etc.), and security vulnerabilities (such as SQL injection, cross-site scripting attack vulnerabilities, etc.), and compare and analyze the relevant analysis reports generated by the analysis tools with known correct results or expected results.

[0133] The analysis tool uses its built-in code analysis algorithms and rules to identify and analyze key elements (such as functions, classes, variables, etc.) and structures (such as the hierarchical structure of the code, the call relationships between modules, etc.) in the code. For example, to analyze the hierarchical structure of the code, it is necessary to obtain the reference relationships between various files and modules in the code library, which is obtained by scanning the code library.

[0134] The analysis tool checks whether there are defects or security vulnerabilities in the code, such as null pointer references, SQL injection vulnerabilities, cross-site scripting attack vulnerabilities, etc. in the code. The analysis tool scans the code according to the known security vulnerability feature library to identify potential security problems. These checks are based on the code content obtained by scanning.

[0135] The analysis tool generates reports on the key elements, structures, defects, and security vulnerabilities of the code. Compare the generated reports with known results or expected results. For example, in the testing phase of a software project, the known expected result is that there are no SQL injection vulnerabilities in the code. If the analysis tool-generated report finds that there is an SQL injection vulnerability, it will mark the problem and compare it with the expected result. The generated reports on the key elements, structures, defects, and security vulnerabilities of the code will also complement the software composition report to further improve the analysis results of the software project.

[0136] Furthermore, the quality judgment of the self-developed code means that by identifying the key elements, structures, defects, and security vulnerabilities in the self-developed code, the quality of the self-developed code can be evaluated. For example, if a large number of security vulnerabilities and logical errors are found in the self-developed code, even if the self-developed rate value is high, it does not mean that the software quality is good. On the contrary, if the key elements of the self-developed code are clear, the structure is reasonable, and there are fewer defects and vulnerabilities, then in the case of a high self-developed rate, the software quality is more guaranteed.

[0137] Furthermore, by identifying the key elements, structures, defects, and security vulnerabilities in the code, the quality of the self-developed code can be evaluated, including the following steps:

[0138] S51: Calculate the defect assessment score, and the formula is as follows:

[0139]

[0140] In the above formula, DS is the defect assessment score, and its value range is usually between 0 and 100. The higher the score, the better the quality of the code in terms of defects; DD weight is the weight of the defect density, and its value range is from 0 to 1, and DD weight +DRR weight = 1. This weight reflects the importance of the defect density in the whole defect assessment. For example, if it is considered that the impact of the defect density on the code quality is more critical, then DD weight can be set to 0.6; DD is the defect density; DD max is the maximum value of the defect density. It is a preset reference value, representing the upper limit of the defect density within the acceptable range. For example, according to past project experience or industry standards, DD max is set to 0.1 defect per line of code; DRR weight is the weight of the defect repair rate, and its value range is also between 0 and 1. It reflects the importance of the defect repair rate in the whole defect assessment. If more importance is attached to the defect repair ability of the development team, DRR weight can be set to 0.6; DRR is the defect repair rate; DN represents the number of self-developed code defects; CS represents the code size (Code Size), which can be measured by the number of lines of self-developed code (LOC), etc.; RDN represents the number of repaired defects. Determination of defect assessment parameters: The maximum value of the defect density can be determined according to industry statistical data and project historical experience. For general enterprise-level Java projects, referring to industry data, if the number of defects in every 1000 lines of code does not exceed 10 on average, the maximum value of the defect density can be set to 0.01 defect per line of code. The weight of the defect repair rate can be adjusted according to the importance attached to the defect repair speed and quality in the project. If the project is in the rapid iteration stage and more attention is paid to the defect repair speed, the weight of the defect repair rate can be set to 0.7; if the project has extremely high requirements for software stability and more importance is attached to the defect repair quality, it can be set to 0.5.

[0141] S52: Calculate the structure assessment score, and the formula is as follows:

[0142]

[0143] In the above formula, SS is the structure assessment score, and its value range is usually between 0 and 100. The higher the score, the better the structure quality of the code;

[0144] MD weight is the weight of the modularity degree, and its value range is from 0 to 1, and satisfies MD weight +ACD weight= 1, and this weight reflects the importance of the modularity level in the overall structure evaluation. For example, if it is considered that modularity has a greater impact on the code structure, MD weight can be set to 0.6;

[0145] MD norm is the standardized modularity level. The modularity level (where MC is the within-module width and IC is the inter-module coupling degree). Since the value range of the modularity level is uncertain, for the convenience of unified calculation and comparison, it needs to be standardized to between 0 and 1. There are various standardization methods. For example, the reasonable range of the modularity level can be determined according to historical project data [MD min , MD max , and then the formula is used for standardization.

[0146] ACD weight is the weight of the average code nesting depth, and its value range is between 0 and 1. It reflects the importance of the average code nesting depth in the overall structure evaluation. If you want to focus on the impact of the code nesting depth on the structure, ACD weight can be set to 0.6.

[0147] ACD is the average code nesting depth (Average Code Nesting Depth), and the calculation formula is where ND i is the depth of the i-th nested structure, and n is the number of nested structures.

[0148] ACD max is the maximum value of the average code nesting depth, which is a preset reference value representing the acceptable average code nesting depth. For example, according to the code specification or experience, ACD max is set to 5.

[0149] Determination of structure evaluation parameters: The standardized range of the modularity level can be determined according to the best practices in the industry where the project is located. For example, in a software project in the financial industry, referring to the modularity level data of excellent projects in the industry, the reasonable range of the modularity level is determined to be [0.3, 0.8]. The maximum value of the average code nesting depth can be set according to the code specification and performance optimization requirements. For Python code, to ensure code readability and performance, the maximum value of the average code nesting depth is usually set to 4. Exceeding this value may lead to complex code logic and difficult maintenance.

[0150] S53: Calculate the security vulnerability assessment score, and the formula is as follows:

[0151]

[0152] In the above formula, SVS is the security vulnerability assessment score; n is the total number of discovered security vulnerabilities; S i is the severity score of the i-th security vulnerability. Usually, it is graded according to the vulnerability type and potential harm level. For example, a high-severity vulnerability is scored 10 points, a medium level is 5 points, a low level is 2 points, etc.; W i is the impact scope weight of the i-th security vulnerability. The impact scope can be considered from aspects such as the affected system function modules, user groups, data sensitivity, etc. The weight value range is generally between 0 and 1. For example, if a certain vulnerability affects the core business process of the system, its impact scope weight may be 0.8. If it only affects some secondary functions, the weight may be 0.2.

[0153] S54: Calculate the comprehensive quality score. The formula is as follows:

[0154] CQS = DS×DW + SS×SW + SVS×SVW;

[0155] In the above formula, CQS represents the comprehensive quality score; DS represents the defect assessment score; DW represents the defect weight; SS represents the structure assessment score; SW represents the structure weight; SVS represents the security vulnerability assessment score; SVW represents the security weight.

[0156] Implementation effect:

[0157] Through the method of the above embodiments, it is possible to comprehensively and accurately perform bill of materials analysis on software projects, and at the same time fully reflect the interdependent relationship between each analysis step. A detailed software component report can be generated to clearly understand the third-party services and self-developed code used in the software project, accurately calculate the self-developed code rate, timely discover key elements, structural problems, defects and security vulnerabilities in the code, and through comparison with the expected results, provide strong support for the management, maintenance and optimization of software projects.

[0158] The method for software bill of materials analysis provided by this application realizes in-depth and efficient analysis of software projects through steps such as comprehensively scanning the code library and dependencies, identifying third-party services, analyzing self-developed code and calculating the self-developed code rate, identifying key elements and security issues in the code and comparing reports, and clarifying the interdependent relationship between each step, and has important practical application value and market prospects.

[0159] Embodiment 2

[0160] As Figure 2 shown, a software bill of materials analysis system applied to the above-mentioned software bill of materials analysis method includes:

[0161] A selection module, which is used to select the software project to be evaluated to ensure that the code library of the software project is complete and accessible;

[0162] A scanning module, which is used to scan the code library and dependencies using an analysis tool and generate a software component report;

[0163] An identification module, which is used to identify third-party services used in a software project according to the information obtained by scanning the code library and dependencies;

[0164] A differentiation module, which is used to accurately differentiate self-developed code and calculate the self-developed code rate according to all the content of the scanned code library and in combination with the identified third-party services;

[0165] An analysis module, which is used to identify key elements, structures, defects or security vulnerabilities of the code, compare and analyze them with known correct results or expected results, and judge the quality of self-developed code.

[0166] Data transfer process: After the selection module selects the software project to be evaluated, it transfers the project code library path information to the scanning module. The scanning module reads the content of the code library according to the path. After the scanning is completed, it transfers the software component report data (including various file information, dependencies, etc. in the code library) to the identification module and the differentiation module. The identification module uses this data to identify third-party services and transfers the identification results to the differentiation module. The differentiation module combines the scanning data and the third-party service identification results, differentiates self-developed code and calculates the self-developed code rate, and transfers the results to the analysis module. The analysis module identifies key elements, structures, defects and security vulnerabilities of the code according to this data, and after comparing and analyzing with the known results, generates a code quality evaluation report to complete the entire data transfer and processing process.

[0167] Embodiment III

[0168] A computer-readable storage medium, the computer-readable storage medium includes a stored program, wherein, when the program runs, it controls the device where the computer-readable storage medium is located to execute the software bill of materials analysis method described above.

[0169] Embodiment IV

[0170] A processor, the processor is used to run a program, wherein, when the program runs, it executes the software bill of materials analysis method described above.

[0171] Compared with the prior art, the beneficial effects of the present invention are:

[0172] 1. Accurately analyze software components and clarify property rights: It is difficult for existing technologies to clearly define the boundaries between self-developed code and third-party code in software projects. However, this solution can accurately distinguish self-developed code by comprehensively scanning the code library and dependencies, and identifying third-party services based on specific rules. According to the formula "self-developed code rate = (number of self-developed code lines / total number of code lines) × 100%", the self-developed code rate can be accurately calculated. Taking a complex enterprise-level software project as an example, this solution can quickly sort out a large number of dependent libraries, clarify the ownership of each part of the code, avoid copyright disputes, provide a solid basis for enterprise intellectual property protection, and enable enterprises to clearly grasp their own technical assets in the market competition.

[0173] 2. Deeply detect software quality and reduce security risks: Traditional methods have limitations in detecting code defects and security vulnerabilities and are difficult to comprehensively evaluate software quality. This solution uses analysis tools to deeply identify key elements, structures, defects, and security vulnerabilities in the code based on built-in algorithms and rules, and calculates a comprehensive quality score through defect assessment scores, structure assessment scores, security vulnerability assessment scores, etc. For example, it can accurately detect security risks such as SQL injection and cross-site scripting attacks, and promptly discover defects such as code logic errors and syntax errors, helping enterprises prevent risks in advance, ensure the safe and stable operation of software, and improve user experience and enterprise reputation.

[0174] 3. Efficiently identify third-party services and strengthen supply chain management: Previous methods relying on static code analysis cannot effectively identify third-party services called during dynamic runtime. This solution uses dynamic behavior simulation and third-party service prediction algorithms to accurately predict the usage of third-party services before the code actually runs by constructing control flow graphs and data flow graphs, simulating code execution, and matching behavior pattern templates. This enables enterprises to comprehensively master the software supply chain, promptly discover potential risks, ensure the security of the software supply chain, and avoid security incidents and business interruptions caused by third-party service problems.

[0175] 4. Provide comprehensive decision-making support and optimize project management: Existing technologies cannot provide comprehensive and systematic data support for software project management. This solution generates a detailed software component report covering all aspects of the software project, and provides all-round support for project management, maintenance, and optimization through the close cooperation between various analysis steps. Managers can understand the overall situation of the project based on the report and make scientific decisions, such as reasonably arranging development resources, optimizing code structure, and formulating security strategies, improving project management efficiency, reducing development costs, and promoting the continuous optimization and upgrading of software projects.

[0176] 5. Improve development efficiency and accelerate project iteration: During the software development process, developers can use this solution to quickly understand the third-party services relied on by the project, reducing the time spent exploring unknown dependencies. For example, when developing new features, they can quickly determine which parts can reuse third-party services and which need to be developed in-house, avoiding duplicate development. At the same time, through code quality assessment, the development team can accurately locate and prioritize the repair of critical defects and optimize the code structure, improving code readability and maintainability, making subsequent development and modification more efficient. This helps the project speed up the iteration speed, quickly respond to market demands, and enhance the enterprise's competitiveness in the market.

[0177] 6. Promote the standardized development of the software industry: The indicators and methods such as the calculation of the in-house code research rate and code quality assessment involved in this solution provide a unified quantitative standard for the software industry. Enterprises can objectively evaluate their own software projects based on these standards, conduct comparative analysis with other projects in the industry, identify gaps, and learn from excellent experiences. This is conducive to promoting the formation of standardized norms in aspects such as code management and quality control in the entire software industry, improving the overall level of the industry, and promoting the healthy and orderly development of the software industry.

[0178] 7. Adapt to the development needs of emerging technologies: With the continuous emergence of emerging technologies such as cloud computing, big data, and artificial intelligence, the architectures and development models of software projects are becoming increasingly complex. The flexibility and scalability of this solution enable it to adapt to these changes. For example, in software projects based on cloud computing, it can accurately identify the usage of cloud services; for big data projects, it can effectively analyze the key elements and structures in massive amounts of code. This provides strong technical support for the wide application of emerging technologies in the software field and ensures the smooth progress of emerging technology projects.

[0179] This application provides a software bill of materials analysis method, including: S1: Select the software project to be evaluated, ensuring that the code library of the software project is complete and accessible; S2: Use an analysis tool to scan the code library and dependencies and generate a software component report; S3: Identify the third-party services used in the software project based on the information obtained from scanning the code library and dependencies; S4: Accurately distinguish the in-house developed code and calculate the in-house code research rate based on all the content of the scanned code library and the identified third-party services; S5: Identify the key elements, structures, defects, or security vulnerabilities in the code and conduct comparative analysis with the known correct results or expected results, and judge the quality of the in-house developed code. It can comprehensively and accurately perform a bill of materials analysis on the software project, clearly define the in-house developed code, effectively identify third-party services, and accurately evaluate the code quality.

[0180] Those of ordinary skill in the art can realize that the units of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition of each example has been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0181] In the embodiments provided by the present invention, it should be understood that the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units can be combined into one unit, one unit can be split into multiple units, or some features can be ignored, etc.

[0182] In addition, the functional units in each embodiment of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0183] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0184] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of each embodiment of the present invention, and they should all be covered by the scope of the claims and the description of the present invention.

Claims

1. A software bill of materials analysis method, characterized in that, Including: S1: Select the software project to be evaluated, ensuring that the code library of the software project is complete and accessible; S2: Use an analysis tool to scan the code library and dependencies and generate a software component report; S3: Based on the information obtained from scanning the code library and dependencies, identify the third-party services used in the software project; S4: Based on all the content of the scanned code library and combined with the identified third-party services, accurately distinguish the self-developed code and calculate the self-developed code rate; S5: Identify the key elements, structures, defects or security vulnerabilities of the code and conduct a comparative analysis with the known correct results or expected results, and judge the quality of the self-developed code.

2. The software bill of materials analysis method according to claim 1, wherein In step S3, the identification of the third-party services used in the software project includes the following steps: S31: Conduct static analysis on the code to construct the control flow graph and data flow graph of the code; S32: Design a dynamic execution simulator to simulate the execution process of the code and record the key behavior information; S33: Define the behavior pattern template for third-party service calls, and match the simulated behavior with the template; S34: Make a prediction of the third-party service according to the matching result.

3. The software bill of materials analysis method according to claim 2, wherein In step S33, the matching of the simulated behavior with the template includes the following steps: S331: Conduct symbolic execution or simulated execution on the code, and record various behaviors of the code during runtime in this process; S332: The predefined behavior pattern template representing third-party service calls; S333: Match the simulated behavior with the template by checking one by one whether the simulated behavior meets the behavior characteristics specified in the template.

4. The software bill of materials analysis method according to claim 3, wherein In step S333, the calculation formula for matching the simulated behavior with the template is as follows: Among them, M is the matching degree; f sim and n sim are respectively the network request frequency and the number of request parameters in the simulated behavior; f pattern and n pattern are the corresponding values of the network request frequency and the number of request parameters in the third-party service call behavior template; α and β are weight coefficients used to adjust the importance of different features in the calculation of the matching degree.

5. The software bill of materials analysis method according to claim 1, characterized in that The calculation formula for the self-developed code rate is as follows: Self-developed code rate = (Number of self-developed code lines / Total number of code lines) × 100%.

6. The software bill of materials analysis method according to claim 1, wherein The judgment of the quality of the self-developed code refers to evaluating the quality of the self-developed code by identifying the key elements, structures, defects and security vulnerabilities in the self-developed code.

7. The software bill of materials analysis method according to claim 6, characterized in that The evaluation of the quality of the self-developed code by identifying the key elements, structures, defects and security vulnerabilities in the self-developed code includes the following steps: S51: Calculate the defect evaluation score, and the formula is as follows: In the above formula, DS is the defect assessment score; DD weight is the weight of the defect density, and DD weight + DRR weight = 1; DD is the defect density; DD max is the maximum value of the defect density; DRR weight is the weight of the defect repair rate; DN represents the number of self-developed code defects; CS represents the code size; RDN represents the number of repaired defects; S52: Calculate the structure evaluation score, and the formula is as follows: In the above formula, SS is the structural evaluation score; MD weight is the weight of the modularity degree and satisfies MD weight + ACD weight = 1; MD norm is the modularity degree after standardization; ACD weight is the weight of the average code nesting depth; ACD is the average code nesting depth; ACD max is the maximum value of the average code nesting depth; S53: Calculate the security vulnerability evaluation score, and the formula is as follows: In the above formula, SVS is the security vulnerability assessment score; n is the total number of discovered security vulnerabilities; S i is the severity score of the i-th security vulnerability; W i is the impact scope weight of the i-th security vulnerability; S54: Calculate the comprehensive quality score, and the formula is as follows: CQS = DS × DW + SS × SW + SVS × SVW; In the above formula, CQS represents the comprehensive quality score; DW represents the defect weight; SW represents the structure weight; SVW represents the security weight.

8. A software bill of materials analysis system, characterized in that, Applied to the software bill of materials analysis method according to any one of claims 1 to 7, including: A selection module, which is used to select the software project to be evaluated, ensuring that the code library of the software project is complete and accessible; A scanning module, which is used to use an analysis tool to scan the code library and dependencies and generate a software component report; An identification module, which is used to identify the third-party services used in the software project according to the information obtained from scanning the code library and dependencies; A distinguishing module, which is used to accurately distinguish self-developed code and calculate the self-developed code rate according to all the contents of the scanned code library in combination with the identified third-party services; An analysis module, which is used to identify key elements, structures, defects or security vulnerabilities of the code, compare and analyze them with known correct results or expected results, and judge the quality of the self-developed code.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein when the program runs, it controls the device where the computer-readable storage medium is located to execute the software bill of materials analysis method according to any one of claims 1 to 7.

10. A processor, characterized in that, The processor is used to run a program, wherein when the program runs, it executes the software bill of materials analysis method according to any one of claims 1 to 7.

Images