Information security software protection method

Abstract

This invention discloses a method for protecting information security software, belonging to the field of information security technology. This method constructs a unified cross-language code attribute graph and combines it with a domain-adaptive graph neural network encoder to map code implementation and business intent to a unified semantic space. It calculates the degree of semantic consistency offset and performs threshold judgment to identify vulnerabilities that are syntactically correct but logically deviate from the true intent. Based on the comparison results between the software bill of materials and the vulnerability database, it combines a static call graph constructed by class hierarchy analysis and rapid type analysis with symbolic execution technology to jointly calculate the comprehensive reachability score of the call chain. It blocks vulnerabilities in truly reachable third-party components during the construction phase. By combining official package repository authenticity verification, reputation feature evaluation, and reverse reasoning from a large language model, it calculates a package name poisoning risk score and proactively intercepts fictitious package names during the dependency introduction phase. This invention can identify hidden logical defects in AI-generated code at the semantic level.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and specifically to an information security software protection method. Background Technology

[0002] With the widespread application of large language models in assisted programming, software development models have undergone significant changes. Developers increasingly rely on artificial intelligence models to automatically generate code snippets, complete function logic, and even independently complete module development. At the same time, enterprise projects are increasingly adopting open-source components to improve development efficiency. Meanwhile, software supply chain security audits based on software bill of materials and software composition analysis, as well as security protection measures based on static application security testing and dynamic application security testing, have become indispensable components of the software development lifecycle.

[0003] Existing technical solutions that are similar to this invention mainly fall into two categories. The first category is static and dynamic security testing methods based on rule matching and taint analysis. The general process is as follows: First, the target source code is subjected to lexical and syntactic analysis to generate an abstract syntax tree. Then, pattern matching is performed on the syntax tree or runtime data stream based on a pre-written vulnerability feature rule base. For taint analysis tools, external input data is further marked and its propagation path in the program is tracked to determine whether it flows into sensitive operations without being filtered, thereby outputting vulnerability alerts. Since this type of method essentially relies on syntax pattern matching or taint propagation rules for detection, its detection logic does not understand the real business intent corresponding to the code. Therefore, when the code generated by artificial intelligence is completely legal in syntactic structure, but its internal logical judgment conditions deviate from the real business requirements, existing tools cannot establish a semantic relationship between the code implementation and the business intent. As a result, it is difficult to effectively identify security defects formed by such syntactically correct but logically deviating from the real intent, forming a detection blind spot.

[0004] The second type is based on software bill of materials and software component analysis. Its general process is as follows: First, scan the project dependency manifest file to generate a list of third-party components and their versions used by the project. Then, compare the version number of this list with the publicly available vulnerability database. If the component version matches the known vulnerability version range, an alert is directly output for developers to manually investigate and handle. Since this type of method only performs a static comparison between the component version number and the vulnerability database, and does not combine the actual function call relationship of the project to determine whether the vulnerable code will be actually triggered by the business logic, even if a vulnerable function is not called in the project, this method will still output an alert, resulting in a large number of invalid alerts, consuming the investigation efforts of the development personnel, and reducing the response efficiency of the security team to real high-risk vulnerabilities.

[0005] Furthermore, existing dependency import processes generally lack proactive verification mechanisms for the authenticity and credibility of newly added package names. Attackers can exploit the phenomenon of generating non-existent third-party component package names using large language models, pre-register malicious packages with the same name in public repositories, and induce developers to mistakenly import them, forming a new supply chain poisoning method. Existing technologies cannot determine whether a package name is generated by artificial intelligence illusions or assess its credibility risk during the dependency import construction stage. At the same time, existing security analysis solutions are mostly designed with parsers and rule bases for single programming languages, making it difficult to directly migrate to hybrid projects composed of multiple programming languages ​​and failing to form a unified semantic-level security protection capability. Summary of the Invention

[0006] The technical problem this invention aims to solve is that existing software security protection methods have gaps in their capabilities when dealing with new security threats in AI-assisted programming scenarios. Specifically, they are unable to identify vulnerabilities that are syntactically correct but whose business logic deviates from the true intent; the lack of joint verification of call chain reachability in software supply chain security testing leads to a high false alarm rate; there is a lack of technical means to actively identify and intercept fictitious package names during the software construction phase; and existing single-language customization solutions are difficult to form a unified semantic-level protection capability for multi-language mixed projects.

[0007] To address the aforementioned technical problems, this invention provides an information security software protection method. This method is deployed as a whole in the integrated development environment coding phase and continuous integration and continuous delivery construction phase of software development. It consists of three collaborative processing steps, all of which share a unified multi-language code parsing and graph construction result.

[0008] The first part is the intent-implementation consistency verification steps: Obtain the multi-language source code files of the target software project, generate abstract syntax trees, control flow graphs, and program dependency graphs respectively, and fuse them according to a unified node and edge semantic specification to construct a unified cross-language code attribute graph. Extract the business intent description text associated with the target code fragment, use a large language model to perform semantic refinement to obtain a structured intent description, input the unified cross-language code attribute graph into a domain-adaptive fine-tuned graph neural network encoder to obtain code semantic embedding vectors, input the structured intent descriptions into a text encoder to obtain intent semantic embedding vectors, project both into a unified semantic space of the same dimension, calculate the semantic consistency offset between the two vectors, and compare them with a preset threshold to determine whether there are vulnerabilities that are syntactically correct but logically deviate from the business intent.

[0009] The second part is the joint verification steps for dynamic reachability: parsing the software bill of materials and comparing it with the vulnerability database to obtain candidate high-risk components; constructing a global static function call graph based on class hierarchy analysis and fast type analysis and performing pruning and compression; finding the call path from the entry function to the vulnerable function to obtain static reachability flags; using symbolic execution technology to solve the path constraints for the static reachable paths to obtain symbolic reachability flags; combining environmental context information to perform weighted calculation of the two types of reachability flags to obtain a comprehensive reachability score; and based on this, performing differentiated blocking in the continuous integration and continuous delivery build phase.

[0010] The third part is the steps to prevent package name hijacking: listen for dependency manifest file change events, call the official package repository interface to verify the existence of newly added package names, obtain reputation features such as registration duration, historical download volume, and maintainer identity authentication level for real package names, and use a large language model to perform reverse reasoning on package names to obtain illusion matching degree. Combine reputation features and illusion matching degree to calculate package name poisoning risk score, and based on this, actively block the introduction of high-risk dependency packages during the build stage.

[0011] The technical effects achieved by this invention include:

[0012] 1. By constructing a unified cross-language code attribute graph and combining it with a domain-adaptive graph neural network encoder, the code implementation and business intent are mapped to a unified semantic space for comparison. This enables the accurate capture of grammatically correct but logically deviating vulnerabilities at the semantic level, thus filling the blind spots of traditional detection tools.

[0013] 2. By combining static call graph analysis and symbolic execution with software bill of materials version comparison for joint verification of call chain reachability, high-risk blocking is applied only to vulnerabilities that are truly reachable and meet the triggering conditions, significantly reducing the false alarm rate of security alerts and improving R&D efficiency;

[0014] 3. Through a multi-dimensional cross-validation mechanism that combines official repository authenticity verification, reputation feature assessment, and reverse reasoning from a large language model, it can proactively identify and intercept fictitious dependency packages during the construction phase, cutting off the supply chain poisoning of package name hijacking at the source; 4. By adopting a unified cross-language code attribute graph to uniformly represent multi-language source code, the same set of semantic verification, reachability analysis, and package name verification mechanisms can cover hybrid projects composed of multiple programming languages, forming a unified cross-language security protection capability. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the consistency verification steps of the present invention.

[0016] Figure 2 This is a flowchart of the joint verification steps for dynamic reachability of the present invention;

[0017] Figure 3 This is a flowchart of the steps for preventing packet hijacking and interception in this invention. Detailed Implementation

[0018] The following is in conjunction with the appendix Figure 1-3 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0019] The information security software protection method provided in this embodiment is deployed in the coding phase and the continuous integration and continuous delivery build phase of software development. It consists of three collaborative processing steps: intent-implementation consistency verification, dynamic reachability joint verification, and anti-package name hijacking interception. The three share the underlying multi-language code parsing and graph construction results, and output the protection results through a unified alarm and blocking strategy engine. The multi-language source code input layer receives source files composed of multiple programming languages. After the unified graph construction and parsing layer generates an abstract syntax tree, control flow graph, and program dependency graph and merges them into a unified cross-language code attribute graph, they are respectively input to the functional modules corresponding to the three processing steps. The output results of the three functional modules, namely semantic consistency deviation degree, comprehensive reachability score, and package name poisoning risk score, are jointly converged to the alarm and blocking strategy engine for comprehensive judgment. Finally, the blocking command or the allow command is transmitted to the continuous integration and continuous delivery pipeline to control the continuation or termination of the build process.

[0020] I. Intent - Specific Implementation Methods for Consistency Verification Steps

[0021] This step is used to detect illusionary vulnerabilities in AI-generated code. Its core is to map the code implementation to the business intent and compare them in a unified semantic space.

[0022] First, obtain the set of source code files for the target software project. The set of source code files corresponds to source files written in multiple programming languages. For each programming language, call the corresponding front-end parser to generate an abstract syntax tree, control flow graph, and program dependency graph.

[0023] Secondly, the abstract syntax tree, control flow graph, and program dependency graph mentioned above are integrated according to a unified semantic specification of nodes and edges to construct a unified cross-language code attribute graph for multiple languages, realizing the representation of different language codes in the same graph structure space.

[0024] Next, extract the business intent description text associated with the target code snippet, including natural language information such as requirement document snippets, function-level comments, and interface documents. Use a large language model to semantically refine the above text to obtain a structured semantic description of the business intent.

[0025] Then, the unified cross-language code attribute graph is input into a domain-adaptive fine-tuned graph neural network encoder to obtain the graph semantic embedding vector of the code implementation. Simultaneously, the structured semantic description of the business intent is input into the text encoder to obtain the intent semantic embedding vector. ,and and Projected into a unified semantic space of the same dimension, the graph neural network encoder undergoes domain-adaptive fine-tuning, that is, the pre-trained model parameters are retrained using code and intent-aligned corpora of a specific business domain to improve the encoder's semantic representation capability in a specific business domain.

[0026] Subsequently, the semantic consistency offset distance between the code implementation vector and the business intent vector is calculated as follows:

[0027] ;

[0028] In the formula, This represents the semantic consistency offset distance; a larger value indicates a greater semantic deviation between the code implementation and the business intent. The graph semantic embedding vector represents the code implementation. A semantic embedding vector representing business intent. This represents the dot product of two vectors. and Let represent the magnitudes of the two vectors respectively. Their product is used to normalize the inner product result, making the second term on the right side of the formula equivalent to the cosine similarity between the two vectors.

[0029] Finally, With the preset offset threshold Comparison: If If the code snippet is deemed to be a phantom vulnerability with correct syntax but deviating semantic logic, a security alert will be triggered, and the corresponding unified cross-language code attribute graph node and source code line number will be located. Then determine whether the implementation of the code snippet matches the business intent. Figure 1 If no alarm is triggered, the results of any triggered alarms will be output in a structured manner. The output will include the vulnerability type, offset distance value, the path of the relevant unified cross-language code attribute graph node, and suggested remediation directions, for reference by developers or subsequent automated remediation modules. The preset offset threshold is mentioned above. The specific values ​​can be preset and dynamically adjusted according to specific business scenarios and historical verification data. This invention does not limit the specific values.

[0030] II. Specific Implementation Methods of the Dynamic Reachability Joint Verification Steps

[0031] This step is used to reduce the false alarm rate of vulnerability alerts for third-party components. Its core is to superimpose call chain reachability verification on the basis of software bill of materials version comparison.

[0032] First, the software bill of materials of the target software project is analyzed to obtain all the third-party components that the project depends on and their version information, and then compared with the known vulnerability database to obtain a set of candidate high-risk components.

[0033] Secondly, based on class hierarchy analysis and fast type analysis algorithms, a global static function call graph is constructed starting from the entry function of the software project. Sparse analysis technology is then used to prune and compress the call graph to reduce the analysis complexity.

[0034] Next, search the static call graph for the call path from the entry point to the corresponding vulnerable function of the candidate high-risk component: if at least one call path exists, record the path and set the static reachability flag. If a value of 1 is assigned, and no call path exists, the static reachability flag will be set. The value is assigned to 0.

[0035] Then, regarding the static reachability flag For a call path with a value of 1, symbolic execution is used. The variables in each branch condition along the path are replaced with symbolic values. The path constraints are solved layer by layer along the call path, and it is determined whether the constraints of the path are satisfied under the given input domain. If satisfied, a symbolic reachability flag is added. Assign a value of 1, otherwise set the sign reachability flag. The value is assigned to 0.

[0036] Furthermore, by combining environmental context information, including runtime configuration, deployment environment, and component call triggering conditions, a comprehensive reachability score is calculated:

[0037] ;

[0038] In the formula, This represents the overall accessibility score. This indicates a statically reachable flag, which can be either 0 or 1. This indicates the symbol's reachability flag, which can take the value 0 or 1. and Let represent the weight coefficients corresponding to static reachability and symbolic reachability, respectively, and satisfy . The specific values ​​of these two parameters can be preset according to the degree of trust in the static analysis and dynamic verification results for different business scenarios.

[0039] Finally, With preset blocking threshold Comparison: If If the vulnerability in the third-party component is determined to be genuinely accessible in the current project, a high-risk blocking mechanism will be triggered during the continuous integration and continuous delivery build phase, halting the build process and issuing an alert. If the risk is deemed low, only logs are recorded without blocking the build process, thereby reducing invalid alerts.

[0040] III. Specific Implementation Methods for Preventing Packet Name Hijacking Interception

[0041] This step is used to proactively identify and intercept the poisoning of fictitious package names generated by AI illusions during the dependency introduction phase.

[0042] First, listen for change events in the dependency manifest file in the code repository and extract the package name and version number of the newly added or changed third-party components.

[0043] Secondly, call the open interface of the official package repository of the corresponding language ecosystem to check whether the package name actually exists: if it does not exist, it is directly determined to be a suspected fictitious illusion dependency package; if it exists, continue with the subsequent verification steps.

[0044] Secondly, for existing package names, obtain reputation-related feature data such as the registration duration, historical download volume, maintainer identity authentication information, and code repository association address of the component package.

[0045] Then, leveraging the reverse reasoning capabilities of the large language model itself, the current package name and its context code snippet are re-inputted into the large language model, prompting it to verify whether the package name is a name it might have fabricated due to hallucination, thus obtaining the hallucination matching degree. Its value ranges from 0 to 1, and the larger the value, the more likely the package name is to be an illusion generator.

[0046] Furthermore, by combining the reputation dimension features with the hallucination matching degree, a package name poisoning risk score is calculated:

[0047] ;

[0048] In the formula, This indicates the risk score for poisoning by package name. This represents the normalized score indicating the registration time of the package. A higher value indicates a longer registration time and a higher degree of credibility. This represents the normalized score indicating historical downloads. The normalized score representing the maintainer's authentication level. This represents the degree of hallucination matching obtained through reverse reasoning from a large language model. , , , These are the weight coefficients corresponding to the features mentioned above, and they satisfy... The specific values ​​of each weight coefficient can be preset according to the degree of importance attached to each reputation dimension in different application scenarios.

[0049] Finally, With preset risk threshold Comparison: If If the dependency is identified as a high-risk illusion dependency, its introduction will be proactively blocked during the build phase, and a verified, legitimate alternative will be recommended to the developer. It is determined to be a normal dependency and is allowed to be introduced normally.

[0050] IV. Other Optional Implementation Methods

[0051] In an alternative implementation, the graph neural network encoder in the intent-implementation consistency verification step can be replaced by a Transformer-class joint encoder based on joint pre-training of code and text. This joint encoder encodes the unified cross-language code attribute graph and the structured semantic description of the business intent. It can also obtain code semantic embedding vectors and intent semantic embedding vectors projected onto the same unified semantic space. The semantic consistency offset distance is calculated in the aforementioned manner to achieve the same illusion vulnerability detection effect.

[0052] In another alternative implementation, the symbolic execution step in the dynamic reachability joint verification step can be replaced by runtime dynamic instrumentation or taint tracing technology. That is, the target software project is actually run in the test environment and real function call trajectories are collected. Reachability evidence is obtained by statistically analyzing whether the vulnerable function is actually reached during runtime, which replaces the static solution of path constraints. The remaining logic of static call graph construction, comprehensive reachability score calculation and threshold determination remains unchanged, and joint verification of vulnerability reachability can also be achieved.

[0053] All of the above processing steps and their alternative implementation methods can be deployed collaboratively according to the overall architecture described in this invention, sharing the construction results of a unified cross-language code attribute graph, and achieving unified semantic-level software security protection across languages ​​and stages.

[0054] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for protecting information security software, characterized in that, include: Obtain the source code file set of the target software project. The source code file set corresponds to multiple programming languages. For each programming language, a corresponding front-end parser is used to generate an abstract syntax tree, a control flow graph, and a program dependency graph. The abstract syntax tree, the control flow graph, and the program dependency graph are merged according to a unified semantic specification for nodes and edges to construct a unified cross-language code attribute graph; Obtain the business intent description text associated with the target code fragment, and use a large language model to perform semantic extraction on the business intent description text to obtain a structured semantic description of the business intent; The unified cross-language code attribute graph is input into a domain-adaptive fine-tuned graph neural network encoder to obtain a graph semantic embedding vector of the code implementation. The structured semantic description of the business intent is input into a text encoder to obtain an intent semantic embedding vector. The graph semantic embedding vector and the intent semantic embedding vector are projected onto a unified semantic space of the same dimension. Calculate the semantic consistency offset between the graph semantic embedding vector and the intent semantic embedding vector; When the semantic consistency deviation is greater than the first preset threshold, the target code segment is determined to be a phantom vulnerability that is syntactically correct but logically deviates from the business intent, triggering a security alarm and locating the corresponding unified cross-language code attribute graph node. When the semantic consistency deviation is not greater than the first preset threshold, the implementation of the target code segment is determined to be consistent with the business intent.

2. The information security software protection method according to claim 1, characterized in that, The semantic consistency offset is the difference between 1 and the cosine similarity, which is obtained by dividing the inner product of the graph semantic embedding vector and the intention semantic embedding vector by the product of the magnitudes of the two vectors.

3. A method for protecting information security software, characterized in that, include: The software bill of materials of the target software project is analyzed to obtain the third-party components and their version information that the target software project depends on. The version information is compared with the vulnerability database to obtain a set of candidate high-risk components. Starting with the entry function of the target software project, a global static function call graph is constructed based on class hierarchy analysis and fast type analysis, and the global static function call graph is pruned and compressed. The call path from the entry function to the corresponding vulnerable function of the candidate high-risk component is found in the global static function call graph. When the call path exists, the static reachability flag is set to 1; when the call path does not exist, the static reachability flag is set to 0. For the call path with the static reachability flag set to 1, symbolic execution is used to replace the variables of each branch condition on the call path with symbolic values. The path constraints are solved along the call path. When the path constraints are satisfied under the given input domain, the symbolic reachability flag is set to 1. When the path constraints are not satisfied, the symbolic reachability flag is set to 0. The comprehensive reachability score is calculated by weighted summation of the static reachability flag and the symbolic reachability flag, wherein the weight coefficients in the weighted summation are preset according to the credibility of the static analysis and symbolic execution verification results; When the overall accessibility score is not less than the second preset threshold, the corresponding third-party component vulnerability is determined to be truly accessible in the target software project. In the continuous integration and continuous delivery build phase, a high-risk blocking mechanism is triggered and the build process is terminated. When the overall accessibility score is less than the second preset threshold, the corresponding third-party component vulnerability is determined to be low-risk and the build process is not blocked.

4. The information security software protection method according to claim 3, characterized in that, The comprehensive accessibility score is equal to the product of the first weighting coefficient and the static accessibility flag plus the product of the second weighting coefficient and the symbolic accessibility flag, and the sum of the first weighting coefficient and the second weighting coefficient is 1.

5. A method for protecting information security software, characterized in that, include: Listen for changes to the dependency manifest file in the code repository and extract the package name and version number of newly added third-party components; The system calls the open interface of the official package repository of the corresponding language ecosystem to query whether the third-party component package name actually exists. If the third-party component package name does not exist, it is determined to be an illusion dependency package. If the third-party component package name exists, the system obtains the registration duration, historical download volume, and maintainer identity authentication degree reputation feature data corresponding to the third-party component package name. The system then uses a large language model to perform reverse reasoning on the third-party component package name and its context code snippets to obtain the illusion matching degree. Based on the matching degree between the reputation feature data and the hallucination, calculate the package name poisoning risk score; When the package name poisoning risk score is not less than the third preset threshold, the corresponding third-party component package is determined to be a high-risk illusion dependency package. During the construction phase, the introduction of the third-party component package is blocked and a legitimate alternative package is recommended. When the package name poisoning risk score is less than the third preset threshold, the corresponding third-party component package is determined to be a normal dependency and its introduction is allowed.

6. The information security software protection method according to claim 5, characterized in that, The package name poisoning risk score is calculated as follows: the normalized score of registration duration is subtracted from 1 and then multiplied by the first feature weight coefficient; the normalized score of historical downloads is subtracted from 1 and then multiplied by the second feature weight coefficient; the normalized score of maintainer identity authentication degree is subtracted from 1 and then multiplied by the third feature weight coefficient; the hallucination matching degree is multiplied by the fourth feature weight coefficient; and the products of the above four items are added together to obtain the package name poisoning risk score. The sum of the first feature weight coefficient, the second feature weight coefficient, the third feature weight coefficient, and the fourth feature weight coefficient is 1.

7. A method for protecting information security software, characterized in that, The method includes the intent-implementation consistency verification step as described in claim 1, the dynamic reachability joint verification step as described in claim 3, and the anti-packet name hijacking interception step as described in claim 5. The method is deployed in the coding phase and the continuous integration and continuous delivery build phase of software development. The construction result of the unified cross-language code attribute graph as described in claim 1 and the parsing result of the software bill of materials as described in claim 3 are used together as inputs for the corresponding processing steps. The results of the three steps are output to a unified alarm and blocking strategy engine for comprehensive judgment. Based on the comprehensive judgment result, the type of instruction to be transmitted is determined. The instruction type includes blocking instructions and allowing instructions. The determined instructions are transmitted to the continuous integration and continuous delivery pipeline to control the continuation and termination of the build process.

8. The information security software protection method according to claim 1, characterized in that, The graph neural network encoder is replaced by a Transformer joint encoder based on joint pre-training of code and text. The Transformer joint encoder is used to jointly encode the unified cross-language code attribute graph and the structured semantic description of the business intent to obtain the graph semantic embedding vector and the intent semantic embedding vector projected onto the same dimension unified semantic space.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the information security software protection method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the information security software protection method as described in any one of claims 1 to 8.

Images