Abstract: Software is commonly built from a package of software packages, such as open-source packages. A package may require a number of interdependent packages, any one of which may have a security vulnerability. However, the dependencies between packages are often version specific and merely upgrading a package to the newest, or newest non-vulnerable, version may break a dependency and cause the software to be unbuildable (e.g., fail to compile or link) or, if built, faulty. By mapping dependencies to non-vulnerable versions a graphical representation may be built having one or more root-to-leaf paths identifying all the required packages by compatible version but exclude any vulnerable versions. The package may then be built to ensure the resulting software is both internally compatible between packages and absent known security vulnerabilities.

Abstract: Embodiments of the disclosure provide systems and methods for accurately identifying functions in software code that represent vulnerabilities. Identifying vulnerable functions in software code can comprise collecting information identifying one or more known Common Vulnerabilities and Exposures (CVEs) and identifying one or more vulnerable functions in the software code based on relationships between the collected information identifying the one or more known CVEs and the one or more vulnerable functions in the software code. A call graph can be derived for the software code based on the identified one or more vulnerable functions. Each of the identified one or more vulnerable functions can be indicated in the call graph by a vulnerability symbol. A determination can be made as to whether each identified one or more vulnerable functions is a true vulnerability, i.e., when the vulnerable function is encountered when traversing the call graph.

Abstract: Software is commonly built from a package of software packages, such as open-source packages. A package may require a number of interdependent packages, any one of which may have a security vulnerability. However, the dependencies between packages are often version specific and merely upgrading a package to the newest, or newest non-vulnerable, version may break a dependency and cause the software to be unbuildable (e.g., fail to compile or link) or, if built, faulty. By mapping dependencies to non-vulnerable versions a graphical representation may be built having one or more root-to-leaf paths identifying all the required packages by compatible version but exclude any vulnerable versions. The package may then be built to ensure the resulting software is both internally compatible between packages and absent known security vulnerabilities.