Model-based upgrade recommendations using software dependencies

A method may include obtaining, for an application, application dependency specifications, identifying vulnerable components using the application dependency specifications and a list of known vulnerable components, selecting, for a vulnerable component, candidate dependency specifications each specifying a version ID for a component, selecting, for a candidate dependency specification, an upgraded version ID for a component, verifying, using an application dependency graph generated from the application dependency specifications, that upgrading the candidate dependency specification to the upgraded version ID removes a dependency on the vulnerable component, and recommending, for the application, an upgrade solution including upgrading the candidate dependency specification to the upgraded version ID.

BACKGROUND

Software applications often need to upgrade the versions of the components upon which their application depends, particularly when vulnerabilities (e.g., security vulnerabilities) are detected in specific component versions. The software application may be secured by upgrading the vulnerable component to a newer version that fixes the vulnerability. Similarly, when an application becomes outdated due to an outdated component, the application may be updated by upgrading the component to a newer version. However, the newer version of the component may be incompatible with other components, sub-components, sub-sub-components, etc. When an application has transitive dependencies (e.g., layers of components), and components have multiple versions, efficiently identifying component, sub-component, sub-sub-component, etc. versions is challenging.

SUMMARY

In general, in one aspect, one or more embodiments relate to a method including obtaining, for an application, application dependency specifications, identifying vulnerable components using the application dependency specifications and a list of known vulnerable components, selecting, for a vulnerable component, candidate dependency specifications each specifying a version ID for a component, selecting, for a candidate dependency specification, an upgraded version ID for a component, verifying, using an application dependency graph generated from the application dependency specifications, that upgrading the candidate dependency specification to the upgraded version ID removes a dependency on the vulnerable component, and recommending, for the application, an upgrade solution including upgrading the candidate dependency specification to the upgraded version ID.

In general, in one aspect, one or more embodiments relate to a system including a repository configured to store application dependency specifications and a list of known vulnerable components. The system further includes a computer processor and an upgrade manager executing on the computer processor and configured to obtain, for an application, the application dependency specifications, identify vulnerable components using the application dependency specifications and the list of known vulnerable components, select, for a vulnerable component, candidate dependency specifications each specifying a version ID for a component, select, for a candidate dependency specification, an upgraded version ID for a component, verify, using an application dependency graph generated from the application dependency specifications, that upgrading the candidate dependency specification to the upgraded version ID removes a dependency on the vulnerable component, and recommend, for the application, an upgrade solution including upgrading the candidate dependency specification to the upgraded version ID.

In general, in one aspect, one or more embodiments relate to a method including obtaining, for an application, application dependency specifications, sending the application dependency specifications to an upgrade manager configured to perform: identifying vulnerable components using the application dependency specifications and a list of known vulnerable components, selecting, for a vulnerable component, candidate dependency specifications each specifying a version ID for a component, selecting, for a candidate dependency specification, an upgraded version ID for a component, verifying, using an application dependency graph generated from the application dependency specifications, that upgrading the candidate dependency specification to the upgraded version ID removes a dependency on the vulnerable component, recommending, for the application, an upgrade solution including upgrading the candidate dependency specification to the upgraded version ID, and transmitting the upgrade solution. The method further includes receiving, from the upgrade manager, the upgrade solution.

DETAILED DESCRIPTION

In general, embodiments of the invention are directed to upgrading an application. The application's dependency specifications may indicate version IDs of components upon which the application depends (e.g., components that the application calls). Each dependency specification represents a direct dependency of the application on a component. Similarly, each component's dependency specifications may, in turn, indicate version IDs of other components upon which the component depends. An application dependency graph generated from the application dependency specifications represents both direct dependencies and transitive (i.e., indirect) dependencies of the application on various components.

Vulnerable components upon which the application depends are identified using the application dependency graph and a list of known vulnerable components. Candidate dependency specifications are selected for a vulnerable component. The candidate dependency specifications are upgrade targets and may be processed separately. A candidate dependency specification may directly set the version ID of the vulnerable component. Alternatively, a candidate dependency specification may indirectly set the version ID of the vulnerable component (e.g., the candidate dependency specification may represent a transitive dependency on the vulnerable component).

An upgraded version ID is selected for the candidate dependency specification to remove the dependency of the application on the vulnerable component. The upgraded version ID may represent the minimal upgrade to a subsequent version ID that is closest to the current version ID and removes the dependency on the vulnerable component. Upgrading the candidate dependency specification to the upgraded version ID is verified, using the application dependency graph, to remove the dependency of the application on the vulnerable component. An upgrade solution including upgrading the candidate dependency specification to the upgraded version ID is recommended for the application.

FIG.1Ashows a system (100) in accordance with one or more embodiments of the invention. As shown inFIG.1A, the system (100) includes a user computing system (102) and a back-end computing system (104). In one or more embodiments, the user computing system (102) and the back-end computing system (104) take the form of the computing system (500) described with respect toFIG.5Aand the accompanying description below or take the form of the client device (526) described with respect toFIG.5B.

The back-end computing system (104) includes a repository (106), an upgrade manager (108), and computer processor(s) (110). In one or more embodiments, the repository (106) is any type of storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data. Further, the repository (106) may include multiple different storage units and/or devices. The multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. The repository (106) may be accessed online via a cloud service (e.g., Oracle Cloud, Amazon Web Services (AWS), Egnyte, Azure, etc.).

In one or more embodiments, the repository (106) includes functionality to store components (114C,114R), dependency specifications (120C,120R), known vulnerable components (122), and dependency graphs (124). The components (114C,114R) are collections of statements (e.g., computer instructions) written in source code of a human-readable programming language. A component (114C) may be labeled with a component identifier (ID) (116) and a version ID (118). For example, in the dependency specification (402) shown inFIG.4A, the component “jackson-databind: 2.9.10” has a component ID “jackson-databind” (404) and a version ID “2.9.10” (406).

In one or more embodiments, version IDs are ordered using an ordering scheme based on semantic versioning and/or published timestamps of components (e.g., timestamps obtained from a Maven index of components). For example, when semantic versioning is used, the version ID may be divided into a sequence of three digits indicating a major version ID, a minor version ID, and a patch ID. With semantic versioning, a series of version IDs may be 1.0.0, 1.1.0, 1.1.1, 1.2.0, etc. In one or more embodiments, a second version ID is considered subsequent to a first version ID if the second version ID has a higher version according to the ordering scheme and corresponds to a later published timestamp than the first version ID.

A component C (114C) corresponds to one or more dependency specifications (120C). Each dependency specification represents a direct dependency of the component C (114C) on another component. Turning toFIG.1B, a dependency specification (150) includes a component Q (114Q), specification attributes (152), and a specification file (154). For example, the component Q (114Q) may be a library used by component C (114C) ofFIG.1A. Component C (114C) ofFIG.1Amay be referred to as the calling component, and component Q (114Q) ofFIG.1Bmay be referred to as the called component. For example, a calling component may call a called component via application programming interfaces (APIs) provided by the called component. The dependency specification (150) may specify a version ID for the component Q (114Q). For example,FIG.4Ashows a dependency specification (402) that specifies a version ID “2.9.10” (406) for a component.

The specification file (154) is a file that stores the dependency specification (150). For example, the specification file (154) may be a Maven project object model (POM) file. The specification file (154) may be stored in the repository (106). The specification attributes (152) describe features of the dependency specification (150). For example, a specification attribute may indicate that the corresponding dependency specification (150) overrides or imports a version ID of a component specified in another dependency specification. Continuing this example, an imported dependency specification may be included in a specification file that includes several related dependency specifications. The imported dependency specification may be a Maven parent POM file or a Maven bill of materials (BOM) file. For example,FIG.4Cshows an “importing” dependency specification (422) that imports a dependency specification (432) shown inFIG.4D.

Returning toFIG.1A, the known vulnerable components (122) is a list of components in which vulnerabilities (e.g., security vulnerabilities or obsolescence vulnerabilities) have been detected. For example, the known vulnerable components (122) may include entries of the form <component ID, version ID> indicating that a component labeled with the component ID and version ID is known to be vulnerable.

Each dependency graph (124) models a collection of dependency specifications. The dependency graph (124) includes nodes corresponding to components, and directed edges each representing a direct dependency of a calling component on a called component. For example,FIG.4Bshows a dependency graph (410) that includes a direct dependency of an application (412) on a vulnerable component “jackson-databind:2.9.10” (414). InFIG.4B, the application is the calling component and the vulnerable component is the called component. A path formed by a series of edges in the dependency graph (124) models one or more transitive (i.e., indirect) dependencies between components. For example,FIG.4Fshows a dependency graph (450) that includes a transitive dependency of an application (452) on vulnerable component “jackson-databind:2.9.18” (456) and a transitive dependency of the application (452) on vulnerable component “commons-compress:1.10” (458). That is, inFIG.4F, the application (452) sets the version ID of a component (454) that in turn sets the version IDs of the vulnerable components (456,458).

The upgrade manager (108) includes functionality to recommend, for an application (140), an upgrade solution (130). Returning toFIG.1B, the upgrade solution (130) includes upgraded version IDs (160J,160Y) corresponding to dependency specifications (150J,150Y). The upgrade manager (108) includes functionality to apply the upgrade solution (130) by assigning, in a dependency specification (150J), an upgraded version ID (160J) to a component. For example, the upgrade manager (108) may modify the version ID at line7of the dependency specification (402) ofFIG.4Ato be an upgraded version ID.

As another example, the upgrade manager (108) may modify the version ID within the import specification shown on lines12-18of dependency specification B (422) ofFIG.4Cto be an upgraded version ID when the imported dependency specification C (432) shown inFIG.4Dis published externally to dependency specification B (422). That is, when the imported dependency specification C (432) is published externally to the importing dependency specification B (422), the imported dependency specification C (432) may not be modified directly, but may be modified indirectly by modifying the importing dependency specification B (422). In contrast, when the imported dependency specification C (432) ofFIG.4Dis published locally with respect to the importing dependency specification B (422) ofFIG.4C, the version ID within the imported dependency specification C (432) may be modified directly, for example, on line8ofFIG.4D. For example, the imported dependency specification C (432) ofFIG.4Dmay be published locally with respect to the importing dependency specification B (422) ofFIG.4Cwhen the application is a multi-module application.

The user computing system (102) may be a mobile device (e.g., phone, tablet, digital assistant, laptop, etc.) or any other computing device (e.g., desktop, terminal, workstation, etc.) with a computer processor (not shown) and memory (not shown) capable of running computer software. The user computing system (102) includes an application (140) and dependency specifications (120A) corresponding to the application (140). The application (140) may be thought of as a top-level component (e.g., a project). In one or more embodiments, the application (140) may be a multi-module application that includes multiple modules For example, each module may correspond to a separate POM file, where a top-level POM file for the application (140) specifies the individual module POM files that may declare dependencies with respect to other modules included in the application (140).

The user computing system (102) includes functionality to send the dependency specifications (120A) corresponding to the application (140) to the upgrade manager (108). The back-end computing system (104) further includes functionality to store the dependency specifications (120A) corresponding to the application (140) in the repository (106). The user computing system (102) includes functionality to receive an upgrade solution (130) from the upgrade manager (108). The user computing system (102) includes functionality to upgrade the application (140) using the upgrade solution (130).

In one or more embodiments, the computer processor(s) (110) takes the form of the computer processor(s) (502) described with respect toFIG.5Aand the accompanying description below. In one or more embodiments, the computer processor (110) includes functionality to execute the upgrade manager (108).

FIG.2shows a flowchart in accordance with one or more embodiments of the invention. The flowchart depicts a process for upgrading an application. One or more of the steps inFIG.2may be performed by the components (e.g., the upgrade manager (108) of the back-end computing system (104) and/or the user computing system (102), discussed above in reference toFIG.1A). In one or more embodiments of the invention, one or more of the steps shown inFIG.2may be omitted, repeated, and/or performed in parallel, or in a different order than the order shown inFIG.2. Accordingly, the scope of the invention should not be considered limited to the specific arrangement of steps shown inFIG.2.

Initially, in Step202, application dependency specifications are obtained for an application. The upgrade manager may obtain the application dependency specifications for the application from a dependency specification file stored in the user computing system (e.g., a Maven project object model (POM) file). The upgrade manager may obtain the application dependency specifications in response to an announcement of a vulnerability in a component included in the application dependency specifications. For example, the announcement of the vulnerability may trigger a request to upgrade the application. Alternatively, the upgrade manager may obtain the application dependency specification in response to an announcement that a component included in the application dependency specification has become out-of-date. For example, the component may have become discontinued (e.g., end-of-lifed) or deprecated.

In Step204, vulnerable components are identified using the application dependency specifications and a list of known vulnerable components. The upgrade manager may identify the vulnerable components by:

1) generating, for the application and from the application dependency specifications, an application dependency graph that represents the direct and transitive dependencies of the application. The nodes of the application dependency graph correspond to the components used by the application and the edges of the application dependency graph each correspond to a direct dependency of a calling component on a called component, and

2) identifying components corresponding to nodes of the dependency graph whose <component ID, version ID> labels are included in the list of known vulnerable components.

The upgrade manager may generate the application dependency graph by performing the following steps:1) adding nodes corresponding to the components referenced in the application dependency specifications.2) obtaining, for the components referenced in the application dependency specifications, component dependency specifications. For example, the upgrade manager may obtain the component dependency specifications from a Maven project object model (POM) that indicates, for each component, other components upon which the component directly depends.3) adding additional nodes corresponding to the additional components (e.g., called components) referenced in the component dependency specifications.4) adding edges between the components (e.g., calling components) referenced in the application dependency specifications and the components (e.g., called components) specified in the component dependency specifications.

The upgrade manager may then recursively examine the component dependency specifications while adding, to the application dependency graph, nodes corresponding to the components referenced in successive component dependency specifications. The upgrade manager may further add edges between the nodes corresponding to the calling component and the called component of each component dependency specification. In addition, the upgrade manager may further add edges between the nodes corresponding to the called components of a component dependency specification and the nodes corresponding to the calling components of successive component dependency specifications.

In Step206, candidate dependency specifications are selected for a vulnerable component. The candidate dependency specifications are upgrade targets and may be processed separately. The candidate dependency specifications may each specify a version ID for a component. The upgrade manager may select a candidate dependency specification that sets the version ID of the vulnerable component. For example, the upgrade manager may select, as a candidate dependency specification, dependency specification A (402) inFIG.4Aif the vulnerable component is vulnerable component “jackson-databind:2.9.10” because dependency specification A (402) sets the version ID (406) of vulnerable component “jackson-databind:2.9.10.” InFIG.4A, dependency specification A (402) represents a direct dependency of an application on the component “jackson-databind:2.9.10.”

As an alternative example, the upgrade manager may select, as a candidate dependency specification, dependency specification B (422) inFIG.4Cif the vulnerable component is vulnerable component “jackson-databind:2.9.10” because dependency specification B (422) sets the version ID of vulnerable component “jackson-databind:2.9.10.” InFIG.4C, dependency specification B (422) represents a direct dependency of an application on the component “jackson-databind:2.9.10.” However, unlike dependency specification A (402) ofFIG.4A, dependency specification B (422) imports another dependency specification, namely dependency specification C (432) ofFIG.4D.

In contrast, the upgrade manager may select, as a candidate dependency specification, a dependency specification that represents a transitive (e.g., indirect) dependency on the vulnerable component. For example, the upgrade manager may select, as a candidate dependency specification, dependency specification D (442) inFIG.4Eif the vulnerable component is vulnerable component “jackson-databind:2.9.8” because dependency specification D (442) sets the version ID of component “avro:1.9.0” (454) that in turn sets the version ID of a vulnerable component “jackson-databind:2.9.8” (456), as shown in the dependency graph (450) ofFIG.4F. Similarly, the upgrade manager may select dependency specification D (442) as a candidate dependency specification if the vulnerable component is component “commons-compress:1.10” because dependency specification D (442) sets the version ID of component “avro:1.9.0” (454) that in turn sets the version ID of a vulnerable component “commons-compress:1.18” (458), as shown in in the dependency graph (450) ofFIG.4F. InFIG.4E, dependency specification D (442) represents transitive dependencies of an application on the components “jackson-databind:2.9.8” and compress:1.18.”

In Step208, an upgraded version ID for a component is selected for a candidate dependency specification. The upgrade manager may select an upgraded version ID for the candidate dependency specification that removes the dependency of the application on the vulnerable component. The upgrade manager may select the upgraded version ID by performing the following.

1) obtaining a series of version IDs subsequent to a current version ID specified in the candidate dependency specification. For example, the upgrade manager may obtain the series of version IDs using a list of version IDs stored for the component whose version ID is set by the candidate dependency specification. Continuing this example, the list of version IDs may be stored in a Maven index. A second version ID is considered subsequent to a first version ID if the second version ID is higher than the first version ID (e.g., according to an ordering scheme) and the second version ID corresponds to a later published timestamp than the first version ID.

If the candidate dependency specification directly sets the version ID of the vulnerable component, then the upgrade manager may select the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list). Thus, the upgrade manager may select, as a “minimal upgrade,” a subsequent version ID that is closest to the current version ID and also removes the dependency on the vulnerable component. For example, a version ID that is close to the current version ID may be less likely to result in a potential incompatibility in the application due to upgrading to a version ID that is not backward compatible with another component of the application.

2) Alternatively, if the candidate dependency specification sets the version ID of another component that in turn depends on the vulnerable component, the upgrade manager may generate a series of candidate version dependency graphs corresponding to the series of version IDs for the component specified in the candidate dependency specification. The upgrade manager may generate and process the candidate version dependency graphs according to an ordering scheme for the version IDs based on semantic versioning and/or published timestamps of components. In contrast to the application dependency graph discussed in Step204above, which represents the dependencies of the entire application, each candidate version dependency graph represents the dependencies of a different version ID of the component specified in the candidate dependency specification (see description of Step204above).

3) determining, using the series of candidate version dependency graphs, whether upgrading the candidate dependency specification to the respective version ID removes the dependency on the vulnerable component. For example, the upgrade manager may determine whether the <component ID, version ID> labels of the components corresponding to the nodes of the respective candidate version dependency graph are included in the list of known vulnerable components. Continuing this example, a dependency on a vulnerable component with component ID C and version ID V may be considered to be removed when the component is upgraded to a version ID W such that the label <component ID C, version ID W> is not included in the list of known vulnerable components.

The upgrade manager may generate and process candidate version dependency graphs until an upgraded version ID is found that removes the dependency on the vulnerable component. If no such version ID is found, then the earliest version ID with the fewest number of dependencies on vulnerable components may be selected.

For example,FIG.4Gshows a series of dependency graphs (460,470,480) generated for a series of subsequent version IDs of candidate dependency specification D (442) ofFIG.4E. Dependency graph C (460) corresponds to version ID 1.9.1 of the component labeled with component ID “avro,” and shows that the version ID of the vulnerable component “commons-compress” is upgraded to a clean (e.g., non-vulnerable) version ID. However, dependency graph C (460) further shows that the version ID of the vulnerable component “jackson-databind,” although upgraded, is included in the list of known vulnerable components. Thus, the upgrade manager next generates dependency graph D (470) corresponding to version ID 1.9.2 of the component labeled with component ID “avro,” which also shows that the version ID of the vulnerable component “jackson-databind” is included in the list of known vulnerable components. Thus, the upgrade manager next generates dependency graph E (480) corresponding to version ID 1.10.0 of the component labeled with component ID “avro,” which finally shows that the version ID of the vulnerable component “jackson-databind” is upgraded to a clean version ID. The upgrade manager then ceases generating and processing candidate version dependency graphs, and selects version ID 1.10.0 as the upgraded version ID for the candidate dependency specification.

If the candidate dependency specification is a parent POM, the upgrade manager may similarly process each version ID in the series of version IDs to process dependencies on vulnerable components. However, instead of generating a candidate version dependency graph for the parent POM, the original application dependency graph (discussed in Step204above) may be regenerated using the upgraded parent POM because a candidate version dependency graph for the parent POM may fail to detect dependencies resulting from declarations in a child POM corresponding to a parent POM.

In Step210, upgrading the candidate dependency specification to the upgraded version ID is verified, using the application dependency graph generated from the application dependency specifications, to remove a dependency on the vulnerable component. Once the upgraded version ID has been processed using a candidate version dependency graph for the component specified in the candidate dependency specification, the upgrade manager then performs a similar, global analysis by re-generating the application dependency graph (discussed in Step204above) using the upgraded version ID for the candidate dependency specification. For example, the upgrade manager may verify, using the re-generated application dependency graph, that upgrading the candidate dependency specification to the upgraded version ID removes the dependency on the vulnerable component. In addition, the upgrade manager may check whether any additional dependencies on vulnerable components have been introduced due to the upgrade. For example, a subsequent version of a component may introduce new dependencies on vulnerable components. If new dependencies on vulnerable components were added, Step206and/or Step208above may be repeated in an attempt to remove the new dependencies on vulnerable components. For example, when repeating Step208, a second subsequent upgraded version ID for the candidate dependency specification may be selected in an attempt to remove a new dependency on a vulnerable component, where the second subsequent upgraded version ID follows, in an ordering scheme for version IDs, the upgraded version ID selected in the previous iteration of Step208.

As an alternative example, when repeating Step206, a second set of candidate dependency specifications may be selected in an attempt to remove a new dependency on a vulnerable component. Then, when repeating Step208, the upgrade manager may select, for a candidate dependency specification selected from the second set of candidate dependency specifications, an upgraded version ID for a component that is different from the component referenced in the previous iteration of Step208.

If the upgrade manager is unable to remove one or more dependencies on vulnerable components, the upgrade manager may:1) issue an alert indicating that the application includes one or more dependencies on vulnerable components. The alert may include the candidate dependency specification and the component ID and version ID of each vulnerable component, and/or2) recommend an upgrade solution in Step212below that removes as many of the dependencies on vulnerable components as possible.

In Step212, an upgrade solution including upgrading the candidate dependency specification to the upgraded version ID is recommended for the application. The upgrade solution may further include upgrading one or more additional candidate dependency specifications to upgraded version IDs that were generated during one or more iterations of Step206, Step208, and Step210above. The upgrade solution may be stored in an output file (e.g., a patch file) that includes the upgraded version ID corresponding to each candidate dependency specification processed during one or more iterations of Step206, Step208, and Step210above. The output file may be used to assign, in a specification file corresponding to each candidate dependency specification of the upgrade solution, the upgraded version ID to the respective candidate dependency specification.

The upgrade solution may be presented to a user (e.g., a software developer or information technology administrator) for review. For example, the upgrade solution may be presented to the user via a graphical user interface (GUI) of the user computing system, where the user may approve or reject the upgrade solution.

The process ofFIG.2may be extended to support multi-module applications as follows. Generating the application dependency graph for multi-module applications may include separately generating module dependency graphs for each module, such that identifying the modules to be generated includes scanning a list of modules included in a top-level file (e.g., a top-level POM file) for the application. Each file (e.g., POM file) referenced in the list of modules may declare its own submodules, which may be scanned recursively. Once the module dependency graphs are generated, the modules may be separately processed to produce a combined set of candidate dependency specifications for the multi-module application. Then an upgraded version ID may be selected for each candidate dependency specification as described above. One modification to the process ofFIG.2is that the module updated dependency graphs are processed when upgrading a parent POM. When verifying in Step210above, the process may be performed over the set of modules in the multi-module application.

FIG.3shows a flowchart in accordance with one or more embodiments of the invention. The flowchart depicts a process for upgrading an application. One or more of the steps inFIG.3may be performed by the components (e.g., the upgrade manager (108) of the back-end computing system (104) and/or the user computing system (102), discussed above in reference toFIG.1A). In one or more embodiments of the invention, one or more of the steps shown inFIG.3may be omitted, repeated, and/or performed in parallel, or in a different order than the order shown inFIG.3. Accordingly, the scope of the invention should not be considered limited to the specific arrangement of steps shown inFIG.3.

Initially, in Step302, application dependency specifications are obtained for an application (see description of Step202above).

In Step304, the application dependency specifications are sent to an upgrade manager configured to transmit an upgrade solution by performing the steps ofFIG.2. The application dependency may be sent to the upgrade manager via a network.

In Step306, the upgrade solution is received from the upgrade manager. The upgrade solution may be received from the upgrade manager via the network.

FIG.4A,FIG.4B,FIG.4C,FIG.4D,FIG.4E,FIG.4F, andFIG.4Gshow implementation examples in accordance with one or more embodiments. The implementation examples are for explanatory purposes only and not intended to limit the scope of the invention. One skilled in the art will appreciate that implementation of embodiments of the invention may take various forms and still be within the scope of the invention.

As previously discussed,FIG.4Ashows a dependency specification (402) ((120A,120C,120R) inFIG.1Aand (150,150J,150Y) inFIG.1B) that represents a direct dependency of an application on the component “jackson-databind:2.9.10.” The component “jackson-databind: 2.9.10” has a component ID “jackson-databind” (404) ((116) inFIG.1A) and a version ID “2.9.10” (406) ((118) inFIG.1A). FIG.4B shows a dependency graph (410) ((124) inFIG.1A) that represents the direct dependency of the application (412) ((140) inFIG.1A) on the component “jackson-databind: 2.9.10” (414) ((114C,114R) inFIG.1Aand (114Q) inFIG.1B).

As previously discussed,FIG.4Cshows dependency specification B (422) that represents a direct dependency of an application on the component “jackson-databind:2.9.10.” Dependency specification B (422) imports dependency specification C (432) shown inFIG.4D.

As previously discussed,FIG.4Eshows dependency specification D (442) that represents transitive (e.g., indirect) dependencies of an application on the components “jackson-databind:2.9.8” and “commons-compress:1.18,” as shown in the dependency graph (450) ofFIG.4F. The dependency graph (450) shows that the application (452) has transitive dependencies on component “jackson-databind:2.9.8” (456) and component “commons-compress:1.18” (458). That is, the transitive dependency of the application (452) on the component “jackson-databind:2.9.8” (456) includes a direct dependency of the application (452) on the component “avro:1.9.0” (454) and a direct dependency of the component “avro:1.9.0” (454) on the component “jackson-databind:2.9.8” (456). For example, dependency specification D (442) sets the version ID of the component “avro:1.9.0” (454) that in turn sets the version ID of component “jackson-databind:2.9.8” (456). Similarly, the transitive dependency of the application (452) on the component “commons-compress:1.18” (458) includes a direct dependency of the application (452) on the component “avro:1.9.0” (454) and a direct dependency of the component “avro:1.9.0” (454) on the component “commons-compress:1.18” (458).

As previously discussed,FIG.4Gshows a series of dependency graphs (460,470,480) generated for a series of subsequent version IDs of dependency specification (442) ofFIG.4E.FIG.4Eshows that dependency specification (442) specifies the version ID “1.9.0” for the component labeled with component ID “avro.” Dependency graph C (460) corresponds to a subsequent version ID “1.9.1” and shows that the version ID of the vulnerable component “commons-compress” is upgraded to a clean (e.g., non-vulnerable) version ID. However, dependency graph C (460) also shows that the version ID of the vulnerable component “jackson-databind,” although upgraded, is included in the list of known vulnerable components. Dependency graph D (470) corresponding to version ID 1.9.2 of the component labeled with component ID “avro” also shows that the version ID of the vulnerable component “jackson-databind” is included in the list of known vulnerable components. Dependency graph E (480) corresponding to version ID 1.10.0 of the component labeled with component ID “avro,” shows that the version ID of the vulnerable component “jackson-databind” is upgraded to a clean version ID.

Embodiments disclosed herein may be implemented on a computing system specifically designed to achieve an improved technological result. When implemented in a computing system, the features and elements of this disclosure provide a significant technological advancement over computing systems that do not implement the features and elements of the disclosure. Any combination of mobile, desktop, server, router, switch, embedded device, or other types of hardware may be improved by including the features and elements described in the disclosure. For example, as shown inFIG.5A, the computing system (500) may include one or more computer processors (502), non-persistent storage (504) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage (506) (e.g., a hard disk, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory, etc.), a communication interface (512) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), and numerous other elements and functionalities that implement the features and elements of the disclosure.

The computer processor(s) (502) may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores or micro-cores of a processor. The computing system (500) may also include one or more input devices (510), such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device.

The communication interface (512) may include an integrated circuit for connecting the computing system (500) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) and/or to another device, such as another computing device.

The nodes (e.g., node X (522), node Y (524)) in the network (520) may be configured to provide services for a client device (526). For example, the nodes may be part of a cloud computing system. The nodes may include functionality to receive requests from the client device (526) and transmit responses to the client device (526). The client device (526) may be a computing system, such as the computing system shown inFIG.5A. Further, the client device (526) may include and/or perform all or a portion of one or more embodiments disclosed herein.

The above description of functions presents only a few examples of functions performed by the computing system ofFIG.5Aand the nodes and/or client device inFIG.5B. Other functions may be performed using one or more embodiments disclosed herein.