Question: Is there a reason why there is no command line option to sign the generated sbom-file using a given key?

[ksidirop-laerdal]

Essentially what the subject says. CycloneDX itself supports this just fine:

cyclonedx  sign   bom                \
               "${bom_file_path}"     \
               --key-file   "${sbom_signing_key_file_path}"

Appreciate any insights. Keep up the good job.

[mtsfoni]

Looks like it's implemented in the CLI directly and not in the library: https://github.com/CycloneDX/cyclonedx-cli/blob/main/src/cyclonedx/Commands/Sign/SignBomCommand.cs

There is no particular reasons it's not possible in this tool. I think it could be a useful addition.

[Whathecode]

More broadly speaking, what is the plan in terms of all the other features in the CLI tool in relation to cyclonedx-dotnet?

Can we expect merge/add/etc. to be added here as well?

[mtsfoni]

More broadly speaking, what is the plan in terms of all the other features in the CLI tool in relation to cyclonedx-dotnet?

Can we expect merge/add/etc. to be added here as well?

As this tool is to generate SBOMs from nuget dependencies and the CLI tool does exists, I only see such features in the generator that are tightly related to generating an SBOM. Merging and adding are not directly related to generating a SBOM from nuget. That somebody wants to have the generated SBOM signed is something I still see relevant.

Long story short: If you need a bunch of changes after creating the SBOM with the dotnet tool, the intended way is to use an editing tool, like the cli-tool.

[Whathecode]

Merging and adding are not directly related to generating a SBOM from nuget.

I can follow that reasoning. However, we currently have to rely on the CLI tool because the SBOM we generate is incomplete, e.g., missing native dependencies. Adding additional components to the SBOM, in that sense, is very much related to generating it!

Possibly that means additional functionality should be added to generate more complete SBOMs, i.e., incorporating native dependencies, in which case the problem is solved for now. However, consider that there may be numerous cases which require more specific post-generation mutations. Trying to account for all of them may not be the right approach, architecturally.

Whenever such mutations are needed (which I suspect may become more the norm than an exception), people will need to set up custom steps in their CI/CD pipelines to pull in cyclonedx-cli (using the matching assembly for the agent's target platform) and run additional commands on the original output of cyclonedx-dotnet. If so, that sounds highly cohesive to me, and feels rather arbitrary to keep them separated.

Actually, quickly checking your profile, it looks like the dotnet tool you created seems like another example of exactly such a use case! I believe that rather than creating a plethora of intermediate SBOM transformation tools, it makes more sense to provide more generic/configurable behavior in a single cyclonedx-dotnet generation tool.

[mtsfoni]

Whenever such mutations are needed (which I suspect may become more the norm than an exception), people will need to set up custom steps in their CI/CD pipelines to pull in cyclonedx-cli (using the matching assembly for the agent's target platform) and run additional commands on the original output of cyclonedx-dotnet. If so, that sounds highly cohesive to me, and feels rather arbitrary to keep them separated.

It's a matter of scope: cyclonedx-dotnet generates SBOMs specifically for .NET applications, while cyclonedx-cli provides mutating functionality for any CycloneDX SBOMs, regardless of their ecosystem. The CLI is used across various ecosystems, such as Java, npm, or Python, offering a consistent interface that simplifies tasks for DevOps teams. Without this unified tool, they would need to learn different mutating syntaxes for each ecosystem.

Nobody would suggest integrating grep into cat just because they are often used together—their separation keeps each tool focused, flexible, and reusable. In the same way, keeping cyclonedx-dotnet dedicated to SBOM generation while cyclonedx-cli handles mutations ensures a cleaner architecture, a smaller package size, and avoids unnecessary dependencies.