Testing with Eclipse Dash tool to describe use case for ORT
Thoughts about ORT that surface when we understand Dash tool deeper
The Dash tool, when used to analyze the IP situation of an Eclipse project, lists the third party dependency tree till platform level, and list the licenses of them (though not in a detailed way) in a file if a project is analyzed using the maven dependency plugin for Dash license tool.
So, a question came to mind - Why should we use ORT? I figured this answer; but, this may be wrong as well - please correct me if I am wrong - Dash tool list detailed dependency tree without much intervention only in the case of maven based projects. For others like npm, automatic dependency resolution is not easy unless proper input is provided to the tool. As described in https://www.eclipse.org/projects/handbook/#ip-license-tool-cli, project teams that use technologies that do not provide easily parsed/converted dependency lists can manually generate a list and feed that to the Dash tool. For this they use the CLI. So, this involves a manual step from the projects. So, the accuracy of the analysis depends on what is fed to the tool.
So, can we infer that the primary reason for bringing in ORT is to cover all use cases with minimum user inputs?
A test case to start with
We tested a project to come out with a few points on the use case of ORT. The project was the Eclipse Dash license tool. We have done the following three steps: a. Reviewed the DEPENDENCY file for the Dash tool for license information provided. b. Uploaded the source code for Dash tool in to Fossology and checked the license information that Fossology provided. c. Reviewed the results of scan of ORT on the Dash tool.
We could find that the DEPENDENCY file listed license information and approval status from the Eclipse database, and ClearlyDefined. However, the question that remained was whether that amounts to proper SBOM data for all dependencies. We should discuss this point.
Fossology could only be helpful in identifying the available license information from the project files. Fossology is not capable of analyzing information of third party dependencies based on a knowledge base.
ORT could find out the provenance, bring in the source code for many dependencies and give a comprehensive scan report of many third party dependencies. There are a few results that seems to be anomalies. They needs discussion though.
What we perceive as missing in the current setup with Dash tool
There are a few things that seems missing now:
- Automatic triggering of license analysis of all Eclipse projects on a regular frequency.
- The comprehensiveness of the license information from dependencies. e.g. detailed source code analysis of the dependencies are not done now. Rather information is collected from the Dash database and other sources like ClearlyDefined.
- Generation of SBOMS for projects, especially given that the focus of the IP due diligence has changed recently to license compliance.
- A repository that stores information about each Eclipse project and the respective third party components used in Eclipse projects in one database.
- Inclusion of all the above items in the best possible work flow, giving the IP team opportunity to review and audit content at the right time.
- Information on security.
What could ORT bring in
- We may trigger scheduled runs of ORT on every Eclipse repository in regular intervals.
- We could leverage the current integration of ORT with IPLab, to create issues corresponding to each project scan. We may define some criteria for creating new issues in IPLab.
- Much more comprehensive information on licensing of third party dependencies, as ORT seems to find the provenance and scan the source code of the dependencies as per the versions mentioned in the dependency lists.
- ORT could be integrated with Eclipse SW360, which is a repository to store project information, third party dependency information, and the relationship between the project and the third party dependencies.
- ORT provides information on vulnerabilities, and we may check if that information about CVEs could be send to Eclipse SW360 from ORT, automatically after every scan of a project. This could be very beneficial for anyone outside the security team as well, as the component information give insights on CVEs as well.
- Another aspect is that, tracking of the third party components used in projects in a repository could be very useful when a general alert about security of a component is out in the public. We could track the projects affected by the vulnerability in the third party components and act on it.