SBOM-centric license workflow

The idea about an “SBOM-first” or maybe even “SBOM-only” workflow already teased earlier still appeals to me. In principle I don’t see why it couldn’t work, but I haven’t put it in practice, yet. My thinking is mostly CycloneDX-centric since that’s what I’m using right now. Generally, CycloneDX has free-form key-value properties where you can put everything SPDX-specific into, and SPDX has the CdxPropertiesExtension which is basically the same, so if you control the tooling you can do anything in either formats. Several thoughts and questions: All tools love to emit SBOMs, especially in the security field. Few tools like to use existing SBOMs and enrich them. SBOM import ist often just reading out components and never looking at the provided SBOM again or reusing any other information from it. Do you know a public enrichment tool or framework other than parlay? In CycloneDX tools like FOSSology seem to model files (component type = file) as siblings to packages (component type =…