Patent Description:
Some open source software packages can be consumed and executed independently. Other open source software packages are building blocks which are combined with other software to create a product. A developer can use one, dozens, or hundreds of open source software packages in their own codebase and ship the codebase to others. Thus, open source software is advantageous because it enables a developer to properly use the work of others to advance their own work.

A package manager is an entity to which various publishers of open source can place the open source software packages they are willing to share. Others can then access those open source software packages from the package manager. The package managers are typically specific to a particular language (e.g. c# package manager, java script package manager, etc.). Thus, entities working on a codebase in a particular language can go to a specific package manager to search for open source packages of interest.

<CIT> describes a computer system which includes a transceiver and a processor that is cooperatively operable with the transceiver. The processor gathers, over the transceiver, (i) issue tracking information stored in an issue tracking storage system, the issue tracking information having a history of issues filed against a plurality of artifacts, and (ii) source code management information stored in a source code management storage system, the source code management information having a history of code changes committed against another plurality of artifacts. The processor checks a combined history of the issue tracking information and the source code management information for a history of issues filed against an artifact and a history of commits and corresponding source code changes committed against the artifact. The processor provides an interpretation of the current state of the artifact based on the combined history of the issue tracking information and source code management information about the artifact.

<CIT> describes a certificate-based methodology which is used to establish the trustworthy relationship between source codes and produced binary files for a given software build. The trustworthy relationship between the source code and binary files is generated by recording build information during building of the source code. The build information may include build environment information, framework information, source files identification, intermediately generated files information, final binary files information, file operations during building of the source code, and/or commands / operations during building of the source code. A certificate is generated using the build information for establishing a relationship between the source code and a binary file created from the source code, and the certificate is signed with a public cryptographic key. A software release package is provided to the recipient including at least the source code, final binary files generated from the source code, and the certificate.

<CIT> describes a method and system for identifying an open-source software package from a binary file for which an open-source license is to be checked. The method includes: accessing a database generated to include a plurality of open-source software packages having a plurality of open-source files and open-source software package version information, based on a plurality of first identifiers included in each of the plurality of open-source files; receiving the binary file; extracting at least one second identifier included in the binary file by performing a string search on the binary file; and extracting at least one first identifier that matches the at least one second identifier from the database, and outputting an open-source software package and open-source software package version information corresponding to the at least one first identifier.

This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description.

The principles described herein relate to detecting whether or not an open source software package has functionality which is not described by the source code used to build the open source software package. After an open source software package has been built from source code, additional functionality may be introduced into the package. The additional functionality can be harmful and thus presents a risk for using an open source software package which may or may not have additional functionality. The embodiments described herein allow a developer to reduce the risk of using open source software packages by enabling the developer to detect additional functionality in an open source software package.

In one embodiment, this is done by accessing source code used to build the open source software package. The open source software package is rebuilt from the source code. After the open source software package has been rebuilt, it is then computed whether or not the rebuilt package accomplishes the same functions as the open source software package. Finally, if the rebuilt package does not accomplish the same functions as the open source software package, an alert is raised.

<FIG> illustrates an environment <NUM> in which an open source software package is originally built. Source code <NUM> includes a compilation of commands written in an interpretable language or a compilable language. The source code <NUM> describes functionality <NUM>. In the paradigm of <FIG>, this functionality <NUM> is represented as a circle for reasons that will be later described. The functionality includes capabilities of the source code when converted to machine code and executed by a computing system.

The written source code <NUM> is then used to generate an open source software package <NUM>. As shown by arrow <NUM>, the source code is sent to a build component <NUM>. The build component <NUM> that receives the source code <NUM> then uses the source code <NUM> to produce (as represented arrow <NUM>) the open source software package <NUM>. In order to generate the open source software package <NUM>, the build component <NUM> may perform a variety of processes on the source code <NUM>. For example, the build component <NUM> may compile the source code into an executable. In another example, the build component <NUM> may transform the source code <NUM> itself, such as performing a minimization to eliminate white space and reduce the size of the resulting package <NUM>. If the environment <NUM> is implemented within a computing system, such as the computing system <NUM> described below with respect to <FIG>, the build component <NUM> is structured as described below for the executable component <NUM>.

The open source software package <NUM> also has functionality <NUM>. In the illustrated case, the functionality <NUM> is represented by an oval <NUM>. The functionality <NUM> of the open source software package <NUM> could be identical to the functionality <NUM> of the source code <NUM>. However, there could also be differences. The circle <NUM> and oval <NUM> symbolically represent how the functionality <NUM> of the source code <NUM> and functionality <NUM> of the open source software package <NUM> may be similar, but might not be identical. The open source software package <NUM> may have different functionality because additional functionality was introduced to the open source software package <NUM>. The additional functionality of the open source software package <NUM> is functionality which is not described by the source code <NUM>.

In some instances, the additional functionality is introduced to the package by a compromised build environment of the build component <NUM>. Alternatively, or in addition, the additional functionality may be introduced after the open source software package <NUM> has been generated and published to a package manager. For example, this may occur while the open source software package <NUM> is in storage on either a source repository or a developer's computing system. Finally, the additional functionality might also be introduced to the open source software package <NUM>, while the package is in transit from a first network location to a second network location. For example, additional functionality might be introduced while the open source software package <NUM> is being transmitted from a source repository to a developer's computing system.

The additional functionality is possibly malicious or harmful and therefore, a developer incurs risk for using an open source software package <NUM>. The principles described herein aim to reduce this risk by detecting whether or not an open source software package includes functionality which is not described by the source code. If so, the developer is alerted, allowing for the issue and potential risk to be identified, and therefore potentially managed.

<FIG> illustrates a flowchart of a method <NUM> for detecting whether or not an open source software package has functionality which is not described by source code used to originally build the open source software package. This is accomplished by retracing at least some the acts performed on the source code during the original build and substantively repeating those acts to generate a new rebuilt package. In this sense, this method establishes a supply chain pedigree for the open source software package. Although the method acts may be discussed in a certain order or illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated or required (e.g., because an act is dependent on another act being completed prior to the act being performed).

Referring again to <FIG>, the method <NUM> includes accessing the original source code used to build the open source software package (act <NUM>). After the source code has been accessed, the method includes rebuilding the open source software package from the source code (act <NUM>). Following the rebuild, the method includes computing whether or not the rebuilt package accomplishes the same functions as the open source software package (decision block <NUM>). If the open source software package and the rebuilt package are the same ("Yes" in decision block <NUM>), the method <NUM> includes estimating that the open source software package has the same functionality as the rebuilt package (act <NUM>). The open source software package may be tagged or one of its attributes set, to mark the open source software package as having the same functional as when it was original built. The similar functionality between the open source software package and the rebuilt package indicates that the open source software package is likely safe and does not include any additional functionality that was not represented in the original source code.

If the original and rebuilt open source software packages are not the same ("No" in decision block <NUM>), the method <NUM> includes estimating that the open source software package does not have the same functionality (act <NUM>). The open source software package may be tagged or one of its attributes set, to mark the open source software package as having different functional than when it was original built. The different functionality between the open source software package and the rebuilt package indicates that the open source software package may include additional potentially unsafe functionality that was not within the original source code. Thus, the method includes alerting an appropriate entity that the rebuilt package does not accomplish the same functions as the open source software package (act <NUM>) if indeed that is the case. That appropriate entity could be, by way of example only, a user, a developer, and IT administrator, an artificial intelligence, a risk assessment component, or the like. The remainder of <FIG> will be described after a brief description of <FIG>.

<FIG> illustrates a flowchart of a method <NUM> which may be used to validate a package as having functionality that is fully described by the source code. The method <NUM> of <FIG> may be performed to mark the original open source software package, in which case the method <NUM> would be performed after act <NUM> in <FIG>. Alternatively, the method <NUM> of <FIG> may be performed to mark the rebuilt open source software package as valid, which would be performed after act <NUM> of <FIG>.

The method <NUM> for validating the open source software package includes marking the open source software package as valid (act <NUM>). This marking may include an indicator or stamp which illustrates the validation of the open source software package, or an indicator within the package demonstrating the validity of the open source software package. Following the marking, the open source software package may be added to a list of validated open source packages (act <NUM>). Thus, over time, the developer and/or the organization that is collecting authoring software, may build a library of validated open source packages that are deemed safe, or which have a particular level of assessed risk.

Returning to <FIG>, once the open source software packaged has been deemed likely safe because no additional functionality was detected, the open source software package awaits selection by a developer. A developer may or may not choose to use a safe open source software package in a codebase. Similarly, a rebuilt package may or may not be selected by a developer to be used in a codebase. Nevertheless, the safe open source software package is available for selection. Thus, following acts <NUM> or <NUM>, the open source software package or the rebuilt package may be selected by a developer to be used in a codebase (act <NUM>).

Finally, the method <NUM> includes incorporating the open source software package into a codebase (act <NUM>). This incorporation includes using either the original open source software package or the rebuilt package. Thus, at this point, the code from the open source software package has been successfully and safely used within the codebase of the developer.

<FIG> illustrates an environment <NUM> in which the method of <FIG> may occur. An access component <NUM> first accesses the source code <NUM>. The access component <NUM> is an example of a component that performs the accessing described in act <NUM> of <FIG>. If the environment <NUM> is implemented within a computing system, such as the computing system <NUM> described below with respect to <FIG>, the access component <NUM> is structured as described below for the executable component <NUM>.

The source code <NUM> is an example of the source code <NUM> depicted in <FIG>. In order to access the source code <NUM>, the access component identifies the source code <NUM>. In some embodiments, the source code <NUM> is provided in the open source software package <NUM> and the access component <NUM> identifies and receives the source code <NUM> from the open source software package <NUM>. Alternatively, or in addition, the open source software package <NUM> provides information representing the location where the source code <NUM> exists on a source repository <NUM>. From this, the access component <NUM> identifies the location of the source code <NUM> on a source repository <NUM>, and then addresses and receives the source code <NUM> over a network connection <NUM>.

In one embodiment, the access component <NUM> identifies the location of the source code <NUM> from debugging information within a compiled executable in the open source software package <NUM>. The debugging information could include symbols which map every line of code to a source repository <NUM> where the original source code <NUM> is stored. The access component will use the location obtained from the debugging information to identify the source code <NUM> on the source repository <NUM> and then address and receive the source code <NUM> over the network connection <NUM>.

In some instances, the source code <NUM> is not in the open source software package <NUM>, nor does the open source software package provide a location for the source code <NUM>. In these instances, the provenance information of the open source software package <NUM> is established in order to identify the location of the original source code <NUM>. Provenance information may include the version of the source code used to build the open source software package, the location of the source code, and/or the publisher who generated the open source software package. A developer or a package manager may provide provenance information for some open source software packages. However, that provenance information may be incomplete. For example, a package manager may provide publisher information and a source repository location but omit the version of source code used to generate the open source software package.

Establishing provenance is also advantageous because it gives the developer access to the original licenses for the source code. In some instances, there may be inconsistencies between the license file of the source code and the license file of the open source software package. Provenance gives a developer the ability to review the original licenses in order to identify the license terms of the open source software package and enables improved compliance with the license terms. Finally, establishing provenance is advantageous because it allows a developer to discover a publisher and/or verify the credibility of that publisher.

Provenance may be established in order to identify the source code and the publisher of an open source software package. In one embodiment, the access component <NUM> is structured to establish provenance to thereby identify and access the source code <NUM> with a predetermined process (described below) to identify the correct source repository <NUM> where the source code <NUM> is located. The predetermined process includes one or more acts that the access component <NUM> uses to search for a source repository <NUM> where the source code <NUM> is located. These acts will now be described. Though the acts themselves will be described below in a particular order within this document, no particular order is required when executing these acts within the predetermined process. Furthermore, the predetermined process may include any combination of the described acts. If the access component <NUM> finds the source code <NUM> before the predetermined process is complete, the access component <NUM> ends the predetermined process now that goal is accomplished.

As part of the predetermined process to find the source code associated with a particular open source software package <NUM>, the access component <NUM> may search one or more package managers for a source repository that has a same or similar name to that of the particular open source software package <NUM>. Once a source repository <NUM> is found, the access code can address and receive the source code <NUM> over a network connection. In some instances, after source repository is found <NUM>, the access component <NUM> will identify the specific version of source code <NUM> used to originally build the open source software package <NUM>. Identifying the specific version of source code <NUM> will be described in more detail below.

Also as part of the predetermined process, the access component <NUM> may search online forums for one or more discussions of an open source software package <NUM> with a same or similar name as the particular open source software package <NUM>. If the access component <NUM> successfully identifies relevant forum discussions, the access component <NUM> may search the relevant discussions for provenance information of the open source software package <NUM>. Using the identified provenance information, the access component <NUM> will address the source repository and receive the source code over a network connection.

Also as part of the predetermined process, the access component <NUM> may also be configured to identify a specific version of the source code used to build the open source software package <NUM>. Source repositories with version control management may store multiple versions of source code used to build multiple versions of an open source software package. Each version of source code is saved as a commit within the source repository. The access component <NUM> may be configured to identify the specific commit used to build the open source software package. The access component <NUM> may identify the specific commit by matching a version number of the open source software package to a tagged release within the source repository. The access component <NUM> may also parse the release notes within a source repository for indications that a particular release is related to the open source software package <NUM>.

Also as part of the predetermined process, the access component <NUM> may also identify the specific commit by performing a functional matching of source code <NUM> to the open source software package <NUM>. First, the access component <NUM> will identify a range of commits likely to contain the specific commit. For example, the access component <NUM> may identify a range of commits which are time stamped near the publishing date of the open source software package <NUM>. After identifying a range of commits, the access component <NUM> will rebuild the open source software package from each of the versions of source code corresponding to the range of commits resulting in multiple rebuilt packages. The environment <NUM> will then functionally match each of the rebuilt packages to the original open source software package <NUM> and the rebuilt package <NUM>, and find the rebuilt open source software package that most closely matches the open source software package <NUM>. Then, the source code commit used to build the most closely matching rebuilt package is found to be the source code.

In some instances, the rebuilt package <NUM> must be a bit-for-bit match to successfully confirm the provenance of the original open source software package <NUM>. In this bit-for-bit case, this process simultaneously confirms that the open source software package <NUM> does not have any additional functionality.

If a source repository <NUM> or a specific commit for an open source software package <NUM> cannot be found, an attestation is made that the provenance of the open source software package <NUM> cannot be established and that additional functionality cannot be detected. Thus, the attestation is an indicator that the open source software package <NUM> is a high risk if incorporated into a codebase.

After the access component <NUM> has identified and/or accessed the source code <NUM>, the source code is passed to a rebuild component <NUM>. The rebuild component <NUM> is an example of a component that performs the rebuilding described in act <NUM> of <FIG>. If the environment <NUM> is implemented within the computing system <NUM> described below with respect to <FIG>, the rebuild component <NUM> is structured as described below for the executable component <NUM>.

The rebuild component <NUM> may include a hardened build environment which does not allow external code to interact with the rebuilding. This is advantageous because it ensures that no additional functionality can be introduced during the rebuild of the open source software package <NUM>. Additionally, the build environment itself may utilize the embodiments of the present application prior to each build to verify that the build environment and/or tools used by the build component <NUM> are safe to use because they have no additional functionality. Thus, the tools used to rebuild can also be generated from open source software packages, and thus those packages also may be rebuilt to verify no additional functionality has been added.

This is advantageous because it prevents compromised build environments or tools from introducing additional functionality into the rebuilt package <NUM> during the rebuild process. In some embodiments, the build component <NUM> will discard the build environment after the rebuild of the open source software package <NUM> for added security. In that case. any potentially compromised build environment is eliminated after every build.

In one embodiment, the build component <NUM> may be configured to rewrite the source code as interpretable code. This configuration is helpful to rebuild open source software packages which contain interpretable source code or the like. In some instances, the build component will conduct a naive rebuild of the open source software package. To rebuild the open source software package <NUM>, the build component <NUM> will access a directory of the open source software package <NUM> to identify runtime parameters used to originally build the open source software package <NUM> from the source code <NUM>. For example, the runtime parameters may include runtimes, versions, and dependencies needed for building the code.

The build component <NUM> will create a new build environment with the identified parameters. In some embodiments, the new build environment is a hardened build environment, a private build environment, or both such that the build environment is inaccessible to external entities. For example, the new build environment will not be accessible through the internet or by other developers. Therefore, compromise of the new build environment is unlikely.

The build component <NUM> will copy the source code <NUM> to the new build environment. In some instances, the build component will utilize a hash to maintain and verify accurate copying of the copied source code. Finally, the build component <NUM> will execute the rebuild using the new build environment. In some instances, the rebuild will be conducted within a branch of the new build environment to preserve the purity of the source code <NUM>.

In one embodiment, the rebuild component <NUM> may be configured to compile the source code to generate machine code. This configuration is helpful to rebuild an open source software package <NUM> that contains assembled code, machine code, an executable, a DLL, bytecode, or the like. In order to rebuild packages that require compilation or assembly, binaries in the open source software package should be deterministic. One of ordinary skill in the art will appreciate that deterministic binaries include reproduceable bits because the original build of the binary avoided any non-deterministic decision making. Essentially, the original build avoided any processes which were not reproduceable, such as using unrepeatable random number generators, time stamp information, and compilers with non-deterministic internal algorithms. Therefore, the rebuild component <NUM> must first determine that the open source software package <NUM> is deterministic.

After the rebuild component <NUM> has determined that the open source software package is deterministic, the rebuild component <NUM> may utilize the method illustrated in <FIG> to rebuild the open source software package <NUM> and generate a rebuilt package <NUM>. The method will now be described with respect to <FIG>. First, the rebuild component <NUM> will extract embedded metadata from the open source software package (act <NUM>). The embedded meta data includes the version of compiler used to build the open source software package, the versions of any tools used to build the open source software package, string definitions, language translations, and similar resources. The embedded metadata may be copied to a local directory for use during the rebuild.

The rebuild component <NUM> will also extract compiler information from the open source software package (act <NUM>). The compiler information includes the information needed to re-create the deterministic build of the original open source software package from the source code. For example, the compiler information may include compilation flags, environment information, optimizations passed into the open source software package, or similar information. The compiler information may be copied to a local directory for use during the rebuild.

Acts <NUM> and <NUM> may be performed in any particular order, or in parallel. Following acts <NUM> and <NUM>, the rebuild component <NUM> will rebuild the open source software package <NUM> from the source code <NUM> (act <NUM>). The rebuild component <NUM> then produces a rebuilt package <NUM>. The rebuilt package <NUM> includes functionality <NUM> which is fully described by the source code <NUM>. In the illustrated case, note that the functionality <NUM> of the rebuilt package <NUM> and the functionality <NUM> of the source code <NUM> are both represented with a circle representing a corresponding functionality. The functionality <NUM> of the rebuilt package <NUM> may or may not be the same as the functionality <NUM> of the open source software package <NUM>. As illustrated in <FIG>, the functionality <NUM> of the open source software package <NUM> is represented with an oval to indicate similar but potentially different functionality from the functionality <NUM> of the rebuilt package <NUM>.

Returning to <FIG>, the rebuilt package <NUM> and the open source software package <NUM> are passed to the compare component <NUM> which computes whether or not the open source software package <NUM> has additional functionality. The compare component <NUM> is an example of a component that performs the comparison described in decision block <NUM> of <FIG>. If the environment <NUM> is implemented within the computing system <NUM> described below with respect to <FIG>, the compare component <NUM> is structured as described below for the executable component <NUM>.

In one embodiment, the compare component <NUM> performs a bit-for-bit comparison of the rebuilt package <NUM> and the open source software package <NUM>. In another embodiment, the signing information is stripped from the open source software package <NUM> prior to the comparison because the signing information cannot be replicated by the rebuild component. Thus, for example, the compare component <NUM> will compare the rebuilt package <NUM> to an un-signed version of the open source software package <NUM>.

Where the rebuilt package <NUM> and the open source software package <NUM> are a match, the compare component <NUM> will estimate that the open source software package <NUM> has the same functionality <NUM> as the functionality <NUM> of the rebuilt package <NUM>. This is an example of the estimating described in act <NUM> of <FIG> following a "Yes" in the decision block <NUM>. The compare component <NUM> validates the original open source software package as being entirely described by the source code used to build the package and that the open source software package contains no additional functionality. Thereby validating that the original open source software package is safe to use. This is an example of the method illustrated by <FIG>. Similarly, because the open source software package and the rebuilt package are a match, the rebuilt package is also safe to use.

Alternatively, where the rebuilt package <NUM> and the open source software package <NUM> are not a match, the compare component <NUM> may attempt another form a functional matching described further below. The compare component may also estimate that the open source software package <NUM> has a different functionality <NUM> than the functionality <NUM> of the rebuilt package <NUM>. The compare component <NUM> may provide an attestation that the open source software package <NUM> is not entirely described by the source code <NUM> used to build that package <NUM> and that the open source software package <NUM> may contain additional functionality. Thereby attesting that the original open source software package 411is not safe to use. This is an example of the estimating described in act <NUM> of <FIG> following a "No" in the decision block <NUM>.

In another embodiment, functional matching can be inferred from a comparison of the file structure of the rebuilt package <NUM> and the file structure of the open source software package <NUM>. The compare component <NUM> may utilize the method illustrated in <FIG> to make an inference of functional matching. First, the compare component <NUM> will compare a file structure of the open source software package to a file structure of the rebuilt package (act <NUM>). The file structure includes one or more of the names of files, the locations of files, the sizes of files within the package, and other similar structures. For example, the comparison may entail comparing the location of files in the open source software package <NUM> to the location of files in the rebuilt package <NUM>. Similarly, the comparison may entail comparing the sizes of files in the open source software package <NUM> to the sizes of files in the rebuilt package <NUM>.

The compare component <NUM> will use the comparison to identify whether the file structure of the open source package <NUM> and the file structure of the rebuilt package <NUM> are the same or whether the file structure of the open source package <NUM> and the file structure of the rebuilt package <NUM> has one or more differences (act <NUM>). Finally, the compare component <NUM> will use the identified differences to estimate whether the rebuilt package <NUM> accomplishes the same function as the open source software package <NUM> or that the one or more differences are collectively consistent with the rebuilt package <NUM>, and the open source software package <NUM> has different functionality (act <NUM>). Some differences in file structure are not indicative of additional functionality in the open source software package <NUM>. Therefore, the comparison component is configured to identify the differences in files structure and estimate which of the differences indicate different functionality between the rebuilt package <NUM> and the open source software package <NUM>. Where there are such differences, it may estimate that the open source software package <NUM> has additional functionality.

Returning to <FIG>, if the compare component <NUM> is configured to alert when additional functionality is detected in the open source software package <NUM>. The alert is an example of the act <NUM> described in <FIG>. The alert may include an audible or visual indicator displayed for a user on a user interface or output device that identifies an open source software package <NUM> as unsafe. The alert may also include an attestation on the open source software package <NUM> in the form of a stamp, flag, image, or other attestation. In another instance, the open source software package may be added to list of unsafe open source software packages. If the environment <NUM> is implemented within the computing system <NUM> described below with respect to <FIG>, the alert may be performed by an input output mechanism <NUM>.

Returning now to <FIG>, following estimation of additional functionality, the original and/or rebuilt open source software packages await selection by a developer. A developer may or may not choose to use the original or rebuilt open source software packages in a code base. In some instance the original and rebuilt open source software package will await selection in storage <NUM>.

If no additional functionality was detected in the open source software package <NUM>, the open source software package <NUM> is safe to be used by a developer in a codebase. Alternatively, the developer may use the rebuilt package <NUM> in a codebase. For example, where the open source software package <NUM> had additional functionality and was estimated to be unsafe, the rebuilt package <NUM> can be incorporated into a codebase. Furthermore, even where no additional functionality was detected in the open source software package <NUM>, a developer may choose to use the rebuilt package <NUM>. For example, where functional matching was inferred, the rebuilt package <NUM> may be safer to use because it was generated in a hardened build environment. In other words, because the build environment of the rebuilt package <NUM> was known and uncompromised, a developer may choose to use a rebuilt package <NUM> for added security.

The rebuilt package <NUM> may be stored in storage <NUM> for future validation of the open source software package. In some instances, additional functionality may be introduced to an open source software package <NUM> or a rebuilt package <NUM> after the detection has already occurred and validation has been asserted. Thus, a copy of the rebuilt package <NUM> is retained to re-detect and re-validate the open source software package <NUM> or rebuilt package <NUM> when necessary. Functional matching and detection of additional functionality may be performed at any time during the use of an open source software package <NUM>. For example, the detection of additional functionality may be performed before the open source software package is incorporated in a code base, before shipment of a product to a client, or before execution at runtime. Further, the functional matching may include bit-for-bit matching or an inference of functional matching as described with reference to <FIG>.

The embodiments described herein could be used in an enterprise development system to provide an assessment of risk for the use of open source software packages within products. Developers often create products with dozens or hundreds of software packages which may include one or more open source software packages. Further, some open source software packages have dependencies to additional open source software packages. These dependencies increase the risk of using open source software packages as the dependencies are additional avenues of malicious code into a product. In addition, tracking the use of open source software packages and their dependencies can be difficult because enterprise development often spans across multiple teams and vendors which increases the difficulty of managing open source software package inventory and risk assessment.

At least one embodiment is used to simplify risk assessment and potentially manage risk of using open source software packages in development. This is done by tracking every build that occurs within an enterprise, mapping the dependencies of each open source software package used in that build, assigning the risk for each open source software package and its dependencies, providing an overall assessment of the risk for the product, and finally, reducing the risk by managing those risks.

One embodiment seeks to simplify a risk assessment open source software package inventory by including the risk assessment in the product build. For example, the risk assessment could be conducted as a new step during compilation. Once a product is ready for build, a risk assessment will be performed as follows. First, it will be determined which packages used in the product are unlikely to include harmful or malicious code and these packages will be excluded from the analysis (e.g., internal packages).

The remaining packages (e.g. the open source software packages) are identified and the dependencies of each open source software package are found. Dependencies can be identified by extracting dependency information. For example, some open source software packages declare dependencies to other packages in the package themselves and some open source software packages declare a dependency in a binary within the package. Dependencies include other open source software packages.

The risk is assessed for each open source software package and its dependencies. The risk is evaluated using one or more of the following factors. An open source software package with an unknown or untrusted author is an increased risk. An open source software package from a potentially unsafe source repository is an increased risk. For example, potentially unsafe source repository may include a source repository with one or few contributors or where code checks are infrequently performed. An open source software package which does not have source code available is an increased risk. An open source software package which is not rebuildable is an increased risk. Open source software packages which have been validated using the embodiments described herein with reference to <FIG> and <FIG> are a reduced risk. Rebuilt packages which have been built from an open source software package using the embodiments described herein are a reduced risk.

After the risk of each open source software package, and overall risk assessment is made. The overall risk assessment is based on the risk assessment of each individual open source software package in addition to other factors. For example, the overall assessment may also factor an increased risk of using more open source software package or using open source software packages with more dependencies.

Following a risk assessment, an attempt is made to reduce the risk by detecting additional functionality in risky open source software packages using the embodiments described herein and validating the package as safe or attesting that the package is unsafe. By validating risky open source software packages as safe, the overall risk associated with the final product is reduced. In addition, the discovery of unsafe packages gives the developers the opportunity to potentially manage the issue before a product is shipped. Furthermore, risky packages may be replaced with rebuilt packages that have been built in a hardened environment using the embodiments disclosed herein. By replacing risky open source software packages with safer alternatives, the overall risk associated with the final product is reduced.

Finally, because the principles described herein may be performed in the context of a computing system some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> typically includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> may include a general-purpose processor and may also include a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other specialized circuit. The memory <NUM> may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.

In such a case, one of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such a structure may be computer-readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

The term "executable component" is also well understood by one of ordinary skill as including structures, such as hardcoded or hard-wired logic gates, that are implemented exclusively or near-exclusively in hardware, such as within a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other specialized circuit.

For example, such computer-executable instructions may be embodied in one or more computer-readable media that form a computer program product. If such acts are implemented exclusively or near-exclusively in hardware, such as within an FPGA or an ASIC, the computer-executable instructions may be hardcoded or hard-wired logic gates.

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 712A as well as input mechanisms 712B. The principles described herein are not limited to the precise output mechanisms 712A or input mechanisms 712B as such will depend on the nature of the device. However, output mechanisms 712A might include, for instance, speakers, displays, tactile output, holograms and so forth. Examples of input mechanisms 712B might include, for instance, microphones, touchscreens, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Embodiments described herein may comprise or utilize a special purpose or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general-purpose or special purpose computing system.

Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other physical and tangible storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general-purpose or special purpose computing system.

Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general-purpose or special-purpose computing system.

Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, data centers, wearables (such as glasses) and the like.

The disclosed embodiments provide an avenue for developers to benefit from using open source software packages while also reducing the risk that is typically associated with open source software. One benefit of the disclosed embodiments is to detect additional functionality which is not described by the source code used to build the open source software package. Another benefit is to provide a developer with a safer rebuilt open source software package which can be used instead of a risky open source software package. The disclosed embodiments are also advantageous to reduce systematic risks of enterprise development that may rely on dozens or hundreds of open source software packages.

Claim 1:
A computing system (<NUM>, <NUM>) for detecting (<NUM>) whether or not an open source software package (<NUM>) has functionality (<NUM>) which is not described by source code (<NUM>) used to build the open source software package, the computing system comprising:
one or more processors (<NUM>); and
one or more computer-readable media (<NUM>) having thereon computer-executable instructions that are structured such that, if executed by the one or more processors, the computing system is configured to:
access (<NUM>) the source code (<NUM>) used to build the open source software package (<NUM>);
rebuild (<NUM>) the open source software package from the source code wherein the rebuild of the open source software package from the source code is further configured to rewrite the source code as interpretable code;
access a directory of the open source software package to identify runtime parameters used to originally build the open source software package from the source code;
create a new build environment with the identified parameters; and
execute the rebuild using the new build environment;
compute (<NUM>) whether or not the rebuilt package accomplishes the same functions as the open source software package; and
alert if (<NUM>) (<NUM>) the rebuilt package does not accomplish the same functions as the open source software package.