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
Currently the BOM is generated de novo for every dependency, but some crates (e.g. crates that include native code via a build.rs) really should produce their own BOM that's carried forward by downstream users. This could be done by e.g. adding necessary metadata into a package.metadata.bom section that tells us that a BOM is present inside the cargo package/source repository and where to find it.
The text was updated successfully, but these errors were encountered:
We could define a convention to look for an included BOM when a crate uses include in the manifest format or a metadata table with a cyclone-dx key. We could add it as an externalReference or parse it and merge it into our generated BOM (probably should be specified by a CLI argument flag). We should also look into what other ecosystems are doing for their CycloneDX implementations to have a common behavior where possible.
That sounds like a good idea in theory but has some issues in practice:
As you already noticed SBOMs are currently not discoverable, there is just no standard around this at the moment and this project is not the place to define one. I'm sure in a few years we'll have something.
It is currently best-practice to build your own SBOMs (one could think about augmenting them with some upstream metadata) because of things like different target platforms or different feature sets
There was talk at a recent Cargo office hours meeting of having Rust generate a "build info" file which would include everything that actually goes into a build (including build.rs things) which would probably be a better starting point
So, I'm inclined to close this issue because I don't see us being able to do anything here in the next few years.
Happy to reopen it if the situation changes.
This also runs into issues with feature and platform combinations. SBOM is generated for a specific set of features, and optionally for a specific target. Doing this for a Cargo project would require generating a SBOM for every possible combination of features, which would result in a combinatorial explosion.
Somehow picking up on BOMS for C code bundled with -sys crates would indeed be great, and that is tracked as #366
Currently the BOM is generated de novo for every dependency, but some crates (e.g. crates that include native code via a build.rs) really should produce their own BOM that's carried forward by downstream users. This could be done by e.g. adding necessary metadata into a package.metadata.bom section that tells us that a BOM is present inside the cargo package/source repository and where to find it.
The text was updated successfully, but these errors were encountered: