CN117311797A - Software library version safety replacement method based on static analysis - Google Patents
Software library version safety replacement method based on static analysis Download PDFInfo
- Publication number
- CN117311797A CN117311797A CN202311395934.5A CN202311395934A CN117311797A CN 117311797 A CN117311797 A CN 117311797A CN 202311395934 A CN202311395934 A CN 202311395934A CN 117311797 A CN117311797 A CN 117311797A
- Authority
- CN
- China
- Prior art keywords
- version
- dependency
- maven
- versions
- library
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 111
- 238000004458 analytical method Methods 0.000 title claims abstract description 37
- 230000003068 static effect Effects 0.000 title claims abstract description 36
- 230000001419 dependent effect Effects 0.000 claims abstract description 46
- 230000000717 retained effect Effects 0.000 claims description 9
- 238000010276 construction Methods 0.000 claims description 5
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 3
- 230000002159 abnormal effect Effects 0.000 abstract description 13
- 238000010586 diagram Methods 0.000 description 8
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 229920001971 elastomer Polymers 0.000 description 1
- 239000000806 elastomer Substances 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Stored Programmes (AREA)
Abstract
A software library version safety replacement method based on static analysis comprises the steps of obtaining a dependency tree structure according to a given Maven project; traversing the dependency tree to obtain all dependency libraries with multiple versions in the dependency tree, and knowing the loaded version and the rejected version of each dependency library; calculating differences between the discarded version and the loaded version of each dependency library; selecting Jar packages and Maven items in the dependency tree according to the need, constructing a call graph by using static analysis, and performing reachability analysis on difference parts of the abandoned version and the loaded version of each dependency library by taking a set of item methods/classes as an entry method/class on the call graph; for a dependent library with reachable difference parts, various strategies are tried to replace the dependent library with versions, and finally, the difference parts of the rejected version and the loaded version of the dependent library are not likely to be referenced any more at the running time. The method and the device can effectively find and solve the abnormal operation of the Maven project caused by the existence of the multi-version dependency library, and improve the use efficiency.
Description
Technical Field
The invention belongs to the technical field of software maintenance and evolution, and particularly relates to a software library version safety replacement method based on static analysis.
Background
With the development scale of software becoming larger, the emergence of third party libraries improves the reusability of project codes, and software projects increasingly depend on the third party libraries to realize code reuse. However, the heavy dependence of the project on the third party library also brings about difficulty in project dependence library management, even if project construction tools such as Maven and Gradle automate the dependence management process of the project, the dependence relationship can be properly processed when the project is compiled, and the trouble of manually managing the dependence by a programmer is reduced, but when the programmer is unfamiliar with the dependency processing rules of the construction tools, abnormal or unexpected operation results of the operation due to the dependence management problem cannot be avoided.
To address the above issues, the build tool provides some functionality to alert programmers to the problem of multiple version dependency libraries for items, and provides some mechanism to enable the programmer to manually specify the required dependency versions. For example, the Maven build tool provides Maven-dependency-plug in, allows a programmer to print an item dependency tree, and displays multiple versions of the dependency library presence in the print information; maven also allows programmers to specify the version number of the required indirect dependent libraries using the dependency management tag, or delete indirect dependent libraries that are not desired to be used by the dependency tag. However, the Maven build tool cannot learn whether the multi-version condition of these dependent libraries causes runtime anomalies at runtime, and if not, no additional management is needed; manual management of dependencies, if initiated, requires a programmer to have a fairly rich knowledge of the dependency library characteristics used. Therefore, a software library version security replacement method based on static analysis needs to be proposed.
Disclosure of Invention
The invention provides a software library version safety replacement method based on static analysis, which aims to reduce the problem that a Maven project possibly causes abnormal dependency library to have multiple versions as far as possible, and simultaneously aims to ensure that after the problem that the original Maven project dependency library has multiple versions is solved, a new dependency library possibly causing abnormal runtime is not introduced to have the problem of multiple versions. And the risk of the rejected version method/class called by the project in the project multi-version dependency library is automatically analyzed by adopting a conservative static analysis mode, and on the basis of analyzing the possible risk, a project developer is automatically helped to select and recommend a more reasonable and more applicable version of the project use dependency library, and the use efficiency is simultaneously considered.
In order to achieve the above purpose, the present invention adopts the following technical scheme:
the software library version safety replacement method based on static analysis is characterized by comprising the following steps of:
obtaining a Maven project dependency tree by adopting a Maven related open source tool, traversing the dependency tree, determining dependency libraries with multiple versions in the dependency tree, and calculating set differences of respective discarded versions and reserved versions of the dependency libraries with multiple versions, wherein the set differences comprise class set differences and method set differences;
if the set difference is not null, adopting a static analysis mode to analyze whether the set difference can be referred to by classes and methods in the Maven items through paths, if so, starting a library version replacement process to replace the version numbers of the dependent libraries referred to by the Maven items until the situation that the set difference is probably referred to by the Maven items does not exist any more.
In order to optimize the technical scheme, the specific measures adopted further comprise:
further, the method adopts a Maven related open source tool to obtain a Maven project dependency tree, which is specifically as follows:
the Maven project dependency tree is constructed through the related APIs provided by Maven authorities.
Further, the traversing the dependency tree determines that multiple versions of the dependency library exist in the dependency tree, and calculates aggregate differences between respective discarded versions and reserved versions of the multiple versions of the dependency library, specifically:
traversing the whole dependency tree, searching a third party library with a plurality of versions, and determining which version is reserved and which version is abandoned according to the information carried by the dependency tree;
the set of retained versions and the set of each of the discarded versions are calculated, and the set of discarded versions and the set of retained versions are used for differencing to obtain the set difference of each of the discarded versions and the set of retained versions.
Further, the analysis set difference is likely to be referenced by classes and methods in Maven projects through paths, specifically:
and selecting a related Jar packet in the dependency tree, calculating a call graph, taking a Maven item on the graph as a starting node, taking a set difference as a target node, and analyzing the accessibility from the starting node to the target node.
Further, the selecting the related Jar package in the dependency tree calculates a call graph, which specifically includes:
and only the Jar package call graph from the root node of the dependency tree to the link of the abandoned version is calculated without selecting the Jar package of the whole dependency tree.
Further, before the call graph is calculated, firstly, unreachable method set differences are prejudged by using the class reference relation, so that a method which is not necessarily called is eliminated, and the calculation process of the call graph is omitted.
Further, the library version replacement process adopts the following replacement method:
replacing the reserved version of the dependency library such that the reserved version set contains the original set differences, all methods and classes in the set differences being reserved and loaded at run-time;
or cutting off the calling link to the set difference, and replacing the version number of the dependency library to which the discarded version father node belongs in the dependency tree, so that the Maven item does not try to refer to the method and class in the set difference at running time.
Further, after the library version replacement process is finished, the validity of the replacement result is verified by adopting the following method:
executing a Maven item construction process, ensuring that the replaced Maven item can be compiled normally, and if the replaced Maven item cannot be compiled normally, proving that a replacement strategy is invalid, and trying other versions to replace;
checking whether the set difference disappears after replacement: if the set difference disappears, judging that the replacement strategy is effective; if the set difference exists, adopting a static program analysis tool to verify whether the set difference can be referred to by a Maven item, and if so, trying other versions to replace;
and verifying whether the multi-version dependency library exists after replacement, and verifying whether the aggregate difference of the discarded version and the reserved version of the dependency library can be referred to by the Maven item, and if so, attempting other versions to replace.
Further, in the process of attempting replacement of other versions, the version search space is confirmed in the following manner:
and taking the current Maven project use version as a reference, sequentially selecting 1 to 2 versions for candidate replacement version sets respectively from three versions, wherein the first version is the same version as the current Maven project use version MAJOR number and MINOR number but different from the PATCH number, the second version is the same version as the current Maven project use version MAJOR number but different from the MINOR number, and the third version is the version different from the current Maven project use version MAJOR number.
Further, in the process of attempting replacement of other versions, the version search space is confirmed in the following manner:
pre-establishing an ES database, wherein a direct dependency list of each Jar packet in a Maven official warehouse is stored; and in the ES database, inquiring through the inverted index to determine the alternative version.
The beneficial effects of the invention are as follows: according to the software library version safety replacement method based on static analysis, a conservative static analysis mode is adopted, risks that a rejected version method/class in a project multi-version dependent library is possibly called by a project are automatically analyzed, and on the basis of analyzing the possible risks, project developers are automatically helped to select and recommend more reasonable and more applicable project use dependent library versions, and meanwhile, the use efficiency is considered. The method can effectively reduce the problem that the dependent library of the Maven item possibly causes abnormal operation in multiple versions, can also ensure that the new problem of the dependent library possibly causing abnormal operation is not introduced after the problem of the original dependent library in multiple versions is solved, and can effectively discover and solve the abnormal operation of the Maven item caused by the problem of the dependent library in multiple versions.
Drawings
FIG. 1 is a flow chart of a software library version security replacement method based on static analysis according to an embodiment of the invention.
Fig. 2 is a schematic diagram of a POM configuration file provided by the Maven item according to an embodiment of the present invention.
FIG. 3 is a partial schematic diagram of a Maven project dependency tree in accordance with an embodiment of the invention.
Fig. 4 is a schematic diagram of a usage mode of a software library version security replacement method based on static analysis according to an embodiment of the present invention.
FIG. 5 is a schematic diagram of an automatically generated software dependent library security replacement proposal according to an embodiment of the present invention.
FIG. 6 is a diagram of a database storage portion according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.
The embodiment specifically provides a software library version security replacement method based on static analysis, and referring to fig. 1, an automatic software dependent library security upgrading method includes:
determining the dependency libraries of the multiple versions present in the project and finding the method/class difference set of their respective rejected and retained versions, which is the part of the project that will not be loaded during operation, denoted delta; the method/class of the difference set that may be referenced by the project runtime is then selected by static analysis, denoted delta reachable . In relying on secure replacement of library versions, delta needs to be guaranteed reachable Become empty set, not introduce delta yet reachable The method tries to replace the version of the dependent library, adopts a conservative static analysis mode, ensures that after the version is replaced, all the dependent libraries in the project do not exist in delta reachable To achieve static analysis based software dependent library version security replacement.
In this embodiment, multi-version dependency libraries are determined and the portions of their respective discarded and retained versions of the method/class difference set that may be referenced at the project runtime, i.e., the methods/classes that are needed but not loaded at the runtime, are found. To ensure that this part of calculation is accurate and not missing, the following four stages are required;
in the first stage, a Maven project dependency tree is constructed through related APIs provided by a Maven official, as shown in fig. 2, a POM configuration file is provided for one Maven project, and a tool provided by the Maven official can parse the Maven dependency tree according to the POM, as shown in fig. 3, which is a local example of the Maven project dependency tree.
And in the second stage, traversing the whole dependency tree, searching for a third party library with multiple versions, and determining which version is reserved and which version is abandoned according to the information carried by the dependency tree. In most cases, the dependency library and version numbers of all nodes can be directly displayed in the dependency tree, statistics can be simply performed according to the information, and meanwhile, several boundary conditions need to be considered, such as subtrees cut by programmers using an exclusion keyword, which need to be additionally acquired and traversed.
And in the third stage, calculating a reserved version method/class set, and calculating each abandoned version method/class set, wherein the abandoned version method/class set is differenced from the reserved version method/class set by the later method to obtain the difference part of each abandoned version method/class set and the reserved version.
And a fourth stage, selecting a related Jar packet in the dependency tree, calculating a call graph, taking the project method/class as an initial node on the graph, taking the difference part method/class obtained in the third stage as a target node, and analyzing the accessibility from the initial node to the target node.
If the set of methods/classes that may be needed but not loaded at project runtime is empty, then no dependency library version replacement is needed.
If the set of methods/classes that may be needed at project runtime but not loaded is not empty, an attempt to replace the dependent library version will be made by the following two ways:
mode 1: the basic idea is that if there are unloaded methods/classes referenced in the rejected version of the current dependency library, we can find a version of the dependency library that contains all the methods/classes referenced by the current item to the dependency library. This version is declared in the Maven project POM configuration file.
Mode 2: the basic idea is that if there is an unloaded method/class in the rejected version of the dependency library that may be referenced by the item at run-time, we can attempt to sever the reference to this part of the method/class, thus choosing to replace the version number of the dependency library that the item passed along the path of the method/class reference, severing this reference link.
The method is characterized in that the problem that the original dependent library has multiple versions and possibly causes abnormal operation is solved, the multiple versions of the new dependent library possibly causing abnormal operation are not introduced, and the following flow is needed:
1. an alternate version search space is determined.
Method 1: and taking the current project use version as a reference, sequentially selecting 1 to 2 versions from the versions which are closer, farther and farther than each other for candidate replacement version sets. Since Maven dependent library version numbers are typically formatted as < MAJOR > < MINOR > < PATCH >, the closer version is the same version as the current project use version MAJOR number, MINOR number but different from the PATCH number, the farther version is the same version as the current project use version MAJOR number but different from the MINOR number, and the farther version is the version different from the current project use version MAJOR number.
Method 2: before using the method, a database needs to be built in advance, in which a direct dependency list of each Jar package in the Maven official repository is stored. The database uses an elastomer search. The database stores part of the data as shown in fig. 6. After the database is built, when the version of the dependent library which is wanted to be replaced is determined, the version of the replacement is determined by inquiring the inverted index in the ES database: setting a ticket counter Map, wherein keys are all versions of a to-be-replaced dependency library, and values are ticket obtaining numbers, traversing all direct dependent items of the Maven project of the embodiment, and respectively inquiring the coexistence times of all versions of the to-be-replaced dependency library and the to-be-replaced dependency library in an ES database dependencies domain for each direct dependent item. If a direct dependency of the Maven item and a version of the library to be replaced coexist most often, the ticket counter [ vetsion ] ++. And finally, sorting all the keys of the ticket counter according to the value, and sequentially trying to replace the dependent library version of each key after sorting.
2. The versions in the candidate version replacement set are sequentially tried to be declared in the POM file, and a static analysis tool is used for determining that the problem of multiple versions of all the dependent libraries in the item dependent tree after replacement is unlikely to cause runtime exception. The present includes that the dependent libraries being solved have multi-version problems and that potentially newly introduced dependent libraries have multi-version problems. If the candidate version is replaced by the POM, the static verification is passed, and the replaced dependent library and the candidate version are output.
In this embodiment, the multi-version dependency library is determined, and the third stage in the portion where the methods/class difference sets of the respective discarded version and the reserved version may be referred to during project operation is found, and because the method/class set of the Jar package is considered to be unchanged after being released, the efficiency of resolving and calculating the version method/class set in real time is low each time, so that the database of the class and the method set in each Jar package can be pre-established, and then the Jar package is not required to be resolved in real time, and the database is directly read to obtain the method/class set, thereby improving the efficiency. The specific practice can adopt a mode of locally caching files or databases such as ES, mongoDB and the like.
In this embodiment, the multi-version dependency library is determined and the method/class difference sets for their respective discarded and retained versions are found, possibly in the fourth stage in the portion referenced by the project runtime, without choosing the Jar package for the whole dependency tree when computing the call graph. Since the discarded version appears at leaf nodes (e.g., common-logging: jar:1.2 in fig. 3), only the call graph of the Jar package on the dependency tree root to the discarded version link needs to be calculated, because most calls to the discarded version method or class only follow the Jar package on the project to the version dependency tree branch, the number of Jar package parameters can be calculated by the method to reduce the number of call graphs, and the call graph calculation process is greatly accelerated.
In this embodiment, the multi-version dependency library is determined, and the method/class difference sets of the respective discarded version and the reserved version are found, which may be in the fourth stage in the referenced part of the project in operation. The basic idea is that if the method is called by the project, the class of the method is required to be called by the project, in actual conditions, the possibility that the difference set of the method is called by the project is very low, the class reference relation diagram among Jar packages can be calculated at low cost, class reference accessibility analysis is carried out on the diagram, if the class reference is not reachable, the method is not required to be called, so that the method which is not required to be called is eliminated, and the calculation process of the calling diagram is omitted.
In this embodiment, the library version replacement process verifies that the replacement result is indeed valid in the following manner:
step 1: firstly, executing a project construction process, ensuring that the replaced project can be normally compiled, and if the project cannot be normally compiled, proving that a replacement strategy is invalid and trying other versions to replace;
step 2: checking whether the discarded version unloaded method/class set disappears after replacement;
step 3: if the unloaded method/class set of the discarded version in the step 2 disappears, judging that the replacement strategy is valid;
step 4: if the discarded version of the unloaded method/class collection still exists in step 2, a static program analysis tool is used to verify whether the collection portion can be referenced by the item.
Step 5: after replacement is verified by a static analysis method, whether multiple versions exist in other dependent libraries or not is verified, and whether differences between rejected versions and reserved version methods/class sets of other dependent libraries are referenced or not is verified.
Next, a further explanation will be given with specific examples: referring further to fig. 2, the Maven project generally writes the dependent third party libraries and version constraints on these third party libraries in a pon.xml configuration file, and the Maven project developer mainly declares the direct dependent items required by the project through dependency tags, which are uniquely determined by three coordinates groupId, artifactId, version. The combination of groupId, artifactId can uniquely identify the dependent library, version identifies the version of the dependent library, and the version safety replacement of the dependent library refers to replacing version of a groupId, artifactId item to solve the problem that the dependent library which is originally existed and may cause abnormal operation has multiple versions.
As shown in FIG. 3, because the Maven project developer only declares direct dependencies in the pon.xml configuration file, these dependent library versions themselves are very likely to depend on some other dependent library versions that are not declared in the pon.xml configuration file, the Maven build tool will automatically parse and parse the Maven project dependency structure into a tree structure, which is shown as a partial schematic of a Maven project dependency tree. The dependency tree can be seen to show groupId: the dependency library of artifactId is common-logging: the common-logging presents a discarded version 1.9, which is discarded because the 1.6 version of the dependency library appears somewhere else in the dependency tree. The invention can automatically judge which dependency libraries have multiple versions by utilizing the analysis result of the dependency tree.
As shown in FIG. 4, the present invention may be installed in the local Maven repository in the form of a Maven plug-in, one way to use the present invention is to execute specific commands under the embodiment Maven project catalog by way of a command line. After the command is operated, the Maven project is analyzed to obtain a multi-version dependency library, the multi-version problem of the dependency library which can potentially cause the abnormal operation is analyzed, and then a software library dependent version replacement process is carried out to solve the multi-version problem of the dependency library which can cause the abnormal operation.
As shown in FIG. 5, after the operation of the invention is finished, the invention can be output in a text mode to inform a user which dependent library needs to be replaced with which version, and the problem that the original dependent library has multiple versions can be solved. The figure informs the user that org. Apache. Flink is needed: the flink-table-api-java version number is replaced with 1.13.0 from original 1.14.1.
In summary, the software library version safety replacement method based on static analysis can effectively find and solve the abnormal operation of Maven projects caused by the multi-version problem of the dependent library, and meanwhile, improves efficiency and enhances the use experience of the method.
The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above examples, and all technical solutions belonging to the concept of the present invention belong to the protection scope of the present invention. It should be noted that modifications and adaptations to the invention without departing from the principles thereof are intended to be within the scope of the invention as set forth in the following claims.
Claims (10)
1. The software library version safety replacement method based on static analysis is characterized by comprising the following steps of:
obtaining a Maven project dependency tree by adopting a Maven related open source tool, traversing the dependency tree, determining dependency libraries with multiple versions in the dependency tree, and calculating set differences of respective discarded versions and reserved versions of the dependency libraries with multiple versions, wherein the set differences comprise class set differences and method set differences;
if the set difference is not null, adopting a static analysis mode to analyze whether the set difference can be referred to by classes and methods in the Maven items through paths, if so, starting a library version replacement process to replace the version numbers of the dependent libraries referred to by the Maven items until the situation that the set difference is probably referred to by the Maven items does not exist any more.
2. The software library version security replacement method based on static analysis of claim 1, wherein: the method adopts a Maven related open source tool to obtain a Maven project dependency tree, which comprises the following steps:
the Maven project dependency tree is constructed through the related APIs provided by Maven authorities.
3. The software library version security replacement method based on static analysis of claim 1, wherein: traversing the dependency tree, determining that multi-version dependency libraries exist in the dependency tree, and calculating the aggregate differences of the discarded versions and the reserved versions of the multi-version dependency libraries respectively, wherein the aggregate differences are specifically as follows:
traversing the whole dependency tree, searching a third party library with a plurality of versions, and determining which version is reserved and which version is abandoned according to the information carried by the dependency tree;
the set of retained versions and the set of each of the discarded versions are calculated, and the set of discarded versions and the set of retained versions are used for differencing to obtain the set difference of each of the discarded versions and the set of retained versions.
4. The software library version security replacement method based on static analysis of claim 1, wherein: whether the analysis set difference can be referred to by classes and methods in the Maven project through a path or not is specifically:
and selecting a related Jar packet in the dependency tree, calculating a call graph, taking a Maven item on the graph as a starting node, taking a set difference as a target node, and analyzing the accessibility from the starting node to the target node.
5. The software library version security replacement method based on static analysis of claim 4, wherein: the related Jar package in the dependency tree is selected, and a call graph is calculated, specifically:
and only the Jar package call graph from the root node of the dependency tree to the link of the abandoned version is calculated without selecting the Jar package of the whole dependency tree.
6. The software library version security replacement method based on static analysis of claim 4, wherein: before the call graph is calculated, firstly, the unreachable method set difference is prejudged by using the class reference relation, so that the method which is not necessarily called is eliminated, and the call graph calculation process is omitted.
7. The software library version security replacement method based on static analysis of claim 1, wherein: the library version replacement process adopts the following replacement method:
replacing the reserved version of the dependency library such that the reserved version set contains the original set differences, all methods and classes in the set differences being reserved and loaded at run-time;
or cutting off the calling link to the set difference, and replacing the version number of the dependency library to which the discarded version father node belongs in the dependency tree, so that the Maven item does not try to refer to the method and class in the set difference at running time.
8. The software library version security replacement method based on static analysis of claim 1, wherein: after the library version replacement process is finished, the validity of the replacement result is verified by adopting the following mode:
executing a Maven item construction process, ensuring that the replaced Maven item can be compiled normally, and if the replaced Maven item cannot be compiled normally, proving that a replacement strategy is invalid, and trying other versions to replace;
checking whether the set difference disappears after replacement: if the set difference disappears, judging that the replacement strategy is effective; if the set difference exists, adopting a static program analysis tool to verify whether the set difference can be referred to by a Maven item, and if so, trying other versions to replace;
and verifying whether the multi-version dependency library exists after replacement, and verifying whether the aggregate difference of the discarded version and the reserved version of the dependency library can be referred to by the Maven item, and if so, attempting other versions to replace.
9. The software library version security replacement method based on static analysis of claim 8, wherein: in the process of attempting replacement of other versions, the version search space is confirmed in the following manner:
and taking the current Maven project use version as a reference, sequentially selecting 1 to 2 versions for candidate replacement version sets respectively from three versions, wherein the first version is the same version as the current Maven project use version MAJOR number and MINOR number but different from the PATCH number, the second version is the same version as the current Maven project use version MAJOR number but different from the MINOR number, and the third version is the version different from the current Maven project use version MAJOR number.
10. The software library version security replacement method based on static analysis of claim 8, wherein: in the process of attempting replacement of other versions, the version search space is confirmed in the following manner:
pre-establishing an ES database, wherein a direct dependency list of each Jar packet in a Maven official warehouse is stored; and in the ES database, inquiring through the inverted index to determine the alternative version.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311395934.5A CN117311797A (en) | 2023-10-25 | 2023-10-25 | Software library version safety replacement method based on static analysis |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311395934.5A CN117311797A (en) | 2023-10-25 | 2023-10-25 | Software library version safety replacement method based on static analysis |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117311797A true CN117311797A (en) | 2023-12-29 |
Family
ID=89273628
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311395934.5A Pending CN117311797A (en) | 2023-10-25 | 2023-10-25 | Software library version safety replacement method based on static analysis |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117311797A (en) |
-
2023
- 2023-10-25 CN CN202311395934.5A patent/CN117311797A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Macho et al. | Automatically repairing dependency-related build breakage | |
| US20200019494A1 (en) | Method and apparatus for performing test by using test case | |
| US8312440B2 (en) | Method, computer program product, and hardware product for providing program individuality analysis for source code programs | |
| CN112965913B (en) | Java software dependency conflict problem automatic repairing method | |
| Petrović et al. | Practical mutation testing at scale: A view from google | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| CN112799937B (en) | Method for automatically detecting dependence conflict problem in Maven project based on Github | |
| CN115202669A (en) | Project construction method and system based on configuration file and related equipment | |
| CN112631607A (en) | Method for detecting dependency conflict in python environment | |
| CN111679852B (en) | Detection method and device for conflict dependency library | |
| Chen et al. | A study on the changes of dynamic feature code when fixing bugs: towards the benefits and costs of Python dynamic features | |
| CN114969762A (en) | Vulnerability information processing method, service device and vulnerability detection module | |
| CN114661423A (en) | Cluster configuration detection method and device, computer equipment and storage medium | |
| CN111240719B (en) | Defect-driven third-party library version upgrade recommendation method | |
| CN112445706A (en) | Program abnormal code acquisition method and device, electronic equipment and storage medium | |
| CN117311797A (en) | Software library version safety replacement method based on static analysis | |
| CN116841906A (en) | Intelligent contract detection method and device and electronic equipment | |
| CN111352631A (en) | Interface compatibility detection method and device | |
| CN113626823B (en) | Method and device for detecting interaction threat among components based on reachability analysis | |
| CN116028495A (en) | Intelligent contract detection method and device | |
| CN113127367B (en) | Defect detection method for Android dynamic permission application | |
| CN115310095A (en) | Block chain intelligent contract mixed formal verification method and system | |
| CN110321130B (en) | Non-repeatable compiling and positioning method based on system call log | |
| Chen et al. | Tracking down dynamic feature code changes against Python software evolution | |
| TWM632667U (en) | Code-Assisted Management Appliance for Core Accounting Host |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |