You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, full disclosure, I work on the OWASP CycloneDX software bill of materials project https://cyclonedx.org/.
A software bill of materials, in a very basic sense, is a list of all the components that make up a piece of assembled software.
The current output of the info command provides this information.
But that output format is specific to the Conan ecosystem. CycloneDX is an ecosystem agnostic format.
Having this information in a standard format helps with a number of use cases. Identifying components with known vulnerabilities, OSS license compliance, and supply chain component analysis, as examples. Especially in organisations that are building software in multiple ecosystems.
I had been planning to implement a specific tool to do this. But after digging into it, I think it might be better to add it as an additional output format for the info command. Perhaps a --cyclonedx-json option?
If this is something you'd accept a PR for let me know and I'll start working on the implementation and tests.
This looks interesting, and we are willing to accept contributions for this. But right now we are moving fast from 1.X => 2.0, it won't make sense to duplicate the effort, all the interfaces, APIs, etc are being re-designed.
Lets follow up when the Conan 2.0 python api is at least there (will be in a few months, while beta stage), to implement this. Thanks for offering to contribute it!
Hi, full disclosure, I work on the OWASP CycloneDX software bill of materials project https://cyclonedx.org/.
A software bill of materials, in a very basic sense, is a list of all the components that make up a piece of assembled software.
The current output of the
info
command provides this information.But that output format is specific to the Conan ecosystem. CycloneDX is an ecosystem agnostic format.
Having this information in a standard format helps with a number of use cases. Identifying components with known vulnerabilities, OSS license compliance, and supply chain component analysis, as examples. Especially in organisations that are building software in multiple ecosystems.
I had been planning to implement a specific tool to do this. But after digging into it, I think it might be better to add it as an additional output format for the
info
command. Perhaps a--cyclonedx-json
option?If this is something you'd accept a PR for let me know and I'll start working on the implementation and tests.
The text was updated successfully, but these errors were encountered: