-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not use ORT built-in SPDX report? #12
Comments
We're doing research on the matter, and we found that in order to fully understand the world of SBOM, we need to do some investigation ourselves. We're choosing another approach to getting the SBOM. We're using THIS IS ALL EXPERIMENTAL AND NOT USED IN PRODUCTION We're also comparing the spdx outputs with blackduck (SPDX-builder can produce a SPDX file from a blackduck output) and other tools. In Philips we have a lot of different type of projects / setups. So using this setup we've learned a lot about how you can create a SPDX file from an existing project. We found that it's very difficult to have a tool give the right SBOM if it does not know the context of a project. Often results from a tool need to be checked / filtered by an application expert on what's really in the code. The key difference is that the scan environment only needs to know it's own build environment. No more detect scanners with a certain version of dotnet in it which perform some magic. No more magic detection of how a developer setup his python project, which is often not standarised. We need to involve the application expert anyways, so let's make him co-owner of the SBOM by asking her what dependencies there are in the project. We convert them to the latest purl spec or whatever is necessary. Again, this is all experimental and we're testing it with a lot of different internal projects. We want to minimize the impact on the projects and we want to create various views on the SBOM for different people. Legal should see about conflicts in compatible licenses.. Security should see about vulnerabilities. An Export Control officer should see if some 'dangerous' packages are used and the developer should have a feeling the tools are supporting her work instead of adding work to her already busy agenda. More on the Tree-based part: https://github.com/philips-software/spdx-builder/blob/develop/docs/usage_with_tree.md We're planning to deploy OSS versions of the tools so we can also demo this to others. |
Thanks for the detailed response. It is interesting. I'm also looking into a setup where the 'application experts' are responsible for generating and submitting the SPDX files. Byt your idea of still scanning on a central level sounds interesting. The infrastructure becomes somewhat more complex (moving parts at the teams and at the central level), but it seems to make sense. Anyway, thanks for your work in this area, it is inspiring! |
I'm looking into license scanning solutions and I already found ORT as a batteries-included solution around scancode-toolkit. This repo was linked as an example for a github action, which is still a todo there.
Looking into your solution I noticed you use your own
spdx-builder
. Why did you choose a roll-your-own solution, rather than the built-in spdx report from ORT? Was this a timing issue that it was not yet available in ORT?Also: thanks for developing this in public, it is an interesting solution that has some nice ideas like pushing the SPDX documents to a central repo.
The text was updated successfully, but these errors were encountered: