Consider adopting ORT

[tsteenbe]

Happen to stumble upon the announcement of this project and wonder if the maintainers of this project are familiar with or have considered OSS Review Toolkit which offers similar functionality as this project.

ORT is a Linux Foundation project maintained by several (mostly automotive) OSPOs and one can use it to automate your FOSS policy using Policy as Code to do licensing, security vulnerabilities and engineering standards checks for your software project and its dependencies. It support detecting dependencies for ~20 different package managers out-of-the-box and is battle-tested with hundreds of thousands of scans done amongst its users over the last 6 years.

ORT users include Bosch, Deutsche Telekom, EPAM, Forvia, HERE Technologies, Porsche and recently the Eclipse foundation indicated its adopting ORT within their IP process.

Happy to do a demo/q&a call, you can reach me via opensource [at] steenbe [.nl]. Will be demo-ing ORT capabilities as part of my Nov 15, 2022 TODO OSPOLogy talk, see also https://community.linuxfoundation.org/events/details/lfhq-todo-group-presents-how-to-automate-your-foss-policy-and-processes/

[maoo]

Hi @tsteenbe, thanks so much for the pointers, ORT seems very interesting indeed!

I gave it a try, using https://github.com/finos/morphir-elm/ as project to scan, but I got a different outcome than the one I get with FINOS Security Scanning; maybe I'm doing something wrong, so below I'm going to document my steps.

These are the steps I used to generate the analyzer-result.json with ORT:

git clone git@github.com:finos/morphir-elm.git
git clone git@github.com:oss-review-toolkit/ort.git
cd ort
./gradlew installDist
./cli/build/install/ort/bin/ort --info analyze -f JSON -i ../morphir-elm -o ../morphir-elm/ort
open ../morphir-elm/ort/analyzer-result.json

The file contains 1 issue, which refers to a missing lockfile.

Below the steps to run FINOS Security Scanning:

cd moprhir-elm
npm install --prod
npx --yes auditjs ossi

The scan finds the following CVE:

[27/77] - pkg:npm/express@4.17.1 - 1 vulnerability found!

  Vulnerability Title:  1 vulnerability found
  ID:  sonatype-2012-0022
  Description:  1 non-CVE vulnerability found. To see more details, please create a free account at https://ossindex.sonatype.org/ and request for this information using your registered account
  CVSS Score:  7.5
  CVSS Vector:  CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
  Reference:  https://ossindex.sonatype.org/vulnerability/sonatype-2012-0022

Note that the CVE - in this case - does not apply to Morphir (due to the way request parameters are managed), so the team have ignored the warning by defining an allow-list.json; by running npx --yes auditjs ossi --whitelist allow-list.json you should get a successful run.

That being said, I think it would be great to meet next week, share screens and discuss it further, I'll ping you via email.

Thank you!

[tsteenbe]

@maoo Let do a call this week - you get a reply to your email soon - in the meantime below you will find the commands to:

1. Run ORT analyzer to get insights into all dependencies within morphir-elm but with allowDynamicVersions=true so you don't get the issue of missing lockfile
2. Run ORT advisor to get security advisors from OSV and OSSIndex for all dependencies found by the analyzer
3. Run ORT report to get CycloneDX/SPDX software bill of materials and a WebApp html file that makes it easier to browse the scan results.

./cli/build/install/ort/bin/ort -P ort.analyzer.allowDynamicVersions=true --info --force-overwrite  analyze -f JSON -i ../morphir-elm -o ../morphir-elm/ort

./cli/build/install/ort/bin/ort --info --force-overwrite advise -f JSON --advisors OSV,OssIndex --ort-file ../morphir-elm/ort/analyzer-result.json -o ../morphir-elm/ort

./cli/build/install/ort/bin/ort --info --force-overwrite report  --ort-file ../morphir-elm/ort/advisor-result.json -o ../morphir-elm/ort --report-formats CycloneDx,SpdxDocument,WebApp -O SpdxDocument=output.file.formats=json,yaml -O EvaluatedModel=output.file.formats=json

ORT can also:

• Apply policy rules to a scan so you can suppress vulnerabilities via its Evaluator
• Scan any project and its dependencies source code with a license scanner such as ScanCode

For your convenience here my local scan results morphir-elm-ort-results.zip

[maoo]

Thanks a lot @tsteenbe ! I checked the output you attached, and it looks very interesting! I see a lot of outputs referring to devDependencies, though - if I understand correctly from ORT docs - by running the command from the ort folder, I should inherit the .ort.yml configuration, which contains the devDependencies scope exclusion, see https://github.com/oss-review-toolkit/ort/blob/main/.ort.yml#L30

I'm sure I'm missing something obvious here, any help would be greatly appreciated. Until then, I'll keep on playing around. TY!

[TheJuanAndOnly99]

Hi @tsteenbe I'm working on this with @maoo. We are testing it on a rather large codebase and are seeing many HTTP 429 errors. Is there a way to work around this? We did some research and found that supplying credentials to the oss index is a potential solution but it seems ORT does not support this.

[heliocastro]

@TheJuanAndOnly99 Hi Juan Can you be most specific ( as most disclosure as possible ) to where your connections are going ? As i can see by the screenshot, is Cargo specific, or your 429 is happening for another package manager type ?

[maoo]

@TheJuanAndOnly99 Hi Juan Can you be most specific ( as most disclosure as possible ) to where your connections are going ? As i can see by the screenshot, is Cargo specific, or your 429 is happening for another package manager type ?

Thanks for the response @heliocastro , it's so great to witness all this support to help us out adopting ORT!

We got this 429 issue with Cargo but also with NPM dependencies, and apparently it's an issue that others have experienced with OSSIndex: too many requests. As @TheJuanAndOnly99 suggests, providing username/password to OSSIndex connections seems to mitigate this issue (as Sonatype's servers prioritises connections from users, rather than anonymous), but we haven't tried to be honest.

I've quickly checked the ORT code and found something interesting: Seems that OssIndexService.kt does support username and password parameters, but OssIndex.kt doesn't seem to read any config value and therefore doesn't make use of this feature. If that's the case, adding the feature should be extremely easy.

Please take all of this with a grain of salt, as we're quite new to ORT, and we may well be out of track.

Thanks again for your support!

[heliocastro]

OssIndex in the sense of ort code is reality to access the API of vulnerability provider. Quoting main Ort page:

If i'm understand correct, you want use Sonatype Nexus registry for both Rust and NodeJS, as a central storage location. Similar case happens as companies using Artifactory as central storage location

I need double check on my off time of daily work, but i think solution can be streamlined over a configure each registry on runtime env as their own configs, but i'm just guessing the possibility. Need to proper check before give a correct answer.

[maoo]

If i'm understand correct, you want use Sonatype Nexus registry for both Rust and NodeJS, as a central storage location. Similar case happens as companies using Artifactory as central storage location

Actually, we don't have any Sonatype Nexus registry (or artifactory). To reproduce the issue, please follow the steps mentioned above by @tsteenbe . When I mentioned "Sonatype's servers" above, I was referring to ossindex.sonatype.org (sorry for the confusion).

The 429 issue occurs when ORT tries to connect to OSSIndex API, and it does it too many times because the project's dependency tree is too big. This is the issue at hand I think.