CycloneDX
Question: Is there a reason why there is no command line option to sign the generated sbom-file using a given key?
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.
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.
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?
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.
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.
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.
Hi there, I would be interested to work on this as my first contribution as this is relevant to me. What exactly would be the requirements for this? As I understood it, the CLI supports signing only with XML-BOMs and only with RSA (correct me if im wrong).
Should the implementation for the .NET Tool simply replicate the functionality of the CLI?
Hey @Lachstec,
I don’t have deep knowledge about signing. Professionally, I’ve only used SBOMs internally. It’s fair to assume the CLI might be a bit outdated. The CycloneDX format should also support signing JSON files; you can check here: https://cyclonedx.org/use-cases/authenticity-verification/
I’m fine with either approach. Do whatever makes sense as long as it can also help others. If someone needs more later, they can build on top of it.
If you have deeper questions about how the standard itself handles encryption or signing, feel free to ask in the CycloneDX Slack: https://cyclonedx.org/slack/invite
I've checked it out and i think it would make sense to support it for XML and JSON. The CLI indeed seems to be a bit ot of date. I will have a look at it and keep you posted / open a PR when I get something done. Maybe we can adapt the solution and contribute back to the CLI should we get it working.
@mtsfoni I opened a PR addressing that. It currently mirrors the functionality of the CLI, allowing to sign XML BOMs with RSA. I also opened an Issue on the Repo of the CLI, proposing to add some functionality regarding signing of BOMs, as I think that the ability to work with X509-Certificates would be very nice.