Continuous Vulnerability Management for Modern Applications

Abstract

Devices, methods, and systems for continuous vulnerability management of modern applications. A dependency tree can be created to map third-party libraries to microservices used in a software package's application. Natural language processing can be used on release notes and change logs of new library versions to generate a list of libraries disrupted by common vulnerabilities and exposures (“CVEs”). Multiple code calls from an application programming interface (“API”) can be made to the disrupted libraries. Multiple code calls including CVEs can be enumerated for each disrupted library. A risk score can be assigned to the API based on the multiple code calls including CVEs. The risk score can be compared to a threshold to trigger a remediation action, including updating the library to a newer version to address the CVE issue or generating a report about the disrupted library.

Description

Background Art

[0001] Application services, microservices, and software packages and their API implementations can use many open-source libraries or third-party libraries. The functional dependencies of microservices on their libraries can make existing code vulnerable to new vulnerabilities, even when the microservice code dependencies remain unchanged. Due to interactions with updated APIs of existing libraries, microservices may be exposed to previously unknown vulnerabilities. Alternatively, microservices may remain unchanged when libraries are updated, also creating the possibility of exposing microservices to vulnerabilities. In addition, some libraries may have multiple dependencies on subsequent libraries, forming a dependency tree. Microservices may depend on a large number of functional libraries, thus creating more opportunities for malicious attacks on APIs (hacking, unauthorized use, etc.).

[0002] Generally, vulnerabilities in open-source libraries are publicly reported. Depending on the nature of the disclosure, vulnerable libraries may become prime targets for malicious attacks. Typically, vulnerability analysis and resolution related to their dependencies within an API or microservice implementation are performed manually because it is difficult to perform such operations correctly in an automated manner. Manual inspection of each update to an API or microservice can be time-consuming and resource-exhausting. A solution is needed to quickly identify and resolve any vulnerabilities within an API caused by its dependencies on libraries that are likely to be targeted by hackers. Summary of the Invention

[0003] Embodiments provide devices, methods, and systems that provide a more powerful and accurate solution for continuous and automated vulnerability management of modern applications. According to some embodiments, a computer system can execute a method for protecting vulnerabilities in a software package. The method can include receiving a set of libraries of third-party software used by the software package. A list of disrupted libraries from the set of libraries can be determined, where each library in the list of disrupted libraries is affected by a vulnerability. One or more disrupted libraries from the list of disrupted libraries on which the application of the software package depends can be determined, where the application executes code from the one or more disrupted libraries and where the application calls the one or more disrupted libraries. A plurality of code calls including the vulnerability can be identified for each library in the one or more disrupted libraries. The code calls can be made by an application programming interface (“API”) of the application of the software package, and where the code calls are made to code within each library in the one or more disrupted libraries. A risk score can be assigned to the API based on the plurality of code calls. The risk score of the API can be compared with a threshold risk value. In response to the risk score exceeding the threshold risk value, a remedial action can be taken for each disrupted library called by the API.

[0004] Various embodiments may include a non-transitory computer-readable medium including instructions executable by a processing device to cause the processing device to receive, via a communication port, a set of libraries of third-party software corresponding to the use of a software package. A list of disrupted libraries from the set of libraries may be determined, where each library in the list of disrupted libraries is affected by a vulnerability. One or more disrupted libraries from the list of disrupted libraries on which an application of the software package depends may be determined, where the application executes code from the one or more disrupted libraries and where the application calls the one or more disrupted libraries. A plurality of code calls including the vulnerability may be identified for each library in the one or more disrupted libraries. The code calls may be made by an application programming interface ("API") of the application of the software package, and where the code calls are made to code within each library in the one or more disrupted libraries. A risk score may be assigned to the API based on the plurality of code calls. The risk score of the API may be compared to a threshold risk value. In response to the risk score exceeding the threshold risk value, a remedial action may be taken for each disrupted library called by the API.

[0005] Embodiments may include a system including a processing device, a communication port, and a non-transitory computer-readable medium including instructions executable by the processing device. The system may receive, via the communication port, a set of libraries of third-party software corresponding to the use of a software package. A list of disrupted libraries from the set of libraries may be determined, where each library in the list of disrupted libraries is affected by a vulnerability. One or more disrupted libraries from the list of disrupted libraries on which an application of the software package depends may be determined, where the application executes code from the one or more disrupted libraries and where the application calls the one or more disrupted libraries. A plurality of code calls including the vulnerability may be identified for each library in the one or more disrupted libraries. The code calls may be made by an application programming interface ("API") of the application of the software package, and where the code calls are made to code within each library in the one or more disrupted libraries. A risk score may be assigned to the API based on the plurality of code calls. The risk score of the API may be compared to a threshold risk value. In response to the risk score exceeding the threshold risk value, a remedial action may be taken for each disrupted library called by the API.

[0006] These and other embodiments of the present invention are described in detail below. For example, other embodiments relate to systems, devices, and computer-readable media associated with the methods described herein.

[0007] The nature and advantages of embodiments of the present invention may be better understood with reference to the following detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1is a diagram depicting a user's travel path and available suggestions for subsequent locations to be visited according to some embodiments of the present invention.

[0009] Figure 2 A flowchart depicting the performance of continuous and automated vulnerability management according to some embodiments of the present invention.

[0010] Figure 3A is a flowchart for detecting known vulnerabilities in continuous vulnerability management according to some embodiments of the present invention.

[0011] Figure 3B is a flowchart for measuring and reporting the security exposure of microservices in continuous vulnerability management according to some embodiments of the present invention.

[0012] Figure 4 Illustrates the pseudo-logic that can be used to aggregate a list of vulnerable third-party libraries according to some embodiments of the present invention.

[0013] Figure 5 Illustrates the pseudo-logic that can be used to measure security exposure according to some embodiments of the present invention.

[0014] Figure 6 is a block diagram of a continuous vulnerability management system according to some embodiments of the present invention.

[0015] Figure 7 is a flowchart of the process of a method for protecting vulnerabilities in software packages according to some embodiments of the present invention.

[0016] Figure 8 Depicts a block diagram of an example computer system that can be used in conjunction with the systems and methods according to some embodiments of the present invention.

[0017] The term

[0018] The term "application programming interface" ("API") can refer to a collection of routines, protocols, or tools for building software applications. An API can be a collection of well-defined communication methods and interaction methods between various programming components. For example, an API can be used to program a graphical user interface, an operating system, an application, a database system, a software library, a web-based system, or computer hardware. A single API can be implemented in multiple forms as different libraries that share the same programming interface (or none of the implementations are abstract). An API can include specifications for routines, data structures, object classes, variables, and / or remote calls. Some examples of APIs include POSIX, Windows API, and ASPI. An API can be related to a software library. An API can describe and specify the specifications, while a library is the actual implementation of this set of rules. A single API can be implemented in multiple forms as different libraries that share the same programming interface.

[0019] The term "microservice" may include services that operate in a manner loosely coupled to a collection of other microservices to implement an application. For example, a video streaming server may use multiple microservices to provide a video streaming service to a client computer, where one microservice may provide a user interface front end, another microservice may manage a video database, and a third microservice may manage video encoding, etc.

[0020] The term "Common Vulnerabilities and Exposures" ("CVE") may refer to a catalog of known security threats. CVE may include vulnerabilities and exposures reported in the public domain. Common vulnerabilities may be errors in software code that enable an attacker to directly access a system or network. For example, a vulnerability may allow an attacker to impersonate a superuser or system administrator with full access rights. Common exposures may be errors in software code or configuration that enable an attacker to indirectly access a system or network. For example, an exposure may enable an attacker to secretly collect customer information that can be sold. CVE can be used for

[0021] The term "library" may refer to a collection of non-volatile resources used by a computer program for developing and implementing software programs and applications, typically a set of data and programming code used in software development. These may include configuration data, programs, scripts, documents, help data, message templates, pre-written code and subroutines, classes, value or type specifications. For example, a microservice may rely on many third-party libraries to implement various functions of the microservice by calling subroutines or data structures in each library.

[0022] "Memory" may include any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transitory computer-readable media that store instructions that can be executed by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic operating modes.

[0023] "Processor" may include any suitable one or more data computing devices. The processor may include one or more microprocessors that work together to achieve the desired function. The processor may include a CPU, which includes at least one high-speed data processor sufficient to execute program components for executing user- and / or system-generated requests. The CPU may be a microprocessor, such as the Athlon, Duron, and / or Opteron from AMD; the PowerPC from IBM and / or Motorola; the Cell processor from IBM and Sony; the Celeron, Itanium, Pentium, Xeon, and / or XScale from Intel; and / or similar processors. Detailed implementation manners

[0024] Various embodiments provide devices, methods, and systems related to continuous and automated vulnerability management for implementing modern applications. Some embodiments address issues that may occur when updating libraries upon which microservices depend by providing a more powerful and faster solution for identifying and resolving common vulnerabilities and exposures ("CVEs") within the application programming interfaces (APIs) used by software packages. For example, this can be accomplished by: (i) identifying a list of libraries within an API that may be affected by a CVE, (ii) quantifying multiple APIs that may be affected by a CVE and the apparent degree to which each API has been affected, and (iii) providing a notification or report that includes a quantitative analysis of potential CVEs.

[0025] More specifically, a list of third-party libraries can be obtained and mapped to their dependencies within a microservice and subsequently to its APIs. Then, open-source third-party libraries can be mapped to their corresponding source uniform resource identifiers ("URIs"). This allows the present invention to map multi-service dependencies within an API and link libraries to publicly known information (e.g., patches, release notes, versions, or other information related to CVE control). A web crawler can be used to search via the mapped uniform resource identifiers ("URIs") to determine which libraries have newer versions with updates and may thus include potential CVEs. Additionally, when checking for the existence of updated versions, the present invention can determine whether backward compatibility is broken in the newer version of the library.

[0026] After determining a list of potentially vulnerable microservices, the quantity of libraries with known vulnerabilities and other security fixes and the apparent degree to which each microservice may be affected can be quantified. For each known security-related fix, the present invention can determine (i) the severity of the vulnerability, (ii) the number of affected code paths, (iii) whether direct or transitive dependencies are involved, and (iv) the number of dependencies with known CVEs affecting the API. This information can then be used to quantify the business functions affected by these vulnerabilities.

[0027] For example, there may be many dependencies, including known CVEs affecting APIs. The present invention can classify or evaluate the importance of known CVEs for each dependency. For example, a dependency affected by a CVE may be called by an API multiple times within the code, such that each code call may present an attack opportunity. Such a dependency would be classified as a problem and, in some embodiments, may be attributed a level of criticality or risk score. Another dependency may include a known CVE, but its code may not be called when the API is executed. The present invention can note that such a dependency includes a CVE, but since the risk of executing the CVE within the code is minimal or non - existent, its risk score is low or non - existent. Any dependency identified as not including a CVE can be attributed to no risk. Embodiments can then output a quantitative analysis as a notification or report that can be used to further debug, fix, or update potential problems within the library. This approach can allow an organization to continuously monitor for vulnerabilities in applications and business services and can provide risk scores to determine whether a fix should be made based on the severity of the vulnerability and the business functions affected.

[0028] I. Introduction

[0029] Due to the significantly increased dependencies on third - party libraries, especially open - source libraries, the attack surface is growing, which is a huge challenge in modern applications. For a set of deployed microservices and their APIs, visibility of these vulnerabilities is crucial. Additionally, after a vulnerability is discovered, improving recoverability is also important. New vulnerabilities may not actually be new security vulnerabilities, but merely newly disclosed vulnerabilities affecting old, existing code. This means that new known vulnerabilities can exist without any code changes.

[0030] Modern applications may have a large number of microservices with direct and transitive dependencies. This can lead to a significant attack surface. Attackers can increasingly target open - source dependencies as their reuse provides many victims for malicious hackers. Ensuring the security of the systems implementing the APIs may be beneficial to ensure that there are no known vulnerabilities throughout the entire dependency tree of the application. For a given vulnerability in a particular dependency, the exposure level in the microservices and APIs may be unknown. This requires an automated way to proactively detect security vulnerabilities due to vulnerabilities found in third - party dependencies and subsequently fix those vulnerabilities.

[0031] Figure 1A diagram depicting a dependency tree of an application, microservices, and third - party information including libraries according to an example. The application can utilize one or more microservices to perform various functions. The microservices can perform various functions implementing one or more libraries. For example, application 102 can use microservice 104 to perform software - related functions. Microservice 104 can call subroutines, data structures, programs, scripts, etc. stored in third - party library 106 to execute or assist in executing microservice functions.

[0032] In some instances, third - party library 106 can depend on other libraries or be a dependency library on which other libraries depend. Third - party library 106 can have a third - party library version 110 such that different versions of third - party library 106 have different code, where newer versions typically include fixes to address issues in previous versions. Third - party library 106 and third - party library version 110 can be created, provided, updated, or otherwise managed by third - party library source or vendor 108. Updates to third - party library 106 used within the system can be automatic, such that third - party library source or vendor 108 can implement "patches" that take effect at release. Typically, updates to third - party library 106 are manual, such that the manager or programmer of application 102 or microservice 104 can select which versions of third - party library 106 to implement and when to implement them.

[0033] When third - party library version 110 is changed automatically or manually, new CVEs can be created within microservice 104 that depends on third - party library 106. The newly created CVEs in microservice 104 can create potential vulnerabilities or code bugs within application 102. Various microservices can utilize portions of third - party library 106 in combination with other library and microservice code to achieve different microservice functions. Updates to third - party library version 110 can result in unexpected code changes within microservice 104. The code changes can affect the way microservice 104 executes code.

[0034] For example, third - party library source or vendor 108 can maintain third - party library 106 with a particular functionality in mind. Updates to third - party library version 110 may seek to address bugs or security risks present in previous versions that some dependent microservices have experienced. Some microservices may use third - party library 106 with a different set of capabilities than most of the microservices for which the update to third - party library version 110 is intended. Thus, these anomalous microservices may experience newly created CVEs because the update to third - party library version 110 is designed to address other issues or CVEs. As another example, an update to third - party library version 110 may be poorly designed, negatively impacting most of the dependent microservices and creating one or more widespread CVEs.

[0035] To help preemptively identify CVEs or avoid updates to library versions that may lead to CVEs, a third-party library source or vendor 108 can include release notes 112 and a change log 114 within or with the third-party library version 110. The release notes 112 and change log 114 can provide a detailed description of the changes made to the content of the third-party library 106, such that a programmer or manager of the microservice 104 and / or application 102 can change the code (if necessary) to be compatible with the updated third-party library version 110. In some instances, if the microservice 104 does not call code affected by the version update, the update to the third-party library version 110 may not affect the way the microservice 104 operates. In this instance, the microservice 104 does not need to be updated to accommodate the version update, thus avoiding any newly created CVEs.

[0036] Identifying CVEs created by updates to third-party libraries on which microservices depend can be beneficial because attackers may find it easier to exploit these CVEs due to the public nature of the CVEs. For example, a CVE for the third-party library 106 can be identified by a user or third-party library source or vendor 108 and reported as common knowledge. An attacker may know about the publicly known CVE and attempt to automatically attack microservices 104 that may have been updated to the latest CVE-bearing version of the third-party library 106, or that do not change their code to accommodate the changes in the third-party library version 110.

[0037] Typically, CVEs have been addressed through manual diagnosis and error checking. For example, a programmer can read the release notes and change log accompanying a library version update to determine which parts (if any) of the microservice that uses library calls will be affected. Any code in the microservice that exploits the updated part of the library can then be recoded to ensure that the library can be implemented within the microservice without errors or vulnerabilities. In some instances, a continuous integration / build system plugin can be used to provide static analysis of the microservice code to determine which libraries, APIs, or services of the microservice are affected by any code changes in the dependency tree. However, determining the affected code does not provide a quantification that can be used to determine whether a version upgrade will significantly impact the CVE exposure of the system. Embodiments of the present invention provide a solution for determining the quantification of the CVE impact on microservice and / or API code. This quantification can be used to determine whether a third-party library can be updated to its latest version with little or no negative impact on application functionality and security.

[0038] Plugins that provide code static analysis may suffer additional limitations. The plugin may introduce potential vulnerabilities in a manner similar to virus software, such that any potential vulnerabilities are analyzed based on the plugin library. The plugin does not detect potential vulnerabilities based on the library of the API in question and thus cannot address any potential issues within the architectural dependencies.

[0039] Embodiments can solve the above problems in the following ways: (i) actively detect vulnerabilities in third-party dependencies; (ii) provide visibility and measure the security exposure of the APIs (and microservices) of each application; (iii) handle vulnerabilities in deployed applications based on the severity of the exposure; and (iv) trigger remediation actions, such as notifications for addressing vulnerabilities. Embodiments of continuous and automated vulnerability management for modern applications disclosed herein are intended to provide solutions for these instances and other problems encountered when attempting to manage and maintain APIs without loss of CVEs.

[0040] II. Continuous Vulnerability Management

[0041] In this section, descriptions of the individual steps for performing continuous and automated vulnerability management are provided. Figure 2 A flowchart depicting the performance of continuous and automated vulnerability management according to one instance is shown. In block 202, known vulnerabilities are detected. This can include mapping each dependency or library to an application, where a package can include multiple applications. A list of vulnerable libraries including CVEs can be generated. In block 204, the security exposure of the microservices is measured. Using the dependency tree mapped from block 202, the list of vulnerable libraries can be analyzed to determine the number of times the code that calls each library including a CVE is executed to perform the operations of the package. By accumulating the total number of code calls with CVEs for each library, the importance of the CVE, and the impact on business functions, a risk score can be assigned to each library and / or API. The risk score can represent the potential opportunity for a library to be vulnerable to hacking or security breaches. In block 206, the vulnerabilities within the libraries including CVEs can be fixed, and a report can be generated that includes information about each library with a CVE and / or a risk score above a threshold. Based on the risk score of each library compared to the threshold, remediation actions can be performed.

[0042] A. Detecting Known Vulnerabilities

[0043] Figure 3A A flowchart depicting the detection of known vulnerabilities in continuous vulnerability management according to some embodiments of the present invention is shown. Known vulnerabilities are security vulnerabilities that are publicly disclosed, typically discovered and documented by users or reported by security researchers. Publicly known vulnerabilities are the most easily found and exploited by attackers, so it is crucial to address this issue when managing applications and their corresponding version libraries. A mapping of the application dependency tree can be created, and then third-party libraries can be mapped to their available release notes and change logs, and this mapping can be used to determine a list of all dependencies and affected microservices with vulnerabilities.

[0044] In block 302, a baseline repository of all third-party libraries is generated. The baseline repository can include library information from multiple publicly available third-party libraries (e.g., SourceClear Knowledge Center, Mitre's CVE database, Ruby Advisory Database, OSS Index, etc.). This repository can include a list of all known third-party libraries such that some libraries within the repository may not be used by any application or service deployed by a user testing for CVEs. For example, the baseline repository can include thousands of third-party libraries used in various types of APIs with various functions that are readily accessible within the public domain.

[0045] In block 304, deployed applications are mapped to their third-party library dependencies. Using the baseline repository generated in block 302, the third-party libraries stored within the repository can be linked to each application that uses each third-party library. For example, the repository can have hundreds of third-party libraries related to network connectivity. One application of a service provider can use half of these third-party libraries, and another application of the service provider can use only some of these libraries. Each actively deployed application can be mapped or linked to each third-party library that can be called or otherwise implemented by any code or microservice within the application. Mapping the deployed applications to their third-party library dependencies can include dependency version information. This can provide a snapshot of the current state of each third-party library used by each application.

[0046] In block 306, third-party libraries are mapped to their corresponding source repository URIs. Open-source, public vendor, and closed vendor URIs can include release notes and change logs for each third-party library. Mapping the source repository URIs to third-party libraries can indirectly link the deployed applications using the third-party libraries to the source repository URIs. Thus, any release notes or change logs accompanying the third-party library versions provided by third parties can be linked to each application. This can allow for a dynamic and real-time association of each application with the latest release notes or change logs provided by third parties. For example, as described in block 304, an application can be linked to a third-party library, and the application can be indirectly linked to the URI corresponding to the library. A third party can publish updated information (e.g., release notes, change logs, updated library versions) about the URI of the library. Since the libraries mapped to the application were previously linked to the source repository URIs, the updated information for the third-party libraries can be retrieved using the URIs, eliminating the need to create new mappings to retrieve the updated information.

[0047] In some instances, the source repository URI information can be mapped to each third-party library within the third-party library repository generated in block 302. This can create a more complete repository by linking URI information that may not be used in the current CVE analysis but can be used for future CVE analysis. In some instances, the source repository URI information can be mapped only to third-party libraries used by the application being texturized as a CVE. By avoiding mapping URI information corresponding to libraries not used by the application being examined, consumption of computing resources can be avoided.

[0048] As described in blocks 302, 304, 306, the result of the generation of the baseline repository and subsequent mapping of dependencies is a dependency tree similar to the Figure 1 dependency tree. This reverse mapping of the dependency tree can allow for the analysis of direct and transitive dependencies that conventional plugins cannot resolve because they are limited to their own libraries. This dependency tree and its contents can then be analyzed to determine which third-party libraries have been updated and which third-party libraries may include CVEs implemented within the system architecture.

[0049] In block 308, a list of third-party libraries with any changes is generated. Changes to third-party libraries can include vulnerability fixes, CVE fixes, or other code changes that may or may not affect the functionality of microservices implemented within the application. A web crawler can be programmed to automatically parse the URIs collected in block 306 to determine which third-party libraries (if any) have changed from the versions stored within the baseline repository generated in block 302. For example, the web crawler can determine which third-party libraries identified by the collected URIs have a newer version compared to the versions stored in the baseline repository. Third-party libraries identified as potentially having an updated version can be stored as a list for analysis of potential CVEs. Third-party libraries that are actively used and do not have a newer version as determined by the web crawler's access to the corresponding URIs can be ignored for CVE analysis because any potential CVE issues should have been addressed in previous updates to the APIs.

[0050] In block 310, a known vulnerability database is used to analyze the dependency tree created from blocks 302, 304, 306. A known vulnerability database sourced from the internet can be used to search for issues within the dependency tree, particularly regarding the list of third-party libraries with changes generated in block 308. The known vulnerability database can include a list of all bugs caused by known CVEs that have been practiced and reported by various entities using third-party libraries. The direct and transitive dependencies of the dependency tree can be analyzed to determine if any known CVE issues exist.

[0051] Release notes and change logs for a baseline third - party library list with changes generated in block 308 can be collected and parsed for analysis. The release notes and change logs can be run through a natural language processing (“NLP”) engine that understands the semantics of software vulnerability fixes and vulnerabilities (such as CVEs, remote command execution (“RCE”), etc.). The NLP engine can be used to determine whether a known CVE has been fixed in a newer version of the library compared to the current version of the library implemented in the API. For example, the NLP engine can determine that a known CVE present in the version of the third - party library currently used by the API has not been fixed in a newer version of the third - party library. In this instance, since the new version does not address the CVE issue, the NLP engine can determine not to retrieve the latest version of the third - party library from the source or vendor. Thus, the current version will not be updated to the latest version. If the NLP engine determines that a newer version of the third - party library dependency will fix the CVE issue, the newer version can be retrieved and applied in the API to replace the outdated version of the library.

[0052] In block 312, a list of vulnerable third - party libraries and microservices is generated. The list can be generated based on the analysis performed in block 310. The results of processing the release notes and change logs of the library versions with changes using the NLP engine in block 310 can be tabulated based on the NLP analysis in block 310. The list can include all direct and transitive dependencies with vulnerabilities, the corresponding versions that have been fixed, and a log recording any changes made in the updated library versions. The list can also include all microservices and APIs potentially affected by vulnerabilities due to vulnerable direct and transitive dependencies. Alternatively, a separate list of affected microservices or APIs can be generated.

[0053] In block 314, a backward compatibility check is performed between the current version and the new version of the third - party library. Backward compatibility changes for any new versions of dependencies with fixes or changes can be checked against the current version of the dependencies. This can ensure that an update to a newer version of the third - party library does not break the existing API. In some instances, when an update is recommended to fix a known CVE, a backward compatibility tool can be used to determine whether updating the dependency will cause an API break. If an update to a newer version of the dependency is expected to cause an API break, a manual change to the dependency code can be recommended to address the expected break. Dependencies determined to have no compatibility changes that would cause a break can be freely updated without issues. As described in block 312, block 314 can be automatically performed after identifying the list of vulnerable third - party libraries and microservices. For example, a tool such as the APIDIFF tool [2] can be used to perform the backward compatibility analysis.

[0054] Figure 4Shows the pseudo-logic that can be used to aggregate a list of vulnerable third-party libraries. The product can be any software package (e.g., a software package licensed to a third party) that includes one or more microservices. In some instances, the library can have a newer version that can address issues in the current or baseline version being implemented in the microservices within each product.

[0055] The pseudo-logic can include the processes described in blocks 308, 310, 312, and 314. Line 408 can include the initialization of the "for" loop logic such that the remainder of the logic provided by lines 410 to 424 is executed when it is determined that the library has been updated. The determination that the library has been updated and that the for loop logic should be executed is described in blocks 308 and 310 of Figure 3A If the library has been updated, then line 410 of the pseudo-logic can be executed to obtain the release notes and change log, which can correspond to the process described in block 310 of Figure 3A Line 412 can correspond to the NLP of block 310, which can determine whether there are any CVEs or security issues fixed by the newer library version. In addition to checking for CVEs as described in block 310, the embodiments can also check for non-CVE issues, such as security issues. A security issue can be any error or potentially vulnerable part other than a CVE. For example, a security issue may not be a known vulnerability and thus not a CVE, but may be an isolated instance of a security vulnerability specific to a dependency, where an updated version of the dependency may seek to address the security issue.

[0056] Line 414 can correspond to the process described in block 314 of FIG. 3, which describes performing a backward compatibility check. Blocks 312 can be executed at lines 418 and 420, which include, when repeating the for loop of line 408, obtaining information for each vulnerable library and then generating a list of vulnerable libraries, adding new vulnerable libraries to the list. Lines 426 and 430 include creating an overall list of vulnerable libraries across all microservices for each product. Thus, the for loop starting at line 406 determines whether each library in the microservice has been updated or has a new version available, and the for loop of line 404 executes the for loop of line 406 for each microservice within the product. The for loop of line 402 can sequentially execute all of the pseudo-logic to determine which libraries have been updated across each microservice of each product.

[0057] B. Measuring the Security Exposure of Microservices

[0058] After determining that a microservice depends on a third - party library with a known vulnerability (as determined in boxes 302 to 314), the scope of the CVE can be determined. After creating a list of vulnerable third - party libraries and microservices in box 312, the problems caused by the CVE can be quantified to assess how many APIs in the microservices affected by the CVE are impacted. This quantification can be related to the amount of business functionality affected due to the disrupted APIs. Various test suites can be run to determine which code paths and which APIs are affected by the dependency vulnerability. A report can be generated to show the affected APIs and the affected code paths in each microservice. A risk score can be assigned to each API affected by the CVE based on factors including the severity of the vulnerability, the number of code paths affected by the problem for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies with known CVEs that affect the API.

[0059] The risk score can be associated with the microservice or the API, depending on one or more third - party libraries affected by the CVE. The risk score can be used to determine whether to implement an update to the dependency disrupted by the CVE or to update to a newer version that includes the CVE but has significant functional updates. For example, when the number of code calls involving the CVE is high, the risk score associated with the dependency is high. When the number of code calls involving the CVE is low, the risk score associated with the dependency is low. A risk score determined to be greater than a certain threshold level may result in recommendations to take certain measures to mitigate the risk (such as updating the dependency version, providing a notification report with the reasons for the high - risk score).

[0060] Figure 3B is a flowchart for continuously managing the security exposure of microservices in vulnerability management based on the measurement and reporting of some instances. In box 316, one or more test suites can be run to measure the characteristics of the impact of the CVE on the affected microservices and APIs. Test software suites can be used to test the code paths of microservice calls. When the test coverage is high, the application of the test suite can improve the accuracy of the measurement characteristics of the CVE impact. For example, when most of the code paths in the application are tested by the test suite, the test coverage may be high. When too few code paths are tested by the test suite, the test coverage may be low. Too low test coverage may not comprehensively describe the impact of the CVE in the application.

[0061] The code interceptor can be run together with the test suite. A namespace can be created for each affected vulnerable library. An interceptor acting as a code hook can be implanted into the code of the affected library to record any code that executes in the namespace. The code executed in the namespace identified and retrieved by the interceptor can be recorded in a database. This can allow quantifying the number of code calls for the specific code described in the namespace. Quantifying the number of code calls during testing can determine which code (if any) corresponding to each namespace poses a higher vulnerability or exposure risk. For the following example, assume a high test coverage (e.g., 90%). In one instance, compared to the code with a CVE being called only once during testing, the code call with the CVE may be called multiple times, which may pose a higher security risk. During the test suite run, the microservice may never call the code with multiple CVEs, so the threat to security is even lower. Code calls without a CVE do not pose a threat to security.

[0062] In block 318, the risk level of the CVE impact is determined. After running the test suite to record each code hook within the database, the database of the collected code hook information can be analyzed to determine which APIs are affected by the code calls and the number of times the namespace is called for each API call. By analyzing the number of times an API executes code in the namespace, the overall impact on each API can be determined. Based on the affected APIs and the frequency of implementing these APIs in the microservice, the application of a specific service can be assigned a certain risk score. For example, an API with vulnerable dependencies can result in a high risk score in one usage instance (e.g., a business application), while the same API may result in a lower risk score in another usage instance. The risk score of the corresponding application can be assigned based on the context of the application in the business environment. For example, adding a credit card in the payment option may be more critical than sending a confirmation of receipt of the freight, so although the affected API is used in both context settings, it may be given a higher risk score.

[0063] There can be various threshold levels to classify the affected microservices. The threshold level can be the maximum number of times the library code executing the CVE is called for an API call. For example, a low threshold can have a higher number of allowable affected code calls, a medium threshold can have a lower number of allowable affected code calls, and a higher threshold can have an even lower number of allowable affected code calls. In some instances, certain code calls can be prioritized according to the context of the business application. For example, the risk score of an API can be doubled to assign more weight to the specific API compared to other APIs. Depending on the context of the application, this can make the priority of certain API functions higher than other APIs. Then the attribute weights can be compared with a given threshold level to determine whether the API places the microservice at low, medium, or high risk. As understood by those skilled in the art, other categories can also be used in addition to low, medium, and high risks.

[0064] If the impact level of the affected API drops below the threshold (e.g., percentage) such that the implementation of the API does not pose a significant security threat to the functionality of the application, no action is taken. If the impact level of the affected API is greater than the threshold at which the API may pose a significant security threat, it is determined whether to update the current version of the affected dependencies of the API to the latest version.

[0065] In some instances, the threshold can be determined in any number of ways that would be conceivable to a person skilled in the relevant art. Any part of the dependency tree (e.g., packages, applications, microservices, APIs, libraries, etc.) can be given a threshold related to another part of the dependency tree. For example, a threshold of 50% can be assigned to an application such that if 50% or more of the libraries called within the application have a CVE, some remedial action can be taken to provide a notification including information about the CVE or to reduce the threshold level to an acceptable operating level. Different threshold levels can be assigned to various parts of the dependency tree. Continuing with the previous example of an application with a threshold level of 50%, another application used in a package operation has a threshold level of 20%. In some instances,

[0066] In some instances, the code that is not called during testing can be determined. The database storing the code calls can initialize a zero value for each namespace. If the code of a specific namespace is never called, after running various test suites, the attribute value of the code in the database can be zero. This can mean that the code of the library called for the API does not need to be updated as it is neither harmful nor beneficial to the operation of the API.

[0067] Figure 5Illustrate the pseudo - logic that can be used to measure security exposure according to some examples. The pseudo - logic can include the processes described in blocks 316 and 318. In some examples, the name of the detected vulnerability can be determined for each dependency within the vulnerable library list.

[0068] At lines 502 and 504, a mapping or dependency tree of microservices, APIs, and third - party libraries can be generated. The libraries collected in block 302 can be used to generate the dependency tree according to the process described in Figure 3A block 304. At line 506, the dependencies mapped in lines 502 and 504 and the Figure 4 pseudo - logic can be used to create a list of vulnerable libraries. The for loop at line 508 can be executed to analyze each element in the vulnerable library list (e.g., the code section within the vulnerable dependency). Lines 510 and 512 can include the process described in Figure 3B block 316 for implementing code hooks in the vulnerable library code to determine the number of times a microservice calls a portion of code disrupted by a CVE. The code hooks can collect metrics on the frequency and timing of calling a certain API to measure the impact. For example, the code hooks can increment the count of API calls for determining the impact level or weight. The post - hooks can write to a file or other data storage to save information such as the API call count for the API and / or the affected business product or service. This stored information can be used to calculate the overall risk and impact. The for loop at line 514 can run a software build with a test suite to capture the impact percentage (e.g., risk score) of the impacted APIs, including the CVE name and other CVE - related information. The for loop at line 514 can be described by the process in Figure 3B block 318.

[0069] C. Fix Vulnerabilities and Generate a Report

[0070] In block 320, it is determined whether the risky dependencies are stable and backward - compatible. Using the microservice dependency version mapping generated in blocks 302 to 312, all deployed microservices at risk that need to be patched or upgraded can be identified, as described in blocks 316 and 318. Microservices with dependencies having a risk score greater than a threshold determined in block 318 can be analyzed to determine what measures should be taken to address the risk. Similar to the process described in block 314, an API code comparison tool (e.g., the APIDIFF tool [2]) can be used to determine the backward - compatibility between the current version and the new version of a third - party library.

[0071] In block 322, based on the stability and backward compatibility of the dependent versions, remedial measures are taken to handle the risk dependencies. If the backward compatibility of the new version of the affected dependency is broken or there is no available fix, a notice or report can be generated to communicate the affected dependency version, CVE issues, and other relevant information to the relevant users. This report can help assess the risk of the affected business functions based on the affected APIs. This assessment can assist in decision-making on whether to fix or control the issue by changing the business processes to avoid the affected APIs. In instances where there are no backward compatibility issues, measures can be taken based on the types of affected applications and microservices. If there are no downstream dependencies, the microservice can be rolled back to a previous stable version. Otherwise, the microservice can be updated to a fixed version of the dependency. This can trigger a continuous integration build that runs test suites and functional tests and provides a continuous delivery pipeline that can be deployed in production. In some instances, the fix can include updating the current version of the affected dependency to another version of the dependency with a lower risk score, such that the other version may still include CVE issues.

[0072] III. Continuous Vulnerability Management System

[0073] Figure 6 A block diagram depicting a continuous vulnerability management system according to one example. The continuous vulnerability management system 600 can include a processor 602, a bus 604, a communication port 606, and a memory 608. The Figure 6 processor (e.g., processor 602, bus 604, communication port 606, and memory 608) therein can be integrated into a single structure. For example, the components can be within a single housing. In other examples, Figure 6 the components shown therein can be distributed (e.g., in separate housings) and electrically connected to each other. The continuous vulnerability management system 600 can perform any function for continuous vulnerability management described by various embodiments of the present disclosure, perform transition regularized non-negative matrix factorization, and provide sequential recommendations.

[0074] The processor 602 can perform one or more operations to implement some examples. The processor 602 can execute instructions stored in the memory 608 to perform the operations. The processor 602 can include one processing device or multiple processing devices. Non-limiting examples of the processor 602 include a field programmable gate array (“FPGA”), an application specific integrated circuit (“ASIC”), a microprocessor, and the like.

[0075] Processor 602 may be communicatively coupled to memory 608 via bus 604. The non-volatile memory 608 may include any type of memory device that retains stored information when power is removed. Non-limiting examples of the memory 608 include electrically erasable programmable read-only memory (“EEPROM”), flash memory, or any other type of non-volatile memory. In some examples, at least some of the memory 608 may include a medium from which the processor 602 can read instructions. A computer-readable medium may include an electronic, optical, magnetic, or other storage device capable of providing computer-readable instructions or other program code to the processor 602. Non-limiting examples of the computer-readable medium include (but are not limited to) a disk, a memory chip, a ROM, a random access memory (“RAM”), an ASIC, a configured processor, an optical storage device, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler or interpreter from code written in any suitable computer programming language, including, for example, C, C++, C#, etc.

[0076] The CVECVE database 618 may include a list of CVEs known in the entire public domain, including any information related to each CVE. The library database 620 may include any third-party library that is identifiable and retrievable using a URI. In some instances, the CVE database 618 and the library database 620 may be a single database storing repositories and CVE information. The library database 620 may be a private database maintained by a vendor including private libraries. The communication port 606 may interface with the CVE database 618 to transmit information about the CFA to the continuous vulnerability management system 600. The communication port 606 may interface with the library database 620 to transmit information related to third-party libraries (such as release notes, change logs) to the continuous vulnerability management system 600. The CVE and library information received by the communication port 606 is transmitted to the memory 608 via the bus 604. The memory 608 may store any received concentration distribution and any received sensory information.

[0077] The memory 608 may include a release notes and change log database 610 to store release notes and change logs for each version of the repository. The memory 608 may include program code for a natural language processing engine 612, a code comparison module 614, and a web crawler module 616. The natural language processing engine 612 may use NLP to determine whether a known CVE has been fixed in a newer version of the library compared to the current version of the library implemented in the API. When a suggestion to update to fix a known CVE is made, the code comparison module 614 may be used to determine whether the update dependencies will cause an API break. The web crawler module 616 may use a URI to locate and retrieve library content and version data in the public domain.

[0078] The components of the continuous vulnerability management system 600 can be used to implement the described examples, including Figure 3A and 3B the process flows described in. For example, a repository of the current library can be generated according to the process described in block 302. The library database 620 can communicate with the communication port 606 of the continuous vulnerability management system 600. For example, the library database 620 can be a server located remotely from the continuous vulnerability management system 600, where communication between components can be established via the Internet. The communication port 606 can receive libraries and information related to the libraries that can be stored in the memory 608. The web crawler module 616 can be used to search the public domain, including the library database 620, to determine whether any libraries used by the microservices have been updated or whether updates are available. This process can include the process described in block 308 of Figure 3A .

[0079] The library database 620 can include release notes and change logs that can be stored in the release notes and change log database 610. As described in block 310 of Figure 3A , NLP can be used to analyze the information stored in the release notes and change log database 610. Compared with the current version of the library implemented in the API, a natural language processing engine 612 can be used to determine whether known CVEs have been fixed in a newer version of the library. Information about known CVEs can be passed from the CVE database 618 to the communication port 606 for analysis by the natural language processing engine 612. By analyzing the release notes and change logs, the natural language processing engine 612 can generate a list of vulnerable third-party libraries and corresponding microservices as described in block 312 of Figure 3A .

[0080] The code comparison module 614 can be used to compare the current version of the code of the dependencies with the newer version of the dependencies exported from the library database 620 and stored in the memory 608. The memory 608 can include a database of each currently used library on which each microservice in each package depends. The code comparison module 614 can perform a line-by-line syntax analysis to determine which parts of the code of each library have been changed. Distinguishing the current version of the library from the newer version can be used to determine whether the newer version is backward compatible with the current version, as described in block 314 of Figure 3A and Figure 3B block 320 of. Determining whether backward compatibility is available can allow the continuous vulnerability management system 600 to provide recommendations to not update the current version of the library to the newer version of the library to prevent breaking the microservices.

[0081] In some instances, a local repository of known CVEs can be created within the memory 608 to reduce the processing time when generating a list of affected dependencies and microservices. For example, a database of known vulnerabilities on the Internet can be collected from the CVE database 618 and other static sources (such as vulmon.com) and stored in a comprehensive database in the memory 608. Accessing the database locally, rather than communicating CVE updates over the Internet, can shorten the processing time. The local database containing CVEs can be kept current by polling for changes in the known vulnerability database on the Internet intermittently or on demand.

[0082] IV. Continuous Vulnerability Management Method

[0083] Figure 7 is a process flow diagram of a method for protecting vulnerabilities in a software package according to an example. The software package can be executed using a computer system. Some processes of continuous vulnerability management can be described according to previous examples.

[0084] In block 702, a set of libraries corresponding to third-party software used by the software package is received. The software package can have multiple microservices depending on the number of libraries. The libraries can be procured from third-party vendors and stored in a database of the computer system.

[0085] In block 704, a list of disrupted libraries from the set of libraries is determined. Each library in the list of disrupted libraries may be affected by a vulnerability. In some instances, the list of disrupted libraries can be determined by storing the URI of each library in the set of libraries in the database of the computer system. A web crawler can search the public domain for a newer version of each library in the list of disrupted libraries based on the URI of each library. The release notes and change logs associated with the newer version can be stored in the database. A natural language processor engine of the computing system can be used to analyze the release notes and change logs to determine one or more fixable libraries from the list of disrupted libraries. The newer version of the fixable library can eliminate or reduce the impact of the vulnerability in the current version of the fixable library.

[0086] In block 706, one or more disrupted libraries from the list of disrupted libraries that the application of the software package depends on are determined. The application can execute code from one or more disrupted libraries and can call one or more disrupted libraries to perform operations of the software package.

[0087] In block 708, multiple code calls that include vulnerabilities are identified. The multiple code calls can be determined for each of one or more disrupted libraries. The code calls can be made through the APIs of the applications of the software package. The code calls can be made to the code of each of one or more disrupted libraries. A test suite can be run to determine the number of times each portion of the CVE-affected code in each dependent library is called by the APIs in the software package.

[0088] In block 710, a risk score is assigned to the API based on the multiple code calls. The risk score of the API depends on the sensitivity of each library on which the API depends. For example, the API can use multiple libraries to call code. None of this code in these libraries includes a CVE, so a low risk score or no risk score can be assigned to the API. As another example, these libraries may have code with a CVE, but the API does not call these disrupted portions of the code. Therefore, a low risk score or no risk score can be assigned to the API. As another example, the API can call code from a library that includes a CVE. More code calls, including the CVE that the API makes to the library, increase the risk score assigned to the API. In some instances, assigning the risk score can include determining the dependencies from each of one or more disrupted libraries related to the application. For example, the risk score for a direct dependency can be different from the risk score for a transitive dependency. A higher risk score can indicate a higher probability of a security breach, while a lower risk score can indicate a lower probability of a security breach.

[0089] In block 712, the risk score of the API is compared with a threshold risk value. The threshold risk value can be assigned according to the described instances.

[0090] In block 714, in response to the risk score exceeding the threshold risk value, a remedial action is taken for each disrupted library called by the API. The remedial action can include generating a report containing information about the disrupted library, updating the library version, and / or restoring the library version to a backward-compatible version. The remedial action can be taken to report the presence of the CVE in the library or to address the CVE. In some instances, a report can be generated that includes a list of disrupted libraries, the risk score of the API, and a notification that the newer version of the library is not backward-compatible. The report can be transmitted to one or more user devices operated by the user implementing the application. In some instances, a code differentiation tool of the computer system can be used to compare the code of the newer version of the library with the code of the current version of the library for each of one or more disrupted libraries. As a result of the comparison, it can be determined that the newer version is not backward-compatible with the current version.

[0091] V. Computer System

[0092] Figure 8 A block diagram depicting an example computer system that can be used with the systems and methods according to one example.

[0093] Any computer system referred to herein can utilize any suitable number of subsystems. An example of such subsystems is shown in the computer device 800 in Figure 8 . In some embodiments, the computer system includes a single computer device, where the subsystems can be components of the computer device. In other embodiments, the computer system can include multiple computer devices with internal components, and each computer device is a subsystem. The computer system can include desktop computers, laptop computers, tablet computers, mobile phones, and other mobile devices.

[0094] Figure 8 The subsystems shown in are interconnected via a system bus 815. Additional subsystems such as a printer 814, a keyboard 818, a storage device 819, a monitor 816 coupled to a display adapter 820, etc. are shown. Peripheral devices and I / O devices coupled to an input / output (I / O) controller 811 can be connected to the computer system by various means known in the art, such as input / output (I / O) ports 817 (e.g., USB,

[0095] ). For example, the I / O port 817 or an external interface 821 (e.g., Ethernet, Wi-Fi, etc.) can be used to connect the computer device 800 to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus 815 allows the central processing unit 813 to communicate with each subsystem and control the execution of instructions from the system memory 812 or the storage device 819 (e.g., a fixed disk such as a hard disk drive or an optical disk), as well as the exchange of information between the subsystems. The system memory 812 and / or the storage device 819 can be embodied as a computer-readable medium, which can be a non-transitory computer-readable medium. Any data referred to herein can be output from one component to another and can be output to a user.

[0095] The computer system can include, for example, multiple identical components or subsystems connected together by an external interface 821 or by an internal interface. In some embodiments, the computer system, subsystems, or devices can communicate via a network. In such cases, one computer can be regarded as a client, and another computer can be regarded as a server, where each computer can be part of the same computer system. The client and the server can each include multiple systems, subsystems, or components.

[0096] It should be understood that any one of the embodiments of the present invention can be implemented using hardware (such as an application specific integrated circuit or a field programmable gate array) and / or using computer software in the form of control logic, where a general purpose programmable processor is modular or integrated. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosures and teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the embodiments of the present invention using hardware and combinations of hardware and software.

[0097] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python and using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, and the like. The computer-readable medium can be any combination of such storage or transmission devices.

[0098] Such programs can also be encoded and transmitted using a carrier signal suitable for transmission via wired, optical, and / or wireless networks compliant with various protocols including the Internet. Thus, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such a program. The computer-readable medium encoded with the program code can be packaged together with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (such as a hard disk drive, a CD, or an entire computer system), and can exist on or within different computer products in a system or network. A computer system can include a monitor, a printer, or other suitable display for presenting any of the results mentioned herein to a user.

[0099] Any method described herein may be performed, in whole or in part, by a computer system including one or more processors configured to perform the respective steps. Accordingly, embodiments may relate to a computer system configured to perform the steps of any method described herein, which may have different components for performing the respective steps or groups of steps. Although presented in numbered steps, the steps of the methods herein may be performed simultaneously or in a different order. Additionally, portions of these steps may be used in conjunction with portions of other steps of other methods. Further, all or part of these steps may be optional. Additionally, any step of any method may be performed by a module, circuit, or other means for performing these steps.

[0100] Without departing from the spirit and scope of the embodiments of the present invention, the specific details of the specific embodiments may be combined in any suitable manner. However, other embodiments of the present invention may relate to specific embodiments related to each individual aspect or specific combinations of these individual aspects.

[0101] The foregoing description of the exemplary embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms described, and many modifications and variations are possible in light of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable those skilled in the art to best utilize the invention in various embodiments and to make various modifications suitable for the particular use contemplated.

[0102] Unless specifically stated to the contrary, the recitation of "a," "an," or "the" is intended to mean "one or more." The use of "or" is intended to mean "inclusive or" rather than "exclusive or" unless expressly indicated to the contrary. The mention of a "first" component does not necessarily require the provision of a second component. Also, unless expressly stated, the mention of a "first" or "second" component does not limit the mentioned component to a particular location. The term "based on" is intended to mean "at least partially based on."

[0103] All patents, patent applications, publications, and descriptions mentioned herein are incorporated herein by reference in their entirety for all purposes. It is not admitted that they are prior art.

[0104] VI. References

[0105] [1]Ibrahim, S., Bashah Idris, N., Munro, M., & Deraman, A. (n.d.). A REQUIREMENTS TRACEABILITY TO SUPPORT CHANGE IMPACT ANALYSIS.

[0106] [2]Brito, A., Xavier, L., Hora, A., & Valente, M. T. (2018). Why and how Java developers break APIs. 2018 IEEE 25th International Conference on Software Analysis, Evolution, and Reengineering (SANER). doi:10.1109 / saner.2018.8330214

[0107] [3]Fenton, C (October 03, 2017). How to Check OpenSource Code for Vulnerabilities - DZONE Security. Retrieved from https: / / dzone.com / articles / how-to-check-open-source-code-for-vulnerabilities.

Claims

1. A method for protecting vulnerabilities in a software package, the method comprising the computer system performing the following operations: Receiving a set of libraries corresponding to third-party software used by the software package; Determining a list of disrupted libraries from the set of libraries, wherein each library in the list of disrupted libraries is affected by a vulnerability; Determining one or more disrupted libraries from the list of disrupted libraries on which the application of the software package depends, wherein the application executes code from the one or more disrupted libraries, and wherein the application calls the one or more disrupted libraries; Identifying, for each library in the one or more disrupted libraries, a plurality of code calls that include the vulnerability, wherein the code calls are made by an application programming interface (API) of the application of the software package, and wherein the code calls are made to code within each of the one or more disrupted libraries; Assigning a risk score to the API based on the plurality of code calls; Comparing the risk score of the API with a threshold risk value; And In response to the risk score exceeding the threshold risk value, causing a remedial action for each disrupted library called by the API.

2. The method according to claim 1, further comprising: Storing a uniform resource identifier (URI) of each library within the set of libraries in a database of the computer system; Using a web crawler implemented by the computer system to search the public domain for a newer version of each library in the list of disrupted libraries based on the URI of each library; And Storing release notes and change logs associated with the newer version in the database.

3. The method according to claim 1, further comprising: Using a natural language processor engine of the computer system to analyze the release notes and change logs to determine one or more fixable libraries from the list of disrupted libraries, wherein the newer version of the fixable library eliminates or reduces the impact of the vulnerability in the current version of the fixable library, wherein the remedial action includes updating the current version of the fixable library to the newer version of the fixable library.

4. The method according to claim 1, further comprising: Using a code differentiation tool of the computer system to compare the code of the newer version of a library with the code of the current version of the library for each of the one or more disrupted libraries; And In response to the comparison by the code differentiation tool, determining that the newer version is not backward compatible with the current version.

5. The method according to claim 4, further comprising: Generating a report that includes the list of disrupted libraries, the risk score of the API, and a notification that the newer version is not backward compatible; And Transmitting the report to one or more user devices operated by a user implementing the application.

6. The method according to claim 1, wherein assigning a risk score includes determining the dependencies of each of the one or more disrupted libraries relative to the application, wherein the assignment of the risk score for direct dependencies is different from the assignment of the risk score for transitional dependencies.

7. The method according to claim 1, wherein a higher risk score indicates a higher probability of a security breach occurring, while a lower risk score indicates a lower probability of a security breach occurring.

8. A non-transitory computer-readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method according to any one of claims 1-7.

9. A system for protecting vulnerabilities in a software package, comprising: a processing device, a communication port, and a non-transitory computer-readable medium comprising instructions executable by the processing device to perform the method according to any one of claims 1-7.

Images