tsteenbe · HackerTrans

This is why several German automotive OSPOs are working together to build OSS Review Toolkit (ORT) - it kinda glues various open source tools like ScanCode but adds features like the ability to manually correct findings and a policy as code to do risk management at scale/speed. Full disclosure I one ORT maintainers.

tsteenbe

4 年前議論

> Do HN got a recommendation for other CLI based SBOM generators?

Try ORT https://github.com/oss-review-toolkit/ort (full disclosure I am one of its maintainers and also the lead of the SPDX Defects/Security Profile).

If people have questions on SBOMs, comparing SCA/SBOM tools or ORT - feel free to reach out to me https://github.com/tsteenbe/

ORT plug below ;-)

ORT is much more than a SBOM generator though, it's a cli/library that enables you to safely use, integrate, modify and redistribute third party software including FOSS.

You can use ORT to:

1. Generate CycloneDX or SPDX SBOMs for your software project

2. Automate your FOSS policy using Policy as Code to do licensing, security vulnerabilities and engineering standards checks for your software project and its dependencies

3. Correct found invalid or missing package metadata (licensing, source location, etc.) and license findings in the sources of your software project and its dependencies

4. Overwrite scanner license findings in the sources of your software project and its dependencies

5. Mark files, directories or or package manager scopes as not included in your software project or dependency released artifacts - use it to make clear that license findings in build scripts, documentation or tests in a package sources do not apply to the release (binary) artifact

6. Create a source code archive for your software project, including its dependencies to comply with certain license or have your own copy as nothing on the internet is forever

ORT is being built by Open Source Program Offices from Bosch, EPAM, HERE and others for several years who got frustrated with the state of SCA/SBOM tools not being able to support license compliance properly and the 30+ build tools you can find in a lot of large organizations.

To get started with ORT on your local machine I recommend using https://github.com/oss-review-toolkit/orthw/.

tsteenbe

5 年前議論

Good catch I missed that openCVE is Business Source License which I actually do not consider to be open source.

tsteenbe

5 年前議論

Are you aware of https://github.com/nexB/vulnerablecode? which offers a similar solution, is also open source and written in Python.

tsteenbe

7 年前議論

> It makes license scanning a doddle.

As someone working in the field of license compliance (leading an Open Source Program Office) and dealing with the licensing of tens of thousands of OSS dependencies on a daily basis for a large company I can tell you that license scanning / compliance is anything but a doddle. I do a lot of public speaking on this topic for a summary of the issues I recommend you to have a look at https://static.sched.com/hosted_files/ocs19/c7/OSS-Review-To...

Most modern package managers do offer project maintainers a way to declare the license for a project. However I can tell you that often the declared license does not match the licenses detected in the source code. What counts is the license stated in the source code files not what it's in the gemspec, package.json, pom.xml etc.

This is quite common issue especially for older or larger OSS projects where various contributors have added new code over time that may be licensed under an OSS license that is compatible but not the same as the main license of the projects (Think adding BSD-2-Clause in Apache-2.0 project) What happens is that this contributions get accepted but the project maintainers do not to update the declared license.

Not saying declaring a licensing in a .gemspec file is useless but just recommend you to take it as an indicator of the main license of the project - the project may include source code that licensed under a different license.

Lack of clarity around licenses and security vulnerabilities is a big issue within the OSS community especially as lack of clarity reduces engagement — that means fewer users, fewer contributors and a smaller community. Several organizations are working on a open source solution for this community problems see for further details https://clearlydefined.io/about

Full disclosure I am one of the maintainer of OSS Review Toolkit and contributor to ClearlyDefined.io

tsteenbe

7 年前議論

> A trivial solution would be to create a crowd-sourced dependency vetting platform.

Such a platform is already being developed by various organizations, see https://clearlydefined.io/about and it already in use by GitHub. It's still under development and the initial focus is sharing data regarding copyrights, licenses and source code location for OSS packages.

Note that ClearyDefined only scans the code repository of OSS project it does not resolve dependencies for scanned OSS project. This makes sense as not all dependencies of OSS project B are inherited by a project A which included B as a dependency (due to dependency version resolution by the package manager or dependencies only used for testing).

The idea is that you will us an tool to resolve dependencies for the package manager your project uses which then queries the ClearyDefined APIs.

We are building such a tool as an open source project to manage of licensing and security for dependencies named OSS Review Toolkit (https://github.com/heremaps/oss-review-toolkit).

For a overview of the solution we are building see slide 9 in https://static.sched.com/hosted_files/ocs19/c7/OSS-Review-To...

Full disclosure: I am one of the maintainers of OSS Review Toolkit and also a contributor to ClearlyDefined.

tsteenbe

7 年前議論

If you want to do license compliance for various package managers then I recommend you checkout https://github.com/heremaps/oss-review-toolkit.

Full disclosure: I am one of the maintainers of OSS Review Toolkit.

コメント