Replies: 2 comments 10 replies
-
|
Hello @oatovar We currently show |
Beta Was this translation helpful? Give feedback.
-
I don't think it can represent the graph with assemblies. See my example of Module Root Z. Module C appears twice. How can we represent it with assemblies? I saw the following example on page 46. It works only when a nested component has a single parent. If a component has multiple parents, it would be duplicated. |
Beta Was this translation helpful? Give feedback.
-
Yes, but it wouldn't be duplicated at the top level as it is now. With assemblies, the components structure would look like this. "components": [
{
"name": "Module A",
"version": "v1.0.0",
"components": [
{
"name": "Module B",
"version": "v1.0.0",
},
{
"name": "Module D",
"version": "v1.0.0",
"components": [
{
"name": "Module C",
"version": "v1.2.3",
},
]
},
],
},
{
"name": "Module Z",
"version": "v1.0.0",
"components": [
{
"name": "Module B",
"version": "v1.0.0",
"components": [
{
"name": "Module C",
"version": "v1.0.0",
},
]
},
{
"name": "Module D",
"version": "v1.0.0",
"components": [
{
"name": "Module C",
"version": "v1.0.0",
},
]
},
],
},
]I've omitted fields for brevity in the example above, but it encapsulates the case mentioned. It keeps the different occurrences of |
Beta Was this translation helpful? Give feedback.
-
|
Your example SBOM doesn't describe Module D under Module Z. In many cases, components have several parents, which means we need to put them in the top-level components and use the dependencies |
Beta Was this translation helpful? Give feedback.
-
|
😄 Sorry, I was typing this by hand and made an error there, but it's been corrected and does include the module now.
You don't need to do this, and you can still use the dependencies section. |
Beta Was this translation helpful? Give feedback.
-
No problem. Yes, then Module C appears many times. The popular libraries that are often used have so many parents, and using assemblies makes them considerably harder to see and creates more confusion when completely identical components (instances) appear multiple times. In the case of using dependencies, the identical instances only need to appear once, so it is simpler. SBOM still has the same components with the same name, version, etc, though. However, this is our view and we are open if the CycloneDX team thinks that assemblies should be used even in the case of multiple parents. |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to close out this discussion since it's not really a bug, and regardless of the decision to use assemblies or not, separate instances of the components will always be needed to produce an accurate representation of the dependency graph. I appreciate the insightful discussion very much! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, too. It has given us the opportunity to think again about how SBOM should be structured. |
Beta Was this translation helpful? Give feedback.
-
Description
If you generate an CycloneDX SBOM for the
golang:1.22image, you'll receive a lot of duplicatestdlibcomponents instead of a single component.Desired Behavior
As specified in the CycloneDX specification, all items must be unique. In this case the stdlib for Go
1.22.3is the same regardless of the binary location, so it should only appear once with the samebom-ref.Actual Behavior
The resulting CycloneDX SBOM will contain multiple entries for
stdlibversion1.22.3.Reproduction Steps
Target
Container Image
Scanner
None
Output Format
CycloneDX
Mode
Standalone
Debug Output
Operating System
macOS 14.4.1
Version
Checklist
trivy image --resetBeta Was this translation helpful? Give feedback.
All reactions