A method and apparatus for verifying vulnerabilities in third-party libraries based on reachability analysis

Abstract

This invention discloses a method and apparatus for verifying third-party library vulnerabilities based on reachability analysis, relating to the field of network and system security technology. The method includes: querying a vulnerability database based on the third-party library to obtain candidate vulnerabilities; identifying the actual call types of functional functions in the third-party library from the target code and marking dangerous functions; tracing the call chain from external attack vectors to dangerous functions, performing reachability analysis, and obtaining the call chain reachability status; identifying external input sources, tracing the data flow path of tainted data to dangerous functions, determining whether a security defense mechanism exists, and obtaining the tainted data propagation level; and performing a comprehensive score based on the actual call type, call chain reachability status, and tainted data propagation level to determine the truly exploitable target vulnerability. This invention achieves accurate verification of third-party library vulnerabilities, effectively filters false positives, and significantly improves the efficiency of vulnerability remediation.

Description

Technical Field

[0001] This invention belongs to the field of network and system security technology, and specifically relates to a method and apparatus for verifying vulnerabilities in third-party libraries based on reachability analysis. Background Technology

[0002] With the booming development of open-source software, third-party libraries have become a core component of modern software development. Statistics show that over 80% of the code in modern enterprise applications originates from open-source third-party libraries. However, security vulnerabilities in these libraries pose serious security challenges to software systems. The exposure of well-known vulnerabilities in some third-party libraries has led to severe security threats to a large number of systems worldwide.

[0003] Currently, the industry commonly uses Software Composition Analysis (SCA) tools to scan third-party libraries for vulnerabilities. These tools identify the third-party libraries used by the project and their version numbers by analyzing the project's dependency management files or through binary composition analysis technology. They then match the version information with public vulnerability databases to discover third-party libraries with known vulnerabilities. This version-matching-based scanning method is widely used due to its simplicity and efficiency.

[0004] However, the aforementioned existing technologies have significant drawbacks in practical applications. For example, the SCA tool relies solely on a single judgment mode of version number matching, resulting in a massive number of false alarms. Specifically, when a specific version of a third-party library is reported to have a vulnerability, the SCA tool will determine that all references to that version are vulnerable, completely ignoring the following key factors: (1) whether the target code actually calls the specific function involved in the vulnerability; (2) whether the call chain from the external attack vector to the dangerous function is complete and uninterrupted; and (3) whether the data input by the attacker can actually flow into the dangerous function. According to statistics, the false alarm rate for such vulnerabilities is as high as 80%-90%, and only a small number of vulnerabilities are truly exploitable. Security teams are forced to invest a lot of manpower in dealing with these false vulnerabilities, resulting in real high-risk vulnerabilities being overwhelmed by a massive number of alerts and unable to be responded to in a timely manner. The security protection efficiency is extremely low, security decisions are seriously inaccurate, and business continuity is also damaged due to frequent emergency repair operations. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a method and apparatus for verifying third-party library vulnerabilities based on reachability analysis. By introducing a three-layer progressive screening mechanism, namely, actual call identification of function functions of third-party libraries, call chain reachability analysis, and taint data propagation analysis, it can achieve accurate positioning from "library-level vulnerabilities" to "function-level vulnerabilities" and then to "path-level vulnerabilities". It can effectively filter false positives and enable security teams to focus on truly exploitable high-risk vulnerabilities.

[0006] One aspect of the present invention provides a method for verifying vulnerabilities in third-party libraries based on reachability analysis, comprising the following steps: Preliminary scanning steps: In response to a vulnerability scanning task request, scan the target code repository and identify the third-party libraries used by the target code repository, and query the vulnerability database based on the third-party libraries to obtain candidate vulnerabilities; Actual call identification steps: Perform code scanning on the third-party libraries involved in the candidate vulnerabilities, identify the actual call types of the code in the target code library to the functional functions in the third-party library, and mark the called functional functions as dangerous functions or safe functions; Call chain analysis steps: trace the call chain from the external attack vector to the dangerous function, perform reachability analysis on the call chain using a differentiated tracing strategy, obtain the reachability status of the call chain, and determine the dangerous function that can be actually triggered based on the reachability status of the call chain; Taint analysis steps: For dangerous functions that can be actually triggered, identify the corresponding external input source based on the call chain, trace the data flow path of tainted data from the external input source to the dangerous function, determine whether there is a security defense mechanism on the data flow path, and determine the propagation level of tainted data in combination with the nature of the external input source; Comprehensive judgment steps: Based on the actual call type of the function in the third-party library, the reachability status of the call chain, and the propagation level of the tainted data, the candidate vulnerability is comprehensively scored, and the truly exploitable target vulnerability is determined based on the comprehensive score.

[0007] Another aspect of the present invention provides a third-party library vulnerability verification device based on reachability analysis, comprising: The preliminary scanning module is used to respond to vulnerability scanning task requests, scan the target code library and determine the third-party libraries used by the target code library, and query the vulnerability database based on the third-party libraries to obtain candidate vulnerabilities; The actual call identification module is used to scan the code of the third-party library involved in the candidate vulnerability, identify the actual call type of the code in the target code library to the function in the third-party library, and mark the called function as dangerous function or safe function; The call chain analysis module is used to trace the call chain from the external attack vector to the dangerous function, perform reachability analysis on the call chain using a differentiated tracing strategy, obtain the reachability status of the call chain, and determine the dangerous function that can be actually triggered based on the reachability status of the call chain. The taint analysis module is used to identify the corresponding external input source for dangerous functions that can be actually triggered based on the call chain, track the data flow path of tainted data from the external input source to the dangerous function, determine whether there is a security defense mechanism on the data flow path, and determine the propagation level of tainted data in combination with the nature of the external input source. The comprehensive judgment module is used to comprehensively score the candidate vulnerabilities based on the actual call type of the function in the third-party library, the reachability status of the call chain, and the propagation level of the taint data, and to determine the truly exploitable target vulnerabilities based on the comprehensive score.

[0008] The third-party library vulnerability verification method and apparatus based on reachability analysis provided by this invention have the following beneficial effects: (1) The false positive rate is significantly reduced. This invention uses a three-layer progressive screening mechanism, namely, actual function call identification, call chain reachability analysis, and taint data propagation analysis, to accurately filter a large number of candidate vulnerabilities to a very small number of real exploitable vulnerabilities, which greatly improves the work efficiency of the security team.

[0009] (2) Improved vulnerability identification accuracy. This invention designs differentiated reachability analysis rules for different vulnerability types, rather than using a general static analysis method, which significantly improves the vulnerability identification accuracy in complex business scenarios.

[0010] (3) The vulnerability assessment results are more objective. This invention replaces the traditional subjective mode that relies on manual judgment by security experts with a quantitative scoring mechanism based on three-dimensional weighted scoring. This eliminates the assessment bias caused by differences in the experience of different personnel, making the priority ranking of vulnerabilities more objective, scientific and reproducible, and providing accurate decision-making basis for security management.

[0011] (4) Achieved closed-loop vulnerability management. This invention monitors code changes and configuration drift in real time to prevent patched vulnerabilities from being exposed again due to configuration rollback, thus forming a closed-loop vulnerability lifecycle management system. Attached Figure Description

[0012] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of a third-party library vulnerability verification method based on reachability analysis provided in one embodiment of this application; Figure 2 This is a schematic diagram of the structure of a third-party library vulnerability verification device based on reachability analysis provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] To facilitate an accurate understanding of the technical solution of this invention, the key technical terms used herein are first clearly defined: 1. Third-party libraries This refers to software components that are introduced into the target codebase through dependency management tools and developed and maintained by an entity outside the target codebase's development team.

[0015] 2. Danger Function These are known security vulnerabilities in third-party libraries that could be exploited by attackers. Dangerous functions are typically associated with specific vulnerability types, such as deserialization functions, file manipulation functions, and database query functions.

[0016] 3. Security Function This refers to a function in a third-party library that may have version vulnerabilities, but whose specific implementation does not involve security risks, or whose function cannot be used by attackers to carry out effective attacks.

[0017] 4. Call Chain This refers to the sequence of function calls from the external attack vector entry point to the target dangerous function. The call chain reflects the control flow path of program execution and is the control flow dimension used to determine whether a vulnerability is reachable.

[0018] 5. Accessibility Analysis This refers to the technical process of determining whether an external attack vector can actually trigger a dangerous function by analyzing the integrity of the call chain and the interception mechanisms along the path.

[0019] 6. External attack vectors External attack vectors refer to data sources that can be controlled or influenced by external entities (such as users or another system) and serve as input to a program. External attack vectors include, but are not limited to: network protocol fields (such as HTTP request parameters, request headers, and cookies), file upload content, process environment variables, message queue messages, and data obtained from external APIs. External attack vectors are the interface through which attackers interact with the target program and are also the logical starting point for reachability analysis in this invention.

[0020] 7. External Input Sources This refers to data entry points in the code that can be controlled by external users or systems. These include HTTP request parameters, request bodies, request headers, cookies, file uploads, database query results, external API return data, message queue messages, environment variables, and dynamic values ​​in configuration files. External input sources are the starting point of an attack, while dangerous functions are the endpoint.

[0021] 8. Blemish Data This refers to data originating from external input sources that may contain malicious payloads. The propagation path of tainted data within a program is a data flow dimension used to determine whether a vulnerability is reachable.

[0022] 9. Data Flow Path This refers to the code nodes and processing steps that tainted data passes through from the external input source to the location of the dangerous function parameter. The data flow path includes each function in the function call chain, data processing nodes (such as type conversion, string concatenation, encoding / decoding, filtering functions, validation functions, etc.), and conditional decision branches.

[0023] 10. Security Defense Mechanism Security measures that exist on the data flow path and can block or filter malicious input include, but are not limited to: type filtering, blacklist verification, security context restriction, permission verification annotation, role check code, access control logic, pre-compilation mechanism, parameterized query, and filter escape function.

[0024] 11. Actual Invocation Type This refers to the actual usage of functions in a third-party library by the code in the target code library, including three types: calling dangerous functions, calling safe functions, and not calling any functions.

[0025] 12. Call chain reachability state This refers to the call chain status determined after reachability analysis, including but not limited to four situations: unobstructed path, authorized interception, configuration blocking, and broken path.

[0026] 13. Transmissibility Level of Leaked Data This refers to the degree to which tainted data can be disseminated after taint analysis, including three levels: externally controllable, internally controllable, and uncontrollable.

[0027] 14. Externally controllable This refers to an external input source that is a network interface that can be directly accessed by external users, and there is no security defense mechanism on the data flow path. Tainted data can directly reach dangerous functions without processing, and attackers can directly control the risk level of the input.

[0028] 15. Internally controllable This refers to a situation where the external input source is located inside the system or requires specific permissions to access, and there is no security defense mechanism on the data flow path. Tainted data can flow to dangerous functions, but attackers cannot directly control the risk level of its input.

[0029] 16. Uncontrollable This refers to the risk level where the starting point of the data flow path is a constant within the program or data unaffected by external factors, or where there is a security defense mechanism on the data flow path to block the spread of tainted data.

[0030] 17. Risk Level Label This refers to the risk classification determined for each candidate vulnerability after comprehensive evaluation, including but not limited to types such as confirmed false alarm, low-risk acceptance, medium-risk observation, and high-risk immediate repair.

[0031] 18. Runtime Configuration Items Configuration parameters that are loaded during program runtime and can affect the program's behavior and security status, including but not limited to configuration items in configuration files, environment variables, and startup parameters.

[0032] Example 1 This embodiment details a method for verifying vulnerabilities in third-party libraries based on reachability analysis. For example... Figure 1 As shown, the method mainly includes the following steps: Step S101: Preliminary scanning step.

[0033] This step aims to provide a set of candidate vulnerabilities for subsequent refined analysis. Specifically, it involves initially screening out all potentially risky third-party libraries through version matching, which will then serve as input for the analysis.

[0034] Specifically, firstly, in response to a vulnerability scanning task request, the system scans the target code repository. By analyzing the project's dependency management files (such as pom.xml, package.json, requirements.txt, etc.) or using binary component analysis technology, it determines all third-party libraries used by the target code repository and their version numbers. Subsequently, based on the identified third-party libraries and their version numbers, it performs queries and matches in vulnerability databases (such as CVE, CNVD, NVD, etc.), and identifies the risk records corresponding to third-party libraries whose version numbers fall within the scope of vulnerability impact as candidate vulnerabilities.

[0035] This step quickly obtains a set of all potentially risky candidate vulnerabilities through a one-time version matching, laying the foundation for subsequent multi-layered, progressive screening. Although the candidate vulnerabilities generated in this step contain a large number of false positives, they cover all potential risk points, ensuring the completeness of the analysis.

[0036] Step S102: Actual invocation of the identification step.

[0037] This step aims to address the technical problem of traditional SCA tools that only focus on library versions while ignoring actual function calls, leading to false positives. Its core principle is to use deep code scanning to identify whether the target code actually calls vulnerability-related functions in third-party libraries, thereby refining library-level vulnerabilities into function-level vulnerabilities.

[0038] Specifically, code scanning is performed on the third-party libraries involved in the candidate vulnerabilities obtained in step S101. The business code of the target code library is scanned line by line to identify the actual call points to functional functions in the third-party libraries. The functional functions called by the actual call points are compared with predefined dangerous function libraries, and the actual call type corresponding to each candidate vulnerability is determined based on the comparison results. For example, the actual call types include, but are not limited to, calling dangerous functions, calling safe functions, and not calling functional functions.

[0039] The technical principle behind this step is that different functions within the same third-party library have different security attributes. For example, the `parseObject` function in the Fastjson library has a deserialization vulnerability risk, while the `toJSONString` function is relatively safe. If the target code only calls safe functions or doesn't call any functions of the library at all, then even if the library version has a vulnerability, the vulnerability cannot be actually exploited. Therefore, identifying the vulnerability through actual calls can filter out a large number of false positives caused solely by version matching, significantly reducing the false positive rate. Simultaneously, it provides clear targets for dangerous functions for subsequent call chain analysis.

[0040] Step S103: Invoke the chain analysis step.

[0041] This step aims to address the technical problem of knowing only that a function has been called but not being able to determine whether it can be triggered externally. The underlying principle is that even if the target code calls a dangerous function, if the call chain from the external attack vector entry point to that dangerous function is incomplete (e.g., routes are commented out, conditional branches are never satisfied), or if there are effective interception mechanisms in the call chain (e.g., permission verification annotations, role-based checking code, access control logic), then the dangerous function cannot be actually triggered by an external attacker. Therefore, through call chain analysis, dangerous functions reachable at the control flow level can be further filtered out.

[0042] Specifically, for the dangerous functions identified in step S102 that are actually invoked, the vulnerability scanning system traces the complete call chain from the external attack vector entry point to the dangerous function. A differentiated tracing strategy is used to perform reachability analysis on the call chain, determining its reachability status based on the chain's integrity and the interception mechanisms along the path. The reachability status of the call chain includes, but is not limited to, unobstructed paths, authorized interception, configuration blocking, and broken paths.

[0043] It is important to note that this step employs differentiated tracing strategies for call chain reachability analysis, specifically including: For deserialization vulnerabilities, the system tracks whether external attack vectors can be transmitted to the entry point of the dangerous deserialization function and identifies whether type filtering, blacklist verification, or security context restrictions exist on the data flow path. If the external attack vector cannot be transmitted to the entry point of the dangerous deserialization function, the call chain is considered broken; if the external attack vector can be transmitted to the entry point of the dangerous deserialization function and there are no restrictions, the call chain is considered unobstructed; if the external attack vector can be transmitted to the entry point of the dangerous deserialization function but there are restrictions, the call chain is considered to be configured to be blocked.

[0044] For access control vulnerabilities, trace the complete call chain from the external attack vector entry point to the dangerous function, and identify whether there are permission verification annotations, role checking code, or access control logic on the call chain. If the call chain is incomplete and cannot reach the dangerous function, the call chain path is considered broken; if the call chain is complete and there is no permission verification, the call chain path is considered unobstructed; if the call chain is complete and there is permission verification, permission interception is considered.

[0045] For configuration vulnerabilities, identify the configuration items associated with dangerous functions and their value states, and trace the loading source of the configuration items and whether the configuration items can be modified externally. If the dangerous configuration item associated with the dangerous function is disabled, the call chain is determined to be blocked by configuration; if the dangerous configuration item associated with the dangerous function is enabled but cannot be modified externally, the call chain is determined to be blocked by configuration; if the dangerous configuration item associated with the dangerous function is enabled and can be modified externally, the call chain path is determined to be unobstructed.

[0046] For file operation vulnerabilities, trace the construction process of file path parameters and identify whether the path parameters contain external input, whether there is path traversal filtering, and whether the access directory range is restricted. If the path parameters contain external input and there is no filtering or directory restriction, the call chain path is considered unobstructed; if the path parameters contain external input but there is filtering or directory restriction, the call chain is considered to be configured to be blocked; if the path parameters do not contain external input, the call chain is considered to be configured to be blocked or the path is broken.

[0047] For SQL injection vulnerabilities, trace the SQL statement concatenation process and identify whether prepared statements, parameterized queries, or filtering / escaping functions are used. If prepared statements or parameterized queries are used, the call chain is considered blocked; if prepared statements are not used and there is no filtering / escaping, the call chain path is considered unobstructed; if prepared statements are not used but filtering / escaping exists, the call chain is considered blocked.

[0048] This step further filters out dangerous functions that are unreachable at the call chain level through reachability analysis at the control flow dimension, deepening vulnerability analysis from the function level to the path level. Furthermore, this step designs differentiated reachability analysis rules for different vulnerability types, rather than using a general static analysis method, significantly improving the accuracy of vulnerability identification in complex business scenarios.

[0049] Step S104: Stain analysis step.

[0050] While call chain reachability only indicates that an attacker can trigger the execution of a dangerous function at the control flow level, whether the data processed by the dangerous function during execution is under the attacker's control is another crucial dimension determining whether a vulnerability is truly exploitable. If the data processed by the dangerous function comes from internal constants or local files, and the attacker cannot manipulate this data, then even if the function is executed, it will not cause harm. Conversely, if the data comes from an externally controlled input source with no security defenses along the way, then an attacker can construct a malicious payload directly to the dangerous function, posing a real threat.

[0051] This step uses data flow analysis to trace the data flow path of tainted data from external input sources to dangerous functions, and analyzes the security defense mechanisms along the path to determine the propagation level of the tainted data. Specifically, for dangerous functions identified in step S103 that can be actually triggered, the system identifies the corresponding external input source based on its call chain. Subsequently, it traces the data flow path of tainted data from this external input source to the dangerous function, determining whether there are security defense mechanisms along the data flow path. Combining the nature of the external input source and the determination result of whether there are security defense mechanisms along the data flow path, the propagation level of the tainted data is determined. The propagation level of tainted data includes, but is not limited to, three cases: externally controllable, internally controllable, and uncontrollable. (1) If the external input source is a network interface that can be directly accessed by external users and there is no security defense mechanism on the data flow path, then the tainted data can be propagated to the dangerous function and the attacker can directly control the input of the external input source, which is determined to be the external controllable level.

[0052] (2) If the external input source is located inside the system or requires specific permissions to access, and there is no security defense mechanism on the data flow path, the tainted data can be propagated to the dangerous function, but the attacker cannot directly control the input of the external input source, and it is judged to be internally controllable.

[0053] (3) If the starting point of the data flow path is a constant inside the program or data that is not affected by the outside, or if there is a security defense mechanism on the data flow path, then the tainted data cannot be propagated to the dangerous function and is judged to be uncontrollable.

[0054] This step uses taint analysis at the data flow level to further subdivide dangerous functions reachable by the call chain into three levels: externally controllable, internally controllable, and uncontrollable, providing precise data flow dimension input for the final comprehensive judgment.

[0055] Step S105: Comprehensive judgment step.

[0056] The exploitability of a vulnerability is the result of a comprehensive assessment across multiple dimensions; a single-dimensional analysis cannot provide a complete and accurate conclusion. This step introduces a weighted scoring model to transform the qualitative analysis results from the three dimensions into a quantitative risk score, which is then mapped to an intuitive risk level label. This approach ensures both the objectivity of the assessment and the operability of the decision-making process.

[0057] Specifically, for each candidate vulnerability obtained in step S101, the system assigns a first score and a first weight based on the actual call type obtained in step S102; a second score and a second weight based on the call chain reachability status obtained in step S103; and a third score and a third weight based on the tainted data propagation level obtained in step S104. Then, the system sums the products of the first score and first weight, the second score and second weight, and the third score and third weight for each candidate vulnerability to calculate a comprehensive risk score for each vulnerability. Based on the comprehensive risk score, a risk level label is determined for each candidate vulnerability. Risk level labels include, but are not limited to, four types: confirmed false positive, low-risk acceptable, medium-risk under observation, and high-risk immediate remediation. Candidate vulnerabilities whose risk levels meet preset conditions (such as the high-risk immediate remediation type) are identified as truly exploitable target vulnerabilities.

[0058] This step provides a clear risk level label for each candidate vulnerability, enabling security teams to quickly focus on the real threats from a massive number of alerts and achieve precise responses. At the same time, the multi-dimensional quantitative scoring provides security management with a scientific basis for decision-making.

[0059] Furthermore, it also includes step S106: continuous monitoring step.

[0060] Software system security is a dynamic and evolving state, not a static conclusion. New code submissions may introduce new vulnerabilities or create new attack paths; the disclosure of new vulnerabilities may render previously secure libraries dangerous; changes to configuration items may cause previously effective defense mechanisms to fail. Therefore, only by establishing a continuous monitoring mechanism can we ensure that the vulnerability risk status always reflects the true security condition of the system.

[0061] This step establishes a continuous monitoring mechanism to monitor code changes, vulnerability intelligence updates, and configuration item changes in real time, and automatically triggers a reassessment when changes are detected, ensuring the timeliness and accuracy of vulnerability risk status.

[0062] Specifically, the continuous monitoring process includes the following three monitoring mechanisms: (1) Code Change Monitoring: Monitor code changes in the target codebase. When a new third-party library is detected, execute steps S101 to S105 for the new third-party library, which is the complete vulnerability verification process. When an existing third-party library is detected to generate a new function call point, re-execute steps S103 and S104 for the function, which are the call chain analysis step and the taint analysis step, and update the reachability status of its call chain and the propagation level of taint data according to the analysis results.

[0063] (2) Vulnerability intelligence monitoring: Monitor the updates of the vulnerability database. When new vulnerability information is detected, the new vulnerability will be automatically matched with the existing third-party libraries in the target code library. For the successfully matched candidate vulnerabilities, steps S102 to S105 will be executed, namely the actual call identification step, the call chain analysis step, the taint analysis step, and the comprehensive judgment step.

[0064] (3) Configuration drift monitoring: Monitor changes in configuration items during target code runtime. When a change in a configuration item related to the original security defense mechanism is detected, re-determine whether the change in the configuration item causes the original security defense mechanism to fail. If it fails, re-execute steps S103 and S104, namely the call chain analysis step and the taint analysis step, for the affected function, and update the reachability status of its call chain and the propagation level of taint data.

[0065] This step establishes a closed-loop vulnerability lifecycle management system through a triple mechanism of code change monitoring, vulnerability intelligence synchronization, and configuration drift detection. This ensures that the system's security status remains under control and greatly reduces dynamic security risks caused by code iteration, intelligence updates, and configuration changes.

[0066] The method of the present invention will be described in detail below through a specific application embodiment. This embodiment is only one of the many possible application scenarios of the present invention and does not constitute a limitation on the scope of protection of the present invention.

[0067] A bank's core transaction system required vulnerability scanning of third-party libraries. The system's codebase comprises approximately 5 million lines and involves 1200 third-party libraries. The security team consists of 5 people, and traditional SCA tools reported 1500 candidate vulnerabilities.

[0068] (1) Preliminary scanning steps The system received a timed vulnerability scanning task request, scanned the code repository of the bank's core system, and determined the list and version numbers of the third-party libraries used by analyzing the project's dependency management files. Some results are shown below: Spring Boot 2.7.0 Apache Commons IO 2.6 Fastjson 1.2.83 Log4j 2.14.1 ... (1200 in total) The aforementioned third-party libraries and their version numbers were matched with the vulnerability database to obtain a list of 1,500 candidate vulnerabilities.

[0069] (2) Actual call identification steps Code scanning was performed on the third-party libraries involved in the candidate vulnerabilities to identify the actual calls made by the target code to the functionalities within those libraries. Taking Fastjson 1.2.83 as an example, the scan revealed: Location A: payment-service / PaymentParser.java, line 45, code JSONObject.parseObject(userInput), calls the dangerous function parseObject.

[0070] Location B: report-service / ReportGenerator.java, line 120, code JSON.toJSONString(data), calls the safe function toJSONString.

[0071] Location C: internal-tool / ConfigLoader.java, line 80, code JSONObject.parseObject(fileContent), calls the dangerous function parseObject, but fileContent is read from a local configuration file.

[0072] The other 200 references indicate that no function was called.

[0073] Based on the comparison results, the actual call type corresponding to each candidate vulnerability was determined: Locations A and C were for calling dangerous functions, Location B was for calling safe functions, and the other 200 were for calling unused functions.

[0074] (3) Call chain analysis steps Call chain tracing and reachability analysis are performed on the identified dangerous functions.

[0075] 1) Regarding location A (Fastjson deserialization vulnerability) Tracing the call chain: from the external HTTP request / api / payment / parse → PaymentController.parse() → PaymentParser.parse() line 45.

[0076] Analysis of the interception mechanism: The call chain is complete, but there are no permission verification annotations or access control logic along the way.

[0077] Result: The call chain path is unobstructed.

[0078] 2) Regarding position C (Fastjson deserialization vulnerability) Call chain tracing: This function is called by the internal scheduler when the system starts up, and there is no external attack vector entry point.

[0079] Analysis of the interception mechanism: The call chain starts from the internal scheduler, and there is no external reachable path.

[0080] Result: Call chain path broken.

[0081] 3) Regarding Log4j vulnerabilities (JNDI injection) Identify the dangerous function: logger.info internally calls JndiLookup.lookup.

[0082] Tracing the call chain: From the external HTTP request / api / user / login → LoginService.log() → Then go to logger.info.

[0083] Analysis of the interception mechanism: The call chain is complete, but the global configuration log4j2.format Msg NoLook ups=true disables JNDI lookup.

[0084] Result: The call chain is blocked by the configuration.

[0085] 4) Regarding the Apache Commons IO vulnerability (directory traversal): Identify the dangerous function: FileUtils.copyDirectory.

[0086] Tracing the call chain: External HTTP request / api / batch / upload → Batch Controller.handleRequest() → FileProcessor.processBatch() line 60.

[0087] Analysis of the interception mechanism: The call chain contains the @PreAuthorize ("hasRole ('ADMIN')") permission verification annotation.

[0088] Judgment result: The call chain has the authority to intercept.

[0089] Based on the above analysis, the dangerous function that can be actually triggered is: only position A satisfies the condition of a smooth call chain path.

[0090] (4) Stain analysis steps Perform taint analysis on the dangerous function (position A) that can be actually triggered: Identify the external input source: The userInput on line 45 comes from line 42, String userInput = request.getParameter("paymentData"). This parameter comes from an external HTTP request, which is a network interface that can be directly accessed by external users.

[0091] Trace the data flow path: paymentData → userInput → parseObject parameter.

[0092] Security defense mechanisms are checked in line 43: `if (userInput == null) return` (empty check, no defense mechanism); and line 44: `userInput.trim()` (removes whitespace, no defense mechanism). There is no type filtering, no blacklist validation, and no escaping.

[0093] Propagability level determination: If the external input source is an external network interface and there is no security defense mechanism on the data flow path, tainted data can be propagated to dangerous functions and attackers can directly control its input, it is determined to be at the externally controllable level.

[0094] (5) Comprehensive Judgment Steps All 1500 candidate vulnerabilities were comprehensively scored and their risk levels were determined: 1) Taking the candidate vulnerability corresponding to location A as an example: Actual call type: Calling a dangerous function → Assigning the first score of 100 points and the first weight of 30%. Call chain reachability state: Path is clear → Assign a second score of 100 points, with a second weight of 30%. Dissemination level of tainted data: Externally controllable → Assign a third score of 100 points, with a third weight of 40%. Overall risk score = 100 × 30% + 100 × 30% + 100 × 40% = 100 points Risk level label is determined based on the scoring range: High risk, immediate repair.

[0095] 2) Taking the candidate vulnerability corresponding to position C as an example: Actual call type: Calling a dangerous function → First score: 100 points Call chain reachability state: Path broken → Second score 0 Dissemination level of tainted data: Uncontrollable → 0 points (third score) Overall risk score = 100 × 30% + 0 × 30% + 0 × 40% = 30 points Determine the risk level label based on the scoring range: confirm false alarms.

[0096] 3) Taking the candidate vulnerability corresponding to the Log4j vulnerability as an example: Actual call type: Calling a dangerous function → First score: 100 points Call chain reachability state: Configure blocking → Second score 20 points Dissemination level of tainted data: Uncontrollable → 0 points (third score) Overall risk score = 100 × 30% + 20 × 30% + 0 × 40% = 36 points Risk level label is determined based on the scoring range: Low risk, acceptable.

[0097] 4) Taking the candidate vulnerability corresponding to the Commons IO vulnerability as an example: Actual call type: Calling a dangerous function → First score: 100 points Call chain reachability state: Permission to intercept → Second score, 30 points Dissemination level of tainted data: Internally controllable → Third score, 50 points Overall risk score = 100 × 30% + 30 × 30% + 50 × 40% = 30 + 9 + 20 = 59 points The risk level label is determined based on the scoring range: Medium Risk (Observation).

[0098] For example, following the above example, the risk level of all 1500 candidate vulnerabilities was determined, and the following were identified: Three high-risk vulnerabilities requiring immediate fixes are identified as genuinely exploitable vulnerabilities and must be scheduled for immediate remediation. It is estimated that manual confirmation will be required for approximately 0.5 person-days. 15 medium-risk vulnerabilities are under observation and require continuous monitoring. They will not be fixed for the time being and are expected to require about 1 person-day for manual assessment. 200 low-risk vulnerabilities with mitigation measures in place. Acceptance requires business assessment and is expected to require approximately 0.5 person-days of manual review. The remaining 1282 vulnerabilities were confirmed as false alarms and were automatically marked by the system without manual intervention.

[0099] Through the multi-layered progressive screening in this embodiment, the security team reduced the number of vulnerabilities it needed to handle from 1,500 to only 3 high-risk vulnerabilities and 15 medium-risk vulnerabilities, reducing the workload from 100 person-days to 2 person-days, allowing real vulnerabilities to be prioritized for remediation.

[0100] (6) Continuous monitoring steps The system deploys a continuous monitoring mechanism to track subsequent changes in real time. Code Change Monitoring: One week later, the development team submitted new code, introducing a new third-party library h2-database1.4.200. The system automatically identified the newly introduced third-party library, executed steps (1) to (5), and found that it had a CVE-2021-23463 vulnerability. The actual call identification revealed that the code called the dangerous function RunScript.execute. The call chain analysis determined that the path was unobstructed, and the taint analysis determined that it was externally controllable. The comprehensive score was 100 points, and it was immediately marked as high-risk and immediately fixed and an alarm was issued.

[0101] Vulnerability Intelligence Monitoring: Two weeks later, the vulnerability database added CVE-2023-1234 vulnerability, affecting commons-fileupload 1.3.3. The system automatically synchronized vulnerability intelligence and found that the target code library contained this version of the library. Steps (2) to (5) were immediately executed. Analysis revealed that although the vulnerable version of the library existed, the code only called a safe function. The actual call type was a call to a safe function. The overall score was 30 points, and it was marked as a confirmed false alarm.

[0102] Configuration drift monitoring: Three weeks later, the operations and maintenance personnel modified the configuration file, changing log4j2.formatMsgNoLookups from true to false. The vulnerability scanning system detected this runtime configuration change, re-evaluated and found that the original security defense mechanism had failed. It immediately re-executed steps (3) and (4) on the affected functions, updated its call chain reachability status from configuration blocking to path unobstructed, changed the tainted data propagation level from uncontrollable to externally controllable, increased the comprehensive score from 36 points to 100 points, changed the risk level label from low risk to accept update to high risk to be fixed immediately, and triggered an alarm.

[0103] Through continuous monitoring, the vulnerability scanning system can always reflect the latest security risk status, ensuring that the security team can respond promptly to various dynamic security threats.

[0104] Example 2 See Figure 2Another embodiment of the present invention provides a third-party library vulnerability verification device 200 based on reachability analysis, including a preliminary scanning module 201, an actual call identification module 202, a call chain analysis module 203, a taint analysis module 204, and a comprehensive judgment module 205. The third-party library vulnerability verification device 200 based on reachability analysis can execute the third-party library vulnerability verification method based on reachability analysis in the method embodiment.

[0105] Specifically, the third-party library vulnerability verification device 200 based on reachability analysis includes: The preliminary scanning module 201 is used to respond to a vulnerability scanning task request, scan the target code library and determine the third-party libraries used by the target code library, and query the vulnerability database to obtain candidate vulnerabilities based on the third-party libraries; The actual call identification module 202 is used to scan the code of the third-party library involved in the candidate vulnerability, identify the actual call type of the code in the target code library to the function in the third-party library, and mark the called function as dangerous function or safe function; The call chain analysis module 203 is used to trace the call chain from the external attack vector to the dangerous function, perform reachability analysis on the call chain to obtain the reachability state of the call chain, and determine the dangerous function that can be actually triggered based on the reachability state of the call chain. The taint analysis module 204 is used to identify the corresponding external input source for dangerous functions that can be actually triggered based on the call chain, track the data flow path of tainted data from the external input source to the dangerous function, determine whether there is a security defense mechanism on the data flow path, and determine the propagation level of tainted data in combination with the nature of the external input source. The comprehensive judgment module 205 is used to comprehensively score the candidate vulnerabilities based on the actual call type of the function in the third-party library, the reachability status of the call chain, and the propagation level of the taint data, and to determine the truly exploitable target vulnerability based on the comprehensive score.

[0106] It should be noted that the technical solutions corresponding to the third-party library vulnerability verification device 200 based on reachability analysis provided in this embodiment, which can be used to execute various method embodiments, have similar implementation principles and technical effects to the methods, and will not be repeated here.

[0107] Example 3 See Figure 3 This embodiment also provides a structural schematic diagram of an electronic device 300, which is used to implement the third-party library vulnerability verification method based on reachability analysis in the method embodiment. The electronic device 300 in this embodiment may include a smart terminal, a PC, a laptop computer, a server, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0108] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0109] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0110] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for verifying vulnerabilities in third-party libraries based on reachability analysis, characterized in that, Includes the following steps: Preliminary scanning steps: In response to a vulnerability scanning task request, scan the target code repository and identify the third-party libraries used by the target code repository, and query the vulnerability database based on the third-party libraries to obtain candidate vulnerabilities; Actual call identification steps: Perform code scanning on the third-party libraries involved in the candidate vulnerabilities, identify the actual call types of the code in the target code library to the functional functions in the third-party library, and mark the called functional functions as dangerous functions or safe functions; Call chain analysis steps: trace the call chain from the external attack vector to the dangerous function, perform reachability analysis on the call chain using a differentiated tracing strategy, obtain the reachability status of the call chain, and determine the dangerous function that can be actually triggered based on the reachability status of the call chain; Taint analysis steps: For dangerous functions that can be actually triggered, identify the corresponding external input source based on the call chain, trace the data flow path of tainted data from the external input source to the dangerous function, determine whether there is a security defense mechanism on the data flow path, and determine the propagation level of tainted data in combination with the nature of the external input source; Comprehensive judgment steps: Based on the actual call type of the function in the third-party library, the reachability status of the call chain, and the propagation level of the tainted data, the candidate vulnerability is comprehensively scored, and the truly exploitable target vulnerability is determined based on the comprehensive score.

2. The third-party library vulnerability verification method based on reachability analysis according to claim 1, characterized in that, The step of performing reachability analysis on the call chain using a differentiated tracing strategy to obtain the reachability status of the call chain includes: For deserialization vulnerabilities, if the external attack vector cannot be transmitted to the entry point of the deserialization dangerous function, the call chain path is determined to be broken; if the external attack vector can be transmitted to the entry point of the deserialization dangerous function and there is no type filtering, blacklist verification, or security context restriction, the call chain path is determined to be unobstructed; if the external attack vector can be transmitted to the entry point of the deserialization dangerous function but there is type filtering, blacklist verification, or security context restriction, the call chain is determined to be configured to be blocked. For permission vulnerabilities, if there is no complete call chain from the external attack vector entry point to the dangerous function, the call chain path is considered broken; if there is a complete call chain from the external attack vector entry point to the dangerous function and there is no permission check, the call chain path is considered unobstructed; if there is a complete call chain from the external attack vector entry point to the dangerous function and there is a permission check, the call chain is considered to be intercepted by the relevant authorities. For configuration vulnerabilities, if the dangerous configuration item associated with the dangerous function is disabled, the call chain is determined to be blocked by configuration; if the dangerous configuration item associated with the dangerous function is enabled but cannot be modified by external attack vectors, the call chain is determined to be blocked by configuration; if the dangerous configuration item associated with the dangerous function is enabled and can be modified by external attack vectors, the call chain path is determined to be unobstructed. For file operation vulnerabilities, if the path parameter of the dangerous function contains an external attack vector and there is no path traversal filtering or directory range restriction, the call chain path is considered to be unobstructed; if the path parameter of the dangerous function contains external input but there is path traversal filtering or directory range restriction, the call chain is considered to be configured to be blocked; if the path parameter of the dangerous function does not contain external input, the call chain is considered to be configured to be blocked or the path is broken. Furthermore, regarding SQL injection vulnerabilities, if the input data carried by the external attack vector uses a pre-compilation mechanism or parameterized query during its flow into the dangerous function, the call chain is determined to be blocked; if the input data carried by the external attack vector neither uses a pre-compilation mechanism nor calls a filtering and escaping function during its flow into the dangerous function, the call chain path is determined to be unobstructed; if the input data carried by the external attack vector does not use a pre-compilation mechanism but calls a filtering and escaping function during its flow into the dangerous function, the call chain is determined to be blocked.

3. The third-party library vulnerability verification method based on reachability analysis according to claim 1, characterized in that, The stain analysis step further includes: If the external input source is a network interface that can be directly accessed by external users, and there is no security defense mechanism on the data flow path, then tainted data can be propagated to the dangerous function and the attacker can directly control the input of the external input source, which is determined to be an externally controllable level. If the external input source is located inside the system or requires specific permissions to access, and there is no security defense mechanism on the data flow path, then tainted data can be propagated to dangerous functions, but attackers cannot directly control the input of the external input source, and it is determined to be at the internal controllable level. If the starting point of the data flow path is a constant within the program or data that is not affected by external factors, or if there is a security defense mechanism on the data flow path, then the tainted data cannot be propagated to the dangerous function and is determined to be of an uncontrollable level.

4. The third-party library vulnerability verification method based on reachability analysis according to claim 1, characterized in that, The comprehensive determination step further includes: Assign a first score and a first weight to the actual call type of the function in the third-party library corresponding to each candidate vulnerability; assign a second score and a second weight to the reachability status of the call chain corresponding to each candidate vulnerability; assign a third score and a third weight to the tainted data propagation level corresponding to each candidate vulnerability; sum the products of the first score and the first weight, the second score and the second weight, and the third score and the third weight for each candidate vulnerability to obtain a comprehensive score for each candidate vulnerability; determine the risk level label for each candidate vulnerability based on the comprehensive score, and rank the candidate vulnerabilities according to the risk level label; determine the candidate vulnerabilities whose risk level meets the preset conditions as truly exploitable target vulnerabilities.

5. The third-party library vulnerability verification method based on reachability analysis according to claim 1, characterized in that, It also includes continuous monitoring steps: The system monitors code changes in the target code repository. When a new third-party library is detected, the system performs the preliminary scanning step, actual call identification step, call chain analysis step, taint analysis step, and comprehensive judgment step on the new third-party library. When a new function call point of an existing third-party library is detected, the system re-executes the call chain analysis step and the taint analysis step on the function and updates the reachability status of its call chain and the propagability level of taint data based on the analysis results. The vulnerability database is monitored. When new vulnerability information is detected, the new vulnerability is matched with the existing third-party libraries in the target code library. For the successfully matched candidate vulnerabilities, the actual call identification step, call chain analysis step, taint analysis step and comprehensive judgment step are executed. The system monitors changes to configuration items during runtime of the target code. When a change is detected in a configuration item related to the original security defense mechanism, it re-determines whether the change in the configuration item causes the original security defense mechanism to fail. If it fails, the system re-executes the call chain analysis step and taint analysis step on the affected function and updates its call chain reachability status and taint data propagation level.

6. A third-party library vulnerability verification device based on reachability analysis, characterized in that, include: The preliminary scanning module is used to respond to vulnerability scanning task requests, scan the target code library and determine the third-party libraries used by the target code library, and query the vulnerability database based on the third-party libraries to obtain candidate vulnerabilities; The actual call identification module is used to scan the code of the third-party library involved in the candidate vulnerability, identify the actual call type of the code in the target code library to the function in the third-party library, and mark the called function as dangerous function or safe function; The call chain analysis module is used to trace the call chain from the external attack vector to the dangerous function, perform reachability analysis on the call chain to obtain the reachability state of the call chain, and determine the dangerous function that can be actually triggered based on the reachability state of the call chain. The taint analysis module is used to identify the corresponding external input source for dangerous functions that can be actually triggered based on the call chain, track the data flow path of tainted data from the external input source to the dangerous function, determine whether there is a security defense mechanism on the data flow path, and determine the propagation level of tainted data in combination with the nature of the external input source. The comprehensive judgment module is used to comprehensively score the candidate vulnerabilities based on the actual call type of the function in the third-party library, the reachability status of the call chain, and the propagation level of the taint data, and to determine the truly exploitable target vulnerabilities based on the comprehensive score.

7. The third-party library vulnerability verification device based on reachability analysis according to claim 6, characterized in that, The call chain analysis module is further used for: For deserialization vulnerabilities, if the external attack vector cannot be passed to the entry point of the deserialization dangerous function, the call chain path is determined to be broken; if the external attack vector can be passed to the entry point of the deserialization dangerous function and there is no type filtering, blacklist verification or security context restriction, the call chain path is determined to be unobstructed. If an external attack vector can be passed to the entry point of the deserialization dangerous function but there are type filtering, blacklist verification or security context restrictions, then the call chain is determined to be blocked by configuration. For permission vulnerabilities, if there is no complete call chain from the external attack vector entry point to the dangerous function, the call chain path is considered broken; if there is a complete call chain from the external attack vector entry point to the dangerous function and there is no permission check, the call chain path is considered unobstructed; if there is a complete call chain from the external attack vector entry point to the dangerous function and there is a permission check, the call chain is considered to be intercepted by the relevant authorities. For configuration vulnerabilities, if the dangerous configuration item associated with the dangerous function is disabled, the call chain is determined to be blocked by the configuration; if the dangerous configuration item is enabled but cannot be modified by external attack vectors, the call chain is determined to be blocked by the configuration; if the dangerous configuration item is enabled and can be modified by external attack vectors, the call chain path is determined to be unobstructed. For file operation vulnerabilities, if the path parameter of the dangerous function contains an external attack vector and there is no path traversal filtering or directory range restriction, the call chain path is considered to be unobstructed; if the path parameter of the dangerous function contains external input but there is path traversal filtering or directory range restriction, the call chain is considered to be configured to be blocked; if the path parameter of the dangerous function does not contain external input, the call chain is considered to be configured to be blocked or the path is broken. Furthermore, regarding SQL injection vulnerabilities, if the input data carried by the external attack vector uses a pre-compilation mechanism or parameterized query during its flow into the dangerous function, the call chain is determined to be blocked; if the input data carried by the external attack vector neither uses a pre-compilation mechanism nor calls a filtering and escaping function during its flow into the dangerous function, the call chain path is determined to be unobstructed; if the input data carried by the external attack vector does not use a pre-compilation mechanism but calls a filtering and escaping function during its flow into the dangerous function, the call chain is determined to be blocked.

8. The third-party library vulnerability verification device based on reachability analysis according to claim 6, characterized in that, The stain analysis module is further used for: If the external input source is a network interface that can be directly accessed by external users, and there is no security defense mechanism on the data flow path, then tainted data can be propagated to the dangerous function and the attacker can directly control the input of the external input source, which is determined to be an externally controllable level. If the external input source is located inside the system or requires specific permissions to access, and there is no security defense mechanism on the data flow path, then tainted data can be propagated to dangerous functions, but attackers cannot directly control the input of the external input source, and it is determined to be at the internal controllable level. If the starting point of the data flow path is a constant within the program or data that is not affected by external factors, or if there is a security defense mechanism on the data flow path, then the tainted data cannot be propagated to the dangerous function and is determined to be of an uncontrollable level.

9. A third-party library vulnerability verification device based on reachability analysis according to claim 6, characterized in that, The comprehensive determination module is further used for: Assign a first score and a first weight to the actual call type of the function in the third-party library corresponding to each candidate vulnerability; assign a second score and a second weight to the reachability status of the call chain corresponding to each candidate vulnerability. Assign a third score and a third weight to the taint data propagation level corresponding to each candidate vulnerability; The comprehensive score for each candidate vulnerability is calculated by summing the product of the first score and the first weight, the product of the second score and the second weight, and the product of the third score and the third weight. Based on the comprehensive score, a risk level label is determined for each candidate vulnerability, and the candidate vulnerabilities are ranked according to the risk level label. Candidate vulnerabilities whose risk level meets the preset conditions are identified as real and exploitable target vulnerabilities.

10. A third-party library vulnerability verification device based on reachability analysis according to claim 6, characterized in that, It also includes a continuous monitoring module, used for: The system monitors code changes in the target code repository. When a new third-party library is detected, the system executes the preliminary scanning module, actual call identification module, call chain analysis module, taint analysis module, and comprehensive judgment module on the new third-party library. When a new function call point of an existing third-party library is detected, the system re-executes the call chain analysis module and the taint analysis module on the function and updates the reachability status of its call chain and the propagability level of taint data based on the analysis results. The vulnerability database is monitored. When new vulnerability information is detected, the new vulnerability is matched with the existing third-party libraries in the target code library. The actual call identification module, call chain analysis module, taint analysis module and comprehensive judgment module are executed on the successfully matched candidate vulnerabilities. The system monitors changes to configuration items during the runtime of the target code. When a change is detected in a configuration item related to the original security defense mechanism, it re-determines whether the change in the configuration item causes the original security defense mechanism to fail. If it fails, the system re-executes the call chain analysis module and taint analysis module on the affected function and updates the reachability status of its call chain and the propagability level of taint data.

Images