You know that analyzing your code for known open source is important. But now what? What’s the best way to integrate open source code analysis into your software development lifecycle? The answer, of course, is: it depends! There are a number of choices to consider, but no one right answer.
When you’re doing multi-source development, code comes from many places, appears at different stages in your development process, and can be stored in different environments. Here’s a sample:
- Code your developers write, which is typically stored in your SCM system
- Binary code provided by other teams in your company may be stored in your SCM system or in a common binary repository
- Source and/or binary code provided by your supply chain may be stored in your SCM system or in an on-site binary repository
- Open source code you choose to include in your solution (binaries and/or source) may be downloaded and stored in your SCM system or in an on-site binary repository
- Open source code that your chosen open source code depends on may be stored in an external location such as Maven Central and only accessed at build time
For this reason, code management can and should be done at different stages of your development process. Let’s look at the opportunity for adding open source code management to your process for each flavor of code.
Code your Developers Write
Today’s developers are used to finding code on the Internet to help them complete their work. Active code management includes analyzing code written by your developers so that you know your code and can manage any license obligations. When analyzing code written by your team, you may choose to integrate the analysis process with your SCM environment. Analyzing your team’s code at frequent intervals helps you identify open source software (OSS) as soon as it’s introduced, which minimizes the time and effort of any required remediation, and ensures you know what obligations you’ll need to meet at release time. The best frequency for your team will depend on the rate of change and the frequency of releases.
Internal, Shared Binary Code
When incorporating code from another part of your company into your solution, you may access that code from an internal binary repository or your SCM system. Analyze the code as soon as you know you’re going to use it and re-analyze as new versions are made available. Even better, add a step to your process so that a bill of materials (BOM) or the Software Package Data Exchange (SPDX) file for binaries must be provided and added to the repository at the time the binary code is added. In short, integrate analysis into your binary management process.
Supply Chain Source or Binary Code
When working with code from your supply chain, you can follow a similar process to the one used for internal, shared code. Even if your supply chain partner has provided a bill of materials, you should verify their data. Most likely, you already ask your suppliers to provide a BOM or an SPDX file for the code they provide to you. Analyze the code to validate the BOM or SPDX file before final acceptance and integrate analysis into your supply chain management process.
Open Source Packages that you Store Locally
Many organizations download and locally store the source code for an open source package they plan to use. You may do this so that you can recompile the binaries for your particular use, or you may simply wish to ensure you have access to the exact sources for maintenance purposes. The source packages of many open source packages can include code that is licensed differently than declared license for the package. Think of the contrib and tools directories. You may have decided that you’re not going to use any of the contents of the contrib directory. However, the code is in your SCM system. How can you be certain that you didn’t accidentally include it in your build? Integrate open source analysis into your build process to ensure you’re evaluating ALL build inputs.
If you are only using the binaries for the open source package exactly as downloaded, you may still choose to analyze and verify the contents. Many open source projects make use of other open source code, so analysis helps ensure that you have a complete BOM and therefore, a complete understanding of your obligations. In this case, again, integrate analysis into your binary management process.
Open Source Packages from Public Repositories
The last scenario involves open source code that depends on (but does not directly bundle) other open source code. Analyzing the open source code prior to use can provide information about dependencies. However, until you actually build the code, you don’t know what other code might be called by the known dependencies. In some cases, you may not even store the open source code you use, but only access it at build time from a public repository. For both these cases, it makes sense to analyze as part of your build process, to ensure you’re evaluating ALL build inputs.
In short, there are a variety of opportunities to integrate open source analysis into your software development process: you can integrate with your source code management, binary management and build management solutions. You can use one or all of these strategies. Which strategy works best for you depends on your use of open source software, your supply chain, and your individual software development lifecycle.
