Could you please fix the linting issues? Most, if not all, can be fixed by running eg npm run lint.
Also, please sign your commits with git commit -s (see https://github.com/CycloneDX/cdxgen/pull/1803/checks?check_run_id=42351100134).

Other than that, looks good to me! Thanks for the PR!

Still discussing about what to do with the toolchain. Ideally, it should go into the formulation section. Maybe we do this in a separate PR to keep this going.

I'd say let's do that in a separate PR, might be a bit much to throw that in here...

Is there some reason for not using go mod edit --fmt {go.mod} to format the go.mod before parsing

for (const f of gomodFiles) {
      const result = spawnSync("go", ["mod", "edit", "--fmt", f], {
        cwd: basePath,
        encoding: "utf-8",
        timeout: TIMEOUT_MS,
        maxBuffer: MAX_BUFFER,
      });
      // Check if format go.mod successfully
      if (result.status !== 0 || result.error) {
        console.warn(`go mod edit --fmt ${f} command has failed.`);
        if (DEBUG_MODE && result.stderr) {
          console.log(result.stderr);
        }
      }
}

have open a PR for tool

Still discussing about what to do with the toolchain. Ideally, it should go into the formulation section. Maybe we do this in a separate PR to keep this going.

have opened a separate PR: #1805

Is there some reason for not using go mod edit --fmt {go.mod} to format the go.mod before parsing

for (const f of gomodFiles) {
      const result = spawnSync("go", ["mod", "edit", "--fmt", f], {
        cwd: basePath,
        encoding: "utf-8",
        timeout: TIMEOUT_MS,
        maxBuffer: MAX_BUFFER,
      });
      // Check if format go.mod successfully
      if (result.status !== 0 || result.error) {
        console.warn(`go mod edit --fmt ${f} command has failed.`);
        if (DEBUG_MODE && result.stderr) {
          console.log(result.stderr);
        }
      }
}

I assume this is because we don't want to change any files in your project. When you have a different, valid formatting in your files, it is probably there for a reason (even if personal preference) and we should not change this. Maybe it doesn't matter for go, there are however tools where changing files resolves in issues with the build and we should not be the reason builds break.

@prabhu: Or am I completely wrong and should we add formatting and a big disclaimer?

have open a PR for tool

Still discussing about what to do with the toolchain. Ideally, it should go into the formulation section. Maybe we do this in a separate PR to keep this going.

have opened a separate PR: #1805
Awesome, will take a look right after merging this!

Again, thanks for this PR!

That is correct. We should move to a model where the source (directory, image, and binary) remains unmodified after the BOM generation. We only need write access to the some output files and a temp directory.

With --install-deps or --deep arguments, we install packages and run tools like atom that taint the input environment, which is also a risk since the tool now becomes an attack vector.