-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend metadata via user input #607
Comments
I'm actually not convinced that adding CLI flags for this is a good idea. CycloneDX is a standardized format, so if you get a stable interface to interact with any part of it. You can write a tool that applies the desired transformation once, and then use it with any generator or anything that speaks CycloneDX. By contrast, if we start adding CLI flags for various fields, that's a damn lot of fields and damn lot of flags; and these flags would be specific to every generator and would have to be separately implemented in every generator, and you would have to figure out the right flags for every generator as a user - as opposed to just running a CycloneDX editing tool on any CycloneDX file. |
First of all, thank you for your response. Ok, so currently our implementation isn't perfect, only the three fields required by NTIA and not required by CycloneDX are overwritten. There is only one flag (for this proposal, I have two others in the issues regarding purl and bom-ref), and that is the path to the extended metadata. From the cargo side, the problem is that this information is not available in the cargo metadata, and as far as we see it, author CANNOT be provided by the cargo metadata, because it is not a function of the software being described, but of the SBOM composition itself... therefor it must be provided extra to the CycloneDX execution. I don't know how it would be for the other CycloneDX tools. I agree it's not perfect and that's why I'm open to other proposals. But the flag is not breaking. By omitting it, you have the current functionality. I guess the danger is that someone uses the cargo flag and then changes to python or whatever and doesn't have it? As I see it, we have two (three) options:
|
Indeed, this is the approach I would recommend, if feasible. If it is infeasible for some reason for a given field, please let me know and I'll look into that on a case-by-case basis. |
Look at the following documents:
https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf
https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
We think that the following minimum baseline attributes are missing from the sbom.
It is possible to parse the author name and email, using appropriate the Cargo.toml field, however, this is the author of the package, not the author of the SBOM. We think the SBOM author should be independent of the package. We could create a program to parse the output and add the missing fields, however, we thought it might be nicer to provide this possibility via cargo-cyclonedx. Has this issue been already considered elsewhere and rejected?
Initial suggestion would be to include a CLI flag (eg. --metadata-extension-path) for specifying a metadata extension file in XML or JSON, which includes override metadata in the SBOM specified format, eg.:
This way it also is flexible enough for format changes. Poorly formed entries are ignored / rejected.
Interested in your feedback and open to other implementations and/or clarifications. We can implement.
The text was updated successfully, but these errors were encountered: