Candidates for integrations support

[tdruez]

Selection from https://cyclonedx.org/tool-center/

• CycloneDX native plugins - CycloneDX anguage-specific generators (cyclonedx-python, cyclonedx-node-npm, cyclonedx-node-yarn, cyclonedx-gradle-plugin, cyclonedx-maven-plugin, cyclonedx-dotnet, cyclonedx-gomod, cyclonedx-rust-cargo, cyclonedx-php-composer, cyclonedx-ruby-gem).
• Amazon Inspector SBOM Generator (Sbomgen)
• gh-sbom: Generate SBOMs with gh CLI
• apko: apk-based OCI image builder
• SCANOSS Open Source Inventory Engine
• Aikido

[gyanranjanpanda]

hi @tdruez i want to work on this issue could i

[nik-767]

Hi @tdruez ! I'm very interested in helping with this issue, particularly as a prospective GSoC contributor. I see the design-needed label. To get started on a proposal, should I focus on drafting an integration plan for one specific tool first (like gh-sbom or the CycloneDX native plugins), or are you looking for a generalized architecture for all of them?

My initial thought is to research their output formats (mostly CycloneDX JSON/XML) and see how they can be ingested into ScanCode.io's existing pipelines. Let me know how you'd like to proceed .

[dikshaa2909]

Hi @tdruez
This looks like a valuable step toward expanding ScanCode.io’s SBOM integration capabilities.

To approach this incrementally, it might be useful to start with a CLI-based CycloneDX generator (e.g., cyclonedx-python) and evaluate how its generated SBOM (CycloneDX JSON) can be consumed through the existing import pipeline. In particular, we could examine how closely its output aligns with the current CycloneDX ingestion logic and whether any normalization or mapping layer would be needed.

That could help define a reusable integration pattern before considering more complex or service-based tools. I’d be happy to explore one candidate and document the findings.