CycloneDX
Extend metadata via user input
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.
- /metadata/authors (of the SBOM)
- /metadata/Supplier
- /metadata/component/publisher
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.:
{
"authors": [
{
"name": "SbomAuthor",
"email": "[email protected]",
"phone": "6345789"
}
],
"component": {
"publisher": "Developer, Inc."
}
"supplier": {
"name": "Supplier, Inc.",
"url": [
"https://www.supplierco.com"
],
"contact": [
{
"name": "Supplier",
"email": "[email protected]",
"phone": "6345789"
}
]
}
}
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.
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:
- Write a script or program which takes the CycloneDX output and modifies it (adds the missing fields). <- It seems to me this is the intended approach
- Modify CycloneDX tool (Cargo) internally for our purposes and just use that version <- What we are doing now, not sustainable
- (Write our own thing from scratch) <- We will not do this for cargo when you have already provided such a wonderful tool
Write a script or program which takes the CycloneDX output and modifies it (adds the missing fields). <- It seems to me this is the intended approach
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.