Scanning and auditing your code for open source software (OSS) is a great first step towards compliance. However, some organizations may be reluctant to perform scans because of concerns about how disruptive the process can be to their development effort. In this article, I will explore a couple different approaches to scanning your code for OSS and the potential disruption associated with each. I have organized the article from the least to most disruptive approach.
Approach #1: Outsource
Providing your code to a third party, such as OpenLogic, to perform an audit can be the least invasive approach. In this approach, someone from your development organization will need to prepare the code for scanning. The amount of preparation really depends on your application. For example, providing only compiled code can dramatically affect the accuracy of scan results; you will want to supply as much source code as possible. Depending on how your code is managed, this could be a potentially lengthy task. How code is organized and managed, and if different code components are managed separately can impact how long it will take to pull all the required code together for an audit. In any case, preparing the code to be delivered shouldn't take more than a few hours, or a few days worst-case scenario.
If the audit is conducted onsite, you may alleviate concerns about security around letting your intellectual property outside your organization. However, if you need to work with your IT organization to secure an additional workstation where the audit will be performed the impact could be greater than simply preparing the code and passing it to the third-party auditor.
How much preparation you do (either voluntarily or as a requirement of the audit) can be disruptive to your engineering efforts. For example, having or preparing a bill of materials (BOM) and licenses for the open source you know is used in the development of your product can speed the auditing process. But, if you don't already have the list, taking the time to collect the information and organize it can take valuable development time.
During the audit itself, you can expect that the auditor will want to have access to your development team for questions that crop up during the scan analysis phase. For example, auditors may want to know if the development team knows the origin of some OSS libraries. Were they obtained as a bundled component of a larger project, or were they obtained from the original author? Usually, this is not very disruptive and can be managed well by setting up scheduled meetings to address questions.
The next impact you can expect is the review of the results and any follow up actions required. The actual review of the results will most likely be minimal. However, if you are using literally hundreds of OSS packages and the audit report includes a large BOM, you may want to involve a few key stakeholders to review the results. You will need to meet with the auditor to review the report and make sure you understand the results, and how those results might impact your organization.
Approach #2: In-house
The most disruptive approach, however, will be for organizations that choose to perform the audit in-house and use non-dedicated engineering resources to do the scanning and analysis.
In addition to the steps outlined above (preparing the code and workstation for the audit), you will need to schedule an engineer's time to run the scan and perform the analysis of the results. This is time taken away from the engineer's normal tasks such as coding, design, planning, etc.
The amount of time required to analyze the scan results will vary greatly depending on a number of factors: amount of OSS used, whether the OSS is modified, size of your project, age of project, languages used, etc. Obviously, if you use a lot of OSS in your development, the analysis will take longer to identify every OSS project. Older projects can take longer as well, because many of the OSS projects used may no longer exist; this in turn will require more time to research and identify information about the project. Modified source code means that you will see more "snippet" match results from the scanner, each of which you will need to review to ensure you accurately report OSS used.
If your organization has dedicated resources to perform the scanning and auditing, the impact will be very similar to the outsource option. However, you will realize the added benefit of developing internal expertise around the OSS audit process allowing faster and more accurate results over time.
Independent of the approach you use, another key factor on impact is the timing you choose to perform the scan in the development process. The earlier you scan in the process, the less overall cost and impact you can expect. Scanning early and often allows you to track real-time changes to OSS use and take immediate compliance or remediation action if required. Many scanners, like the OLEX scanner, provide a delta scanning capability that allows you to check periodically for changes to your code that include the addition or change to OSS.
What types of disruption concern you? I'd love to get your feedback. If you have additional thoughts or comments please post them below.