SYSTEM AND METHOD FOR SELECTING AND DISCOVERING VULNERABLE SOFTWARE PACKAGES - Patent application

Abstract

A system and method for discovering vulnerabilities in software packages, the method including: identifying a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, where the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package, and identifying the at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, where the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

Description

[Technical field]

[0001] This application claims the benefit of U.S. Patent Application No. 17 / 145,893, filed January 11, 2021, the contents of which are incorporated herein by reference.

[0002] FIELD OF THE DISCLOSURE This disclosure relates generally to detecting software vulnerabilities, and more specifically to increasing vulnerability coverage in detecting software vulnerabilities. [Background technology]

[0003] As software-based technologies increasingly dominate everyday life, detecting and correcting software vulnerabilities has become critical for systems to function normally. Some existing solutions utilize human operators who are trained to review software and processes using such software to identify potential vulnerabilities. These processes may involve manual review of code (e.g., manually crawling software libraries looking for vulnerable software packages) or user-reported issues. However, these processes are highly inefficient compared to automated solutions, are subject to human error, and often require subjective judgments about whether vulnerabilities exist, which can lead to inconsistent results.

[0004] There are several automated solutions that involve scanning for software vulnerabilities. However, these solutions face significant challenges in accurately identifying software vulnerabilities. In particular, while some automated solutions can check for already known issues, these solutions have difficulty identifying previously unknown software, unknown versions of existing software, or software that otherwise lacks some form of standardized format. In the case of operating system vulnerabilities, most major vendors provide consistent standard feeds that can be utilized by existing solutions, but other software providers may not provide consistent standard feeds. This can be particularly problematic for open source software packages, or any other software that does not have a single source of truth.

[0005] Therefore, it would be advantageous to provide a solution that overcomes the above-mentioned challenges. Summary of the Invention

[0006] A summary of some exemplary embodiments of the present disclosure follows. This summary is provided for the convenience of the reader to provide a basic understanding of such embodiments, and does not completely define the breadth of the disclosure. This summary is not an extensive overview of all contemplated embodiments, and is not intended to identify key or critical elements of all embodiments, nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description presented later. For convenience, the terms "some embodiments" or "specific embodiments" may be used herein to refer to a single embodiment or multiple embodiments of the present disclosure.

[0007] Certain embodiments disclosed herein include a method for discovering vulnerabilities in software packages, the method including: identifying a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, where the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package, and identifying the at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, where the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

[0008] Certain embodiments disclosed herein also include a non-transitory computer-readable medium having instructions stored thereon that cause a processing circuit to execute a process to identify a potential source of at least one vulnerability in at least one potentially vulnerable software package of the plurality of software packages, wherein the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package, and identify the at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, wherein the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

[0009] Certain embodiments disclosed herein also include a system for discovering vulnerabilities in software packages, the system including a processing circuit and a memory, the memory including instructions that, when executed by the processing circuit, configure the system to: identify a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, where the potential source of each vulnerability is a modification to one of the at least one potentially vulnerable software package, and identify the at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, where the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package. [Brief description of the drawings]

[0010] The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the end of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0011] [Figure 1] FIG. 1 is a network diagram utilized to explain various disclosed embodiments.

[0012] [Diagram 2] 1 is a flow chart illustrating a method for discovering unknown software vulnerabilities in software packages according to one embodiment.

[0013] [Diagram 3] 1 is a flow chart illustrating a method for identifying potential sources of vulnerabilities according to one embodiment.

[0014] [Figure 4] 1 is an exemplary flow chart illustrating a method for mapping software packages to standard vulnerability identifiers according to one embodiment.

[0015] [Diagram 5] 2 is an exemplary schematic diagram of a vulnerability detector according to one embodiment; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] It is important to note that the embodiments disclosed herein are merely examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of this application do not necessarily limit any of the various embodiments described in the claims. Moreover, some statements may apply to some inventive features but not to others. In general, singular elements may be plural and vice versa, without loss of generality, unless otherwise indicated. In the drawings, like numerals refer to like parts throughout the several views.

[0017] Various disclosed embodiments include methods and systems for detecting software vulnerabilities. One or more repositories may be selected for analysis. Each repository stores software packages. Based on data associated with the software packages, one or more potential sources of vulnerabilities are selected for analysis among changes to the software packages in the selected repositories. The potential sources of vulnerabilities are identified using rules that may be based on factors such as, but not limited to, frequency of use, creation date, whether the software package is known to be open source, and combinations thereof.

[0018] In one embodiment, identifying potential sources of vulnerabilities may include any or all of the following: querying and analyzing change orders, tracing to a particular developer, analyzing code comments, analyzing release notes, and inferring potential vulnerabilities based on version identifiers. Each change order is an instruction to modify a portion of data and thus represents a change that is finalized or confirmed. A change order may include, but is not limited to, a commit description (also referred to herein as a "commit").

[0019] Based on the results of these steps, security-relevant changes to the software package that are potential sources of vulnerabilities are identified. A unique identifier may be created for the security-relevant change. The unique identifier may be utilized to anonymize the change while allowing later investigation into the specific change that introduced the vulnerability. Such anonymization of changes may be important to preserve sensitive information.

[0020] To identify vulnerabilities caused by these changes and thus identify vulnerable software packages caused by these changes, vulnerability identification rules are selected and applied to the data of each of the security-relevant changes. The vulnerability identification rules may be selected based on the availability of a version identifier for a software repository storing the software package. For example, a first rule may be selected when the software repository has the package version, a second rule may be selected when the repository has the release version but not the package version, and a third rule may be selected when the repository does not have any version identifier for the software package. The different rules may define circumstances in which a software package is considered vulnerable. Applying such vulnerability identification rules thus allows to objectively determine whether a given software package is vulnerable or not.

[0021] Each software package that has one of the identified vulnerabilities may be mapped to a known name in a standard software package naming scheme. Such a software package naming scheme may be, but is not limited to, a Common Platform Enumeration (CPE). CPE is a structured naming scheme that may be utilized for software vulnerabilities. CPE utilizes a common syntax for Uniform Resource Identifiers (URIs) and includes a formal name format, a method for checking the name against systems, and a description format for binding text and tests to the name. CPE also utilizes a dictionary that defines an agreed-upon list of names for CPE.

[0022] Each software package having one of the identified vulnerabilities may be further mapped to a standardized software vulnerability identifier, such as an identifier defined per Common Vulnerabilities and Exposures (CVE). The mapping of software packages to standardized software vulnerability identifiers may be based on a mapping of the software packages to names in a standard software package naming scheme.

[0023] In some embodiments, a dependency graph may be created or updated based on the identified vulnerabilities. The dependency graph includes nodes representing software packages connected by edges representing dependencies between the software packages. The dependency graph also includes metadata for the nodes representing the software packages identified as vulnerable. As a result, such a dependency graph enables identifying vulnerabilities caused by dependencies between software packages. For example, a first software package that is not itself vulnerable may depend on a second software package that is vulnerable, such that the dependency of the first software package on the second software package may represent a vulnerability.

[0024] The disclosed embodiments provide an automated process for detecting software vulnerabilities that does not rely on manual evaluation of code or comments and does not require rules created based on known vulnerabilities. The disclosed embodiments may be utilized to identify unknown vulnerabilities or vulnerabilities that have been reported but do not clearly match known vulnerabilities. Thus, the disclosed embodiments enable detection of more software vulnerabilities than existing automated solutions without requiring human error or subjective analysis that can produce inconsistent results.

[0025] Furthermore, the disclosed embodiments may enable detection of vulnerabilities before they are formally reported or even if they are improperly reported. Furthermore, the disclosed embodiments use vulnerability rules that are selected according to predetermined criteria that improve the objectivity of vulnerability detection. Thus, the disclosed embodiments enable improving the accuracy of software vulnerability detection such that more software vulnerabilities are detected without significantly increasing the number of false positives.

[0026] Additionally, the disclosed embodiments enable accurate matching of improperly identified vulnerable software packages to known software packages. In this regard, it is noted that the standardized version of a software package name often does not match the actual name of the software package (e.g., the name shown in the software package's metadata). As a non-limiting example, the actual name of a package may be shown as "org.apache.httpcomponents)_httpclient", while the CPE name of the package may be "apache:httpclient". Existing automated solutions are often unable to accurately identify changes to a particular software package when the changes originate from different sources, due to their inability to map packages to their respective standardized names.

[0027] 1 illustrates an example network diagram 100 that may be utilized to explain various disclosed embodiments. In the example network diagram 100, source repositories 120-1 through 120-N (hereinafter, for simplicity only, referred to individually as source repositories 120 and collectively as source repositories 120), vulnerability detector 130, and user device 140 are communicatively coupled via network 110. Network 110 may be, but is not limited to, a wireless, cellular or wired network, a local area network (LAN), a wide area network (WAN), a metro area network (MAN), the Internet, the World Wide Web (WWW), a similar network, and any combination thereof.

[0028] Each of the source repositories 120 stores software packages (not shown) that may be vulnerable. At least some of the source repositories 120 may be open source repositories that store open source software packages. Because open source software packages do not use a standardized format, it may not be possible to immediately identify known software vulnerabilities using predefined rules associated with different formats of the software packages. To this end, the vulnerability identifier 130 is configured to identify software vulnerabilities, as described herein. Identification of such vulnerabilities may identify unknown or otherwise improperly reported vulnerabilities, and may identify vulnerabilities in open source software packages, or other software packages that lack a known format.

[0029] The user device (UD) 140 may be, but is not limited to, a personal computer, a laptop, a tablet computer, a smartphone, a wearable computing device, or any other device capable of receiving and displaying notifications.

[0030] 2 is a flow chart 200 illustrating a method for discovering unknown software vulnerabilities in software packages according to one embodiment. In one embodiment, the method is performed by vulnerability detector 130 of FIG.

[0031] In S210, potential sources of vulnerabilities to be analyzed are identified. In one embodiment, S210 includes analyzing various data associated with the software package to identify specific changes as potentially causing vulnerabilities. In this regard, it is noted that the number of changes to software packages grows exponentially over time, such that analyzing each and every change for vulnerabilities is impractical, even for an automated solution. By selectively analyzing changes as described herein, the disclosed embodiments allow for reducing the excessive computing resource consumption required to analyze software packages that are subject to those changes, while still identifying most, if not all, previously undiscovered vulnerabilities.

[0032] In a further embodiment, S210 may also include selecting a repository from which the software packages are to be analyzed. Selecting a particular repository may further reduce the scope of data that must be analyzed, thereby further reducing the consumption of computing resources for the analysis.

[0033] In one embodiment, identifying potential sources of vulnerabilities is performed according to the flowchart shown in Figure 3. Figure 3 is a flowchart of S210 illustrating a method for identifying potential sources of vulnerabilities according to one embodiment.

[0034] At optional S310, repositories are selected for analysis. Repositories are selected for analysis such that the repositories being analyzed are more likely to have unknown, otherwise undiscovered, vulnerable software packages. For example, open source software repositories are more likely to contain unknown software packages than software repositories of major software developers. As another example, repositories that have more frequently accessed or updated software packages may be more important for analyzing new and emerging vulnerabilities.

[0035] Selecting repositories for analysis based on the likelihood of having unknown or undiscovered software packages reduces the use of computing resources required for such analysis. In this regard, it is noted that the total number of potential repositories is large, and analyzing all of these repositories for vulnerabilities is impractical, even for an automated system. Thus, the disclosed embodiments reduce the amount of data that needs to be scanned, thus improving the efficiency of the analysis.

[0036] In one embodiment, the repositories are selected based on the relative usage of the software packages stored in each repository compared to other repositories, hi further embodiments, the repositories are selected based on a feedback loop of user data, inferred popularity of repositories, package download statistics, or a combination thereof.

[0037] User data is analyzed through a feedback loop to determine which packages are used more frequently and therefore which repositories contain frequently used packages. A software package may be frequently used, for example, if the number of downloads of the software package within a particular time period (e.g., the past week) exceeds a threshold. Repositories may be selected based on frequency of package usage, for example, based on having one or more frequently used software packages, having a number of frequently used software packages that exceeds a threshold, having the highest number of frequently used software packages among a threshold number of repositories (e.g., the top 10 repositories with the most frequently used software packages), etc.

[0038] Inferring popular repositories may be accomplished by using an application programming interface (API) to recursively crawl repositories for package dependency manifests and determining which packages are most frequently depended on by other packages. A software package may be popular, for example, if the number of dependencies of other software packages on that software package exceeds a threshold. Repositories may be selected based on the popularity of the package, for example, based on having one or more popular software packages, having a number of popular software packages that exceeds a threshold, having the highest number of popular software packages out of a threshold number of repositories, etc.

[0039] The package download statistics may be obtained, for example, by querying a package manager API. The repository with the most downloaded software packages may be selected.

[0040] In steps S320-S360, various portions of the data indicative of changes that may be a source of vulnerabilities are analyzed to identify security-relevant changes that may be reflected, for example, in change orders, comments, notes, or other data associated with the software package, as described further below with respect to steps S320-S360.

[0041] It should be noted that steps S320 through S360 may be performed in any order or in parallel, and in at least some embodiments, only a portion of these steps may be performed. As discussed above with respect to S310, when a repository is selected, only the software packages in the selected repository are analyzed.

[0042] At S320, change order messages are obtained via query and analyzed. The change orders may be, for example, commits. To this end, S320 may include querying the change order messages and analyzing the messages based on keywords contained therein. In a further embodiment, S320 further includes applying a machine learning model trained to identify security-related keywords based on historical change order messages. Such a model may be further trained for text classification. Change orders that include security-related keywords are identified as potential sources of vulnerabilities.

[0043] At S330, data related to each software package is analyzed to track predefined developers represented therein. The developers may be security researchers or software developers, or may be developers known to have security concerns for a particular software package, so that commits from those developers are likely to be associated with potentially unknown security fixes. To this end, when such predefined suspect developers are identified for a software package, changes by those developers are identified as potential sources of vulnerabilities.

[0044] At S340, code comments for each software package are analyzed for security-related keywords. In one embodiment, S340 further includes applying a machine learning model trained to identify security-related keywords based on historical code comments. Such a model may be further trained for text classification. Changes indicated by comments containing security-related keywords are identified as potential sources of vulnerabilities.

[0045] At S350, the release notes of each software package are analyzed against the release date. Changes that added or modified newer software packages (e.g., software packages released less than a threshold period before the current time) are identified as potential sources of vulnerabilities.

[0046] At S360, version indicators in the files of each software package are analyzed to infer changes to files associated with the software package that may be a potential source of vulnerabilities. In an exemplary embodiment, the version indicators may be included in a manifest file, such that changes to the manifest file after a change that updated the software package to its current version identifier would be identified as a potential source of vulnerabilities. To this end, S360 may further include analyzing change orders to determine whether any change orders occurred after the change order that updated the software package to its current version.

[0047] In S370, based on the analysis performed in S320 through S360, one or more potential sources of vulnerability are identified, as described above with respect to those steps.

[0048] At optional S380, a unique identifier may be created and assigned to each of the identified vulnerability-related changes. The change may be a change made permanent via a change order, a change indicated in a code comment, a change indicated in a release note, etc. The unique identifier may be utilized to enable later investigation of the specific change that introduced the vulnerability and may further enable the change to be anonymized. Such anonymization of changes may be important to preserve sensitive information.

[0049] Returning to Figure 2, in S220, vulnerabilities are identified. The identified vulnerabilities may be unknown, improperly reported, or otherwise undiscovered. Identifying such vulnerabilities may also lead to identifying vulnerable software packages.

[0050] In one embodiment, S220 includes selecting and applying a vulnerability identification rule based on data associated with each software package that has undergone a change that is a potential source of a vulnerability identified in S210. The vulnerability identification rule may be selected based on the availability of a version identifier for a software repository storing the software package. In yet another embodiment, a first rule is selected when the software repository storing the software package has the package version or a package version is otherwise available for the software package, a second rule is selected when the repository for the software package has a release version but does not have the package version or a release version is otherwise available but a package version is not available, and a third rule is selected when the repository for the software package does not have any version identifier for the software package or a package version or a release version is otherwise not available for the software package.

[0051] In one embodiment, a first rule defines a vulnerable software package as a software package having a package version that is an earlier version of the version indicated in the most recent change instruction (e.g., the most recent commit). A second rule defines a vulnerable software package as a software package having a release version that is not temporally correlated with a change instruction (e.g., a release version associated with a release date that is not within a threshold number of days of the date indicated by the timestamp of the most recent commit to the software package). The release date of the release version may be stored in an available public repository. A third rule defines a vulnerable software package as a software package that is not temporally correlated with a release time indicated in data stored in a public repository (e.g., a software package having data indicating a creation time that is not within a threshold time of the most recent change indicated by a package manager such as NPM (Node Package Manager)).

[0052] At S230, each vulnerable software package (i.e., each vulnerable software package having an identified vulnerability) is mapped to a respective vulnerability identifier. In one embodiment, S230 includes mapping each identified vulnerable software package to a standardized name of a standard software package naming scheme, and mapping each identified vulnerable software package to a standardized software vulnerability identifier that is based on the standardized name of each identified vulnerable software package.

[0053] In one embodiment, each vulnerable software package is mapped to a respective vulnerability identifier using a process according to Figure 4. Figure 4 is an example flowchart of S230 illustrating a method for mapping software packages to standard vulnerability identifiers according to one embodiment.

[0054] In one embodiment, the process shown in Figure 4 further includes two sub-processes 400-1 and 400-2. In the first sub-process, the software package is mapped to a standardized software package name so that it can be accurately identified using the mapping. In the second sub-process, the software package is mapped to a standardized vulnerability identifier so that known types of vulnerabilities can be identified for the software package. In other embodiments, the method of Figure 4 may include only the second sub-process 400-2.

[0055] In the first sub-process 400-1, in S410, the package name indicated in the data of the software package is tokenized.

[0056] At S420, one or more possible standardized software package names for the software package are identified in one or more software package repositories. In one embodiment, S420 may include querying a package manager or other program configured to search one or more software package repositories that store data indicating names of the software packages in a standardized naming scheme, such as the Common Platform Enumeration (CPE). The query may utilize a tokenized name of the software package.

[0057] At S430, the software packages are mapped to standardized software package names based on the results returned from the query to the software package repository. In one embodiment, S430 includes tokenizing the possible standardized software package names identified at S420 and comparing the tokenized name of the software package to each possible tokenized standardized software package name. In a further embodiment, a score may be generated representing the degree of similarity between each pair of tokenized names, and the software package name and the standardized software package name having the highest score may be determined as the suitable mapping. In yet another embodiment, only the standardized software package names having a score above a threshold may be determined as the suitable mapping.

[0058] In the second sub-process 400-2, in S440, known vulnerabilities for the software package are identified based on the known package name of the software package. The known vulnerabilities have identifiers in a standardized vulnerability identifier format and may be identified by analyzing the change order history for the software package. Such a standardized format may be, for example, CVE (Common Vulnerabilities and Exposures).

[0059] At S450, the source code of the software package is analyzed to identify the actual name of the software package represented in the software package data.

[0060] At S460, a mapping between software packages and standardized vulnerability identifiers is created based on the known vulnerabilities identified at S440 and the actual names specified at S450. In one embodiment, the mapping may be extracted from a standard database such as, but not limited to, the National Vulnerabilities Database (NVD).

[0061] Returning to FIG. 2, at optional S240, a dependency graph may be created or updated based on the identified vulnerable software packages. The dependency graph defines dependencies between software packages and is created or updated to include the identified vulnerable software packages. Thus, the dependency graph shows dependencies on vulnerable software packages by otherwise non-vulnerable software packages. Such dependencies on vulnerable software packages may make otherwise non-vulnerable software packages more susceptible to problems and, as a result, may also be considered vulnerable. As a result, the dependency graph shows these indirect vulnerabilities, i.e., vulnerabilities that cannot be identified by analyzing the code of the software packages themselves, but are instead inherited by relying on vulnerable software packages.

[0062] At S250, a notification is generated based on the identified vulnerable software packages. The notification may indicate, but is not limited to, the identified vulnerable software packages, a dependency graph, both, etc.

[0063] 5 is an exemplary schematic diagram of vulnerability detector 130, according to one embodiment. Vulnerability detector 130 includes a processing circuit 510 coupled to a memory 520, a storage 530, and a network interface 540. In one embodiment, the components of vulnerability detector 130 may be communicatively coupled via a bus 550.

[0064] The processing circuitry 510 may be implemented as one or more hardware logic components and circuits. For example, and without limitation, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SoCs), graphics processing units (GPUs), tensor processing units (TPUs), general purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components capable of performing calculations or other manipulations of information.

[0065] The memory 520 may be volatile (eg, random access memory, etc.), non-volatile (eg, read-only memory, flash memory, etc.), or a combination thereof.

[0066] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in storage device 530. In another configuration, memory 520 is configured to store such software. Software shall be broadly construed to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable code format). The instructions, when executed by processing circuitry 510, cause processing circuitry 510 to perform various operations described herein.

[0067] The storage device 530 may be a magnetic storage device, an optical storage device, etc., and may be implemented, for example, as flash memory or other memory technology, a compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), or any other medium that can be used to store the desired information.

[0068] The network interface 540 allows the vulnerability detector 130 to communicate with, for example, the source repository 120, the user device 140, or both.

[0069] It should be understood that the embodiments described herein are not limited to the particular architecture illustrated in FIG. 4, and that other architectures may equally be used without departing from the scope of the disclosed embodiments.

[0070] Various embodiments disclosed herein may be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer-readable medium consisting of or consisting of a particular device and / or combination of devices. The application program may be uploaded to and executed by a machine having any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPUs), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by the CPU, whether or not such a computer or processor is explicitly shown. Additionally, various other peripheral units may be connected to the computer platform, such as additional data storage units, printing units, etc. Moreover, a non-transitory computer-readable medium is any computer-readable medium except a transitory propagating signal.

[0071] All examples and conditional language described herein are intended for educational purposes to assist the reader in understanding the principles of the disclosed embodiments and concepts contributed by the inventors to further the art, and should not be construed as being limited to such specifically described examples and conditions. Furthermore, all statements herein that describe principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, such equivalents are intended to include both currently known equivalents and equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

[0072] It should be understood that the use of a designation such as "first," "second," etc. to refer to an element herein generally does not limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to a first and a second element does not imply that only two elements may be used therein or that the first element must precede the second element in any manner. Also, unless otherwise specified, a set of elements includes one or more elements.

[0073] As used herein, the phrase "at least one of" followed by a list of items means that any of the listed items may be utilized individually, or any combination of two or more of the listed items may be utilized. For example, if a system is described as including "at least one of A, B, and C," the system can include A alone, B alone, C alone, 2A, 2B, 2C, 3A, a combination of A and B, a combination of B and C, a combination of A and C, a combination of A, B and C, a combination of 2A and C, a combination of A, 3B and 2C, etc.

Claims

1. 1. A computer-implemented method for discovering vulnerabilities in a software package, comprising: identifying a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, wherein the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package; identifying at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, wherein the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

2. 2. The method of claim 1, wherein the selected at least one vulnerability identification rule for a software package is a first rule when a package version is available for the software package, and the first rule defines a vulnerability as the software package having a package version that is an earlier version than a version indicated in a latest change instruction for the software package.

3. 3. The method of claim 2, wherein the selected at least one vulnerability identification rule for a software package is a second rule when a release version is available for the software package but a package version is not available for the software package, the second rule defining a vulnerability as the software package having a release version that is not within a threshold period of a most recent change order for the software package.

4. 4. The method of claim 3, wherein the selected at least one vulnerability identification rule for a software package is a third rule when neither a package version nor a release version is available for the software package, the third rule defining a vulnerability as the software package having a creation time that is not within a threshold period of the most recent change ordered by a package manager for the software package.

5. 2. The method of claim 1, wherein identifying a potential source of the at least one vulnerability further comprises at least one of: analyzing change order messages, tracing at least one predefined message, analyzing code comments for security-related keywords, analyzing release notes for release dates, and inferring vulnerabilities based on file changes that occur after a change that updates a version indicator.

6. 2. The method of claim 1, further comprising: selecting at least one software package repository from among the plurality of software package repositories based on a relative usage of software packages stored in each of the plurality of software package repositories compared to software packages stored in each other software repository of the plurality of software package repositories, wherein the plurality of software packages are stored in the selected at least one software package repository.

7. Selecting the at least one software package repository from among the plurality of software package repositories comprises:

7. The method of claim 6, further comprising: analyzing user data to determine a frequency of use of software packages for each of the plurality of software package repositories, wherein each of the at least one software package repository has a highest frequency of use of software packages among the plurality of software package repositories.

8. Selecting the at least one software package repository from among the plurality of software package repositories comprises: recursively crawling the plurality of software package repositories for package dependency manifests; 7. The method of claim 6, further comprising: for each of the plurality of software package repositories, determining a relative usage of the software package repository based on a number of software packages that depend on each software package stored in the software package repository.

9. the at least one identified vulnerability is associated with at least one vulnerable software package from among the plurality of software packages; 2. The method of claim 1, further comprising: generating a dependency graph based on the identified at least one vulnerability, the dependency graph indicating a plurality of dependencies between software packages, the plurality of dependencies including at least one dependency on the at least one vulnerable software package.

10. A non-transitory computer-readable medium having stored thereon instructions for causing a processing circuit to perform a process, the process identifying a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, wherein the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package; identifying at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, wherein the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

11. 1. A system for discovering vulnerabilities in software packages, comprising: A processing circuit; a memory, which when executed by the processing circuitry provides the system with: identifying a potential source of at least one vulnerability in at least one potentially vulnerable software package of a plurality of software packages, wherein the potential source of each vulnerability is a change to one of the at least one potentially vulnerable software package; Identifying at least one vulnerability in the plurality of software packages by selecting and applying at least one vulnerability identification rule to data of each of the at least one potentially vulnerable software package, wherein the at least one vulnerability identification rule for each of the at least one potentially vulnerable software package is selected based on availability of a version identifier for the potentially vulnerable software package.

12. 12. The system of claim 11, wherein the selected at least one vulnerability identification rule for a software package is a first rule when a package version is available for the software package, and the first rule defines a vulnerability as the software package having a package version that is an earlier version than a version indicated in a latest change instruction for the software package.

13. 13. The system of claim 12, wherein the selected at least one vulnerability identification rule for a software package is a second rule when a release version is available for the software package but a package version is not available for the software package, the second rule defining a vulnerability as the software package having a release version that is not within a threshold period of a most recent change order for the software package.

14. 14. The system of claim 13, wherein the selected at least one vulnerability identification rule for a software package is a third rule when neither a package version nor a release version is available for the software package, the third rule defining a vulnerability as the software package having a creation time that is not within a threshold period of the most recent change ordered by a package manager for the software package.

15. 12. The system of claim 11, wherein the system is further configured to at least one of: analyze change order messages, trace at least one predefined message, analyze code comments for security related keywords, analyze release notes for release dates, and infer vulnerabilities based on file changes that occur after a change that updates a version indicator.

16. The system comprises:

12. The system of claim 11, further configured to select at least one software package repository from among the plurality of software package repositories based on a relative usage of software packages stored in each of the plurality of software package repositories compared to software packages stored in each other of the plurality of software package repositories, the plurality of software packages being stored in the selected at least one software package repository.

17. The system comprises:

20. The system of claim 16, further configured to analyze user data to determine a frequency of use of software packages for each of the plurality of software package repositories, each of the at least one software package repository having a highest frequency of use of software packages among the plurality of software package repositories.

18. The system comprises: recursively crawling the plurality of software package repositories for package dependency manifests; 17. The system of claim 16, further configured to: for each of the plurality of software package repositories, determine a relative usage of the software package repository based on a number of software packages that depend on each software package stored in the software package repository.

19. The at least one identified vulnerability is associated with at least one vulnerable software package from among the plurality of software packages, and the system further comprises:

12. The system of claim 11, further configured to generate a dependency graph based on the identified at least one vulnerability, the dependency graph indicating a plurality of dependencies between software packages, the plurality of dependencies including at least one dependency on the at least one vulnerable software package.

Images