[FEATURE IDEA] postProcess option

[lal12]

There are cases where the resulting BOM might be wanted to change.
Currently I want to add fields to metadata.compononent (beyond rootComponentType, rootComponentName, rootComponentVersion), add its git repo, add more external components and add to metadata.tools.

My webpack build is currently pulling code from three repos, two libraries and the other one is a collection of templates which are converted to code and imports are automatically generated for them. So I want to track their existence and version of the individual parts of the project.

[jkowalleck]

I have too many questions. So I converted this request to a discussion.
Here, we can discuss and elaborate on each aspect individually. I will create sections for the questions I am currently having.

@lal12, could you help understand, what information you are missing, where it can be gathered, and wy the current algorithm is not collecting your needed data already?

---

A general request I have: Could you share this setup you are using? or maybe a reduced example setup?

[lal12]

Hmm, in doubt I could make a mockup project with the same structure, but I will try it like this first:

• builder: a repo containing tools to build the project. Basically a webpack wrapper with plugins and loaders.
• templates: a repo containing several templates for several project.
  Device/Project Owners with little programming knowledge will edit this. Often with a "WebIDE and a LowCode approach"
  • deviceA: contains the templates for a single device/project
    • website
      • pages
        • Home
        • Network-Settings
        • …
      • Main: website tree
      • language-texts.yml
  • deviceB: …
  • deviceC: …
    …
• lib: a repo containing library of react components usable in the templates
  • ui/
  • controllers/
  • Entry.ts
  • package.json
  • webpack.config.js
• lib-shared: a library of shared code between the device server and client,
  theese files will be included directly not as a node_module
  since there are different targets and other different needs
  depending on the using application.
  (is imported by lib in this scenario)
• config-database: a data source where parameters and its types / typechecks are defined

builder now will be called and given all of those repositories.
It will convert the templates into react code and add the needed imports from lib.
It will generate code from the language-text.yml and add the needed imports to the template code.
It will generate code for the Parameters from config-database and will include them.
It will bundle it all starting with Entry.ts.

So I have 4 repos included in the build with seperate versions and a repo with a tool also with it's own version. These parts and versions should be tracked in a SBOM. The repos don't have versions in their package.json and instead are tracked by their tag/commit.

[jkowalleck]

This CycloneDX webpack plugin generates an SBOM.
A SBOM describes the result and its ingredients, what is actually in it.

An SBOM is NOT a recipe, how the result was cooked up. It is not intended to describe which tools composed the result, how they were used and in what order.
This would be another kind of document, that you should be able to write with CycloneDX, but not with this webpack plugin.

You really should join the CycloneDX slack and ask for help and guidance. I can not teach you SBOM in a GitHub discussion.

[lal12]

Well that's just a semantic discussion on what's counts as an "ingredient", I don't see any reason another repo shouldn't be an "ingredient".

If @CycloneDX/cyclonedx-webpack-plugin isn't supposed to support a structure, fine.
But it easily could serve for my use case (and others) with some customizability. I didn't made a PR for myself (I already use a patched version anyway), but for convenience of other users. And generally why should any tool not be flexible/customizable, if the required code/maintenance is negligible.

If you disagree, no problem... I don't see a point on arguing about more exotic use cases and semantics apparently not even clearly defined in the spec.

[jkowalleck]

@lal12 Just in case you wonder how to get components, pedigree and compositions build your desired results:
i think some features of the upcoming CycloneDX v1.5/v1.6 spec will be enabling you to describe the formulation and transformation and processing your workflow is doing.

[jkowalleck]

Aspect: modify bom.metadata.compononent

I want to add fields to metadata.compononent (beyond rootComponentType, rootComponentName, rootComponentVersion), add its git repo [...]

Which fields in particular do you need populated? Are they not already read from the package.json of the project under analysis? It is expected, that all available data is populated already.

[lal12]

Also I want to add the license texts for each component.

Licenses are already picked up. just mention your licenses as "license" in the pckage.json. read https://docs.npmjs.com/cli/v9/configuring-npm/package-json#license example: https://github.com/CycloneDX/cyclonedx-webpack-plugin/blob/master/tests/integration/webpack5-vue2/package.json#L7

Not the content of the license. Which sometime might slightly differ from the spdx id, also the copyright notice would not be included.

[jkowalleck]

Licenses are already picked up. [...]

Not the content of the license. Which sometime might slightly differ from the spdx id, also the copyright notice would not be included.

For the sole reason that there is no defined process of finding a license text in this kind of software stack.
If you think you found a solution, please contribute to CycloneDX/cyclonedx-node-npm#256

[lal12]

Also I am considering putting all the components inside of metadata.component.components, to get a hierarchical structure of the components. Since in the end this BOM will be merged with other BOMs to get a final (hierachically structured) BOM for a device firmware.

The purpose of bom.metadata.component is "The component that the BOM describes.", not the composition itself, therefore nesting everything in metadata.component.components[] is not intended.

Your merge tool shall nest the bom.componentsp[ already.

You really should join the CycloneDX slack and ask for help and guidance. I can not teach you SBOM in a GitHub discussion.

Not saying you are not right on that, but I read the spec and as I understand it, it would (only) make sense to put it into it.

[lal12]

Licenses are already picked up. [...]

Not the content of the license. Which sometime might slightly differ from the spdx id, also the copyright notice would not be included.

For the sole reason that there is no defined process of finding a license text in this kind of software stack. If you think you found a solution, please contribute to CycloneDX/cyclonedx-node-npm#256

I am not aware of any standardized process for this, but reading something like /^LICENSE|COPYING(\.(md|txt|rst))?$/i from any package works in many cases and is better than having none of them. Which is was I currently use.

[jkowalleck]

am not aware of any standardized process for this, but reading something like /^LICENSE|COPYING(.(md|txt|rst))?$/i from any package works in many cases and is better than having none of them. Which is was I currently use.

I agree.
I am planning to create or adopt a standardized process of license detection for all node-based CycloneDX derivates.
Therefore, I would love to read your input in CycloneDX/cyclonedx-node-npm#256
If you would pullrequest a solution there, i think it could be driven further and be made into a universal solution that could be part of this implementation, here.

[jkowalleck]

Aspect: modify bom.components[]

I want to [...] add more external components [...]

Are these components used to produce webpack's build result? Are these components bundled into the build result somehow?
What are these components? Could you name or link them?
Why do you think they should be added to the SBOM?

[lal12]

As to the templates yes they are bundled (through a custom loader). But they are only mentioned if I create a package.json in the repo, which I guess is sensible, since there isn't an easy way to detect them as a seperate component.

[jkowalleck]

As to the templates yes they are bundled (through a custom loader). But they are only mentioned if I create a package.json in the repo, which I guess is sensible, since there isn't an easy way to detect them as a seperate component.

This webpack plugin is tailored to the constraints of webpack being a runner in nodejs,
which analyses assets packaged for nodejs.
Each "component" of the SBOM is a package for node - a node module.
A node module is defined by having a package.json in the root level.

Current implementation in this webpack plugin searches for the nearest up-level package.json based on a file that is packed by webpack, after tree shaking.

To get your custom components picked up and described correctly, please put a package.json in the appropriate (sub) module root folders.
If you fill those package.json files with valid content according to the spec, then all the data should be picked up properly.

Please let me know, if this worked for you.

[lal12]

Hmm, not really/completly.
I would have to place a package.json in each directory in templates for proper naming, this would break some of the existing tooling. Also all of the project parts don't use versioning in/of the package.json, but git tags / commits, so versioning also wouldn't be solved by it.

[jkowalleck]

Understood. custom setup - custom workflows - custom everything.

You could always come to the Official CycloneDX slack or the mailing list and discuss your topics with several hundred other CycloneDX developers, experts and users.

[jkowalleck]

gave the topic some thoughts.
I think you actually do not want to alter the components, but add to the composition. read https://cyclonedx.org/docs/1.4/json/#compositions
There you could describe how your build results were created and which templates were used and such ...
But this is still a topic that has nothing to do with this webpack plugin.

[jkowalleck]

Aspect: modify bom.metadata.tools[]

I want to [...] add to metadata.tools.

What tools are these? Could you name or link them?
Why do you think they should be added to bom.metadata.tools[]?

[lal12]

Nothing public (see the builder repo above). And possible a LowCode IDE for the templates repo (see above).

Probably bom.metadata.tools is actually wrong, since it probably is meant for stuff creating the BOM not the software, but whereever the "compiler" of project is supposed to go.

[jkowalleck]

so none of the things you describe are involved in creating the SBOM?
Then none of these tools shall be added here.

You really should join the CycloneDX slack and ask for help and guidance. I can not teach you SBOM in a GitHub discussion.

[jkowalleck]

📣 Conclusion

Will not implement this feature.
This has technical reasons:

Webpack works in a node environment and this package works in a node environment.
Requested "postProcessing" works in a node environment.

Node environments do NOT share a global bunch of packages/modules (quality/quantity). Each module can have own node_modules and will prefer those over the one traversed up/inherited down.

The environment in which the requested "postProcessing" runs might have different node modules than the environment in which this plugin runs.
This means the "postProcessing" might have a different version of @cyclonedx/cyclonedx-library than the plugin has.
Which could lead to invalid/unexpected results when this plugin generates (serialize/normalize) SBOM documents and therefore renders the process invalid.

To prevent internal mismatches, there should be no option to interfere the result of this plugin.