OSS Review Toolkit’s Post

View organization page for OSS Review Toolkit, graphic

369 followers

Very good read on the complexity of creating the "right" type of #SBOM: https://lnkd.in/ecF92QQB. This is one of the reasons why ORT analyzes the application context (the "project" in ORT-speak), leveraging the original package manager programmatically, instead of parsing package manager files statically, or re-implementing the resolution algorithm, or assuming that NPM would resolve the same dependencies as e.g. Yarn does.

One set of requirements, zillions of SBOMs

One set of requirements, zillions of SBOMs

blog.deps.dev

Philippe Ombredanne

CTO, nexB & maintainer AboutCode stack: ScanCode, DejaCode and VulnerableCode

8mo

The emulated build of deps.dev is likely error prone, as for all practical matters builds are not yet reproducible and dependencies may/will be resolved differently on each build run. Anything that does not run the full real build is likely doomed. IMHO the binary analysis of the built and deployed binaries, or the parsing of lock files generated during the real build, or anything that plugs into and traces the real build are better ways than trying to reproduce and emulate a build.

Like
Reply

To view or add a comment, sign in

Explore topics