Added configurable reference generation between the components of a multi-language SBOM #1567
Conversation
|
Cool idea! |
docs/ENV.md
Outdated
| @@ -6,6 +6,7 @@ The following environment variables are available to configure the bom generatio | |||
| | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | |||
| | CDXGEN_DEBUG_MODE | Set to `debug` to enable debug messages | | |||
| | GITHUB_TOKEN | Specify GitHub token to prevent traffic shaping while querying license and repo information | | |||
| | MULTI_BOM_COMPONENT_REF | When building a multi-language BOM, choose how the references between the components is handled. This can be useful if other tooling used to eg visualize the dependency-tree only uses 'dependsOn' (as the name dependency-tree more or less implies). Possible values: `dependsOn`, `provides`. Default: `provides`. | | |||
There was a problem hiding this comment.
Does this work with our configuration files? .cdxgenrc etc?
There was a problem hiding this comment.
Don't know, I didn't know there are config files! 😄 I'll try it and let you know what I find/try to fix it if it doen't.
There was a problem hiding this comment.
@prabhu Is it currently possible to put EnvVars in the config files? I can't seem to find any documentation on that, or in yargs for that matter... Or is this a feature that needs to be added?
There was a problem hiding this comment.
Good point. I think only command line arguments can be passed via config files. Do we need this variable or can we just assume dependsOn ?
There was a problem hiding this comment.
There's already lots of EnvVar-configs, so we could maybe leave it like that? Or add it as a cli argument.
Maybe it would be good to clean that up a bit at some point and have both support all current args and EnvVars?
There was a problem hiding this comment.
I meant, do we need this new variable MULTI_BOM_COMPONENT_REF at all?
There was a problem hiding this comment.
Not necessarily, I just thought it would be good the have the option to choose. I initially didn't have it, then decided to change the default to provides, since this made more sense to me.
I'll remove it and set it to dependsOn; We can always add something if a request is made. 😄
lib/cli/index.js
Outdated
| const multiBomComponentRef = | ||
| "dependsOn" === process.env.MULTI_BOM_COMPONENT_REF | ||
| ? "dependsOn" | ||
| : "provides"; |
There was a problem hiding this comment.
provides is only useful for CBOMs at this point. We can use default of dependsOn?
There was a problem hiding this comment.
I didn't realize that. I figured that logically it should not be a 'dependsOn' relation, my personal use however will be that every time because of the dependency-tree in Dependency-Track. So yeah, I don't mind turning the default around!
| ? "dependsOn" | ||
| : "provides"; | ||
| let parentDependencies = dependencies.find( | ||
| (d) => d["ref"] === parentComponent["bom-ref"], |
There was a problem hiding this comment.
Should we handle the case, where this could match the child of the parent component?
There was a problem hiding this comment.
I'm not quite sure if I follow you here... bom-refs should be unique, right? So in what case would this match a child component?
There was a problem hiding this comment.
parentComponent could have a list of components.
There was a problem hiding this comment.
That is actually already handled in 31c082d!
|
Is it possible to add a repo test to demonstrate this useful feature? I will fix the current repo tests failures in a different branch. |
That should definitely be possible, my testing-project is already part of the repotests anyway. I'll add some tests in later today. |
|
Can you also rebase. The repotests are fixed now. |
malice00
force-pushed
the
multi_bom_ref
branch
from
5528d1e to
7fa8a1f
Compare
|
All discussed issues should be included, now let's hope all tests work... 😉 |
…ulti-language SBOM Signed-off-by: Roland Asmann <[email protected]>
…ed... Signed-off-by: Roland Asmann <[email protected]>
Signed-off-by: Roland Asmann <[email protected]>
Signed-off-by: Roland Asmann <[email protected]>
Signed-off-by: Roland Asmann <[email protected]>
malice00
force-pushed
the
multi_bom_ref
branch
from
7fa8a1f to
f3e667e
Compare
|
Darn, more commits were added. after I last pulled! Another rebase was done... 😄 |
When generating a multi-language SBOM, the first generated sub-BOM's parentComponent is used as the parent for the mixed SBOM -- but there are no references between the different sub-BOMs.
This fix adds references to all remaining sub-BOMs as a 'provides'-entries. It is also possible to add them as 'dependsOn', so that tools can actually show all components in the dependency-tree -- I noticed that eg Dependency-Track doesn't show references in 'provides'.
Small included change: GRADLE_XXX EnvVars in documentation grouped together, a duplicate EnvVar removed from docs.