Source Code Scanning for OSS Dependencies and Why

Open source application audits using source code scanning tools are a critical part of a corporate open source software policy management and governance process; there literally is no way around it these days.  Without the use of a scanning tool, organizations may rely on homegrown tools, manual inspection and inventory of source code repositories, and developer interviews to implement the governance process.  In our experience, even with full disclosure of open source usage from very honest and open development teams, things slip through the cracks.  And, lets face it, manual inspection of source code is painfully slow.  Homegrown tools might be a realistic approach for larger companies, but they require the allocation of internal resources, not only to use the tools but also to also maintain and update them regularly.

Most open source auditing engagements are completed in the context of scanning a code base of a product line to confirm that a company has appropriately separated their intellectual property from the third party components.  When third party components are used and distributed all licenses for these components need to be identified and there needs to be confirmation that appropriate license compliance steps have been taken.  OpenLogic’s Application Audit and Certification of Compliance services are one solution to consider when outsourcing to a team of experts as these are a full report of all materials, licenses, and a re-verification of compliance steps being completed.

Dependency Scanning Use Case

Depending on the industry and level of maturity of the open source policy management process, a more granular level of scanning may be needed.   Open source packages often bundle other open source software within the larger or parent project.  Some companies want to know not just which open source projects are included in their code, but also identify and then associate the sub-components or dependencies to a parent project.  Open source communities come in all shapes and sizes with varying degrees of attention to the issue of documenting dependencies.  In fact not all open source communities that build and maintain projects accurately disclose and update the dependent libraries that the project uses.  There may have been significant changes from version to version resulting in an old and previously accurate list of dependencies being partially incorrect in the newest versions. Consequently, what was once a pre-approved version of an open source project to use in a distributed code base, could easily be a policy violation and potential license violation in that next version.

If you are familiar with OSS development and license types a single file can make a very big difference.  For example, in one of our scans the OpenLogic audit and IP analysis team actually found a license conflict between source code components in an open source project.  We contacted the community to inform them of the conflict as they were not even aware this conflict existed.  The community acknowledged someone had in fact contributed code that created this conflict and the community did the right thing for their end users by removing the conflicting code and replacing it.

If you scan and analyze the open source software project code directly, you can then determine all the dependencies that are used by the specific version.  For example, if an organization's states that the most recent version of Zlib must be used, then this organization would complete a scan to find out if anything has changed from version to version.  As a result, the organization can then confidently make the statement to customers, investors, acquiring companies, etc. “Yes we ship the Zlib library with our product, we always ship the most recent version of Zlib, and we can tell you exactly what Zlib is using in the newest version.  Would you like to see it?”  Then obviously the company would introduce the most recent Zlib Bill of Materials and Licenses to the audience.

The OSS Deep Discovery scanning tool has a customizable setting for this exact situation thus reducing the number of false positives found in the initial results.  In other words, by adjusting the settings accordingly, the scanner will identify all the components inside of Zlib instead of simply reporting that you have matches to Zlib.

The real world example for this level of diligence goes back to having and managing an actionable open source policy.  Open source review boards that have monthly, bi -monthly, weekly, or even impromptu daily meetings about what can and cannot be used and under what conditions need the ability to quickly identify and document these occurrences, make decisions, implement critical policy rule changes and communicate all of this easily to the organization.  One new or changed file can make a big difference in protecting millions of dollars of development and intellectual property.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @JesseH303
View Jesse Hood's profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.