Go module scanning

[sushiMix]

Hello, I tried cdgxden to produce a sbom from go mod.
I can see the dependencies which seems fine but i'm a bit surprise with the component declaration itself.

"component": {
"group": "",
"name": "app",
"version": "latest",
"type": "application",
"bom-ref": "pkg:golang/app@latest",
"purl": "pkg:golang/app@latest"
}
Why the go module itself for the name is not used which seems more consistent with the dependencies and will ease traceability between multiple scans ? Is it to distinguish app vs library ?

Is there also a plan to support Go in evinse ?

[prabhu]

@sushiMix, we try to detect the main module using the go list command, so I'm not sure why it wasn't working in your case. Could you set the environment variable CDXGEN_DEBUG_MODE=debug to troubleshoot?

https://github.com/CycloneDX/cdxgen/blob/master/index.js#L2808

Regarding evinse for Go or any new language, the project is powered by atom, which supports a few languages. Adding new language support requires people with certain skills who are unlikely to work for free and also requires training in the field of code analysis and compiler frontends. So, we offer an enterprise package where we seek multiple sponsors to split the cost. Our current estimate is $150K for Go, $120K for C/C++, and $100K for PHP, and roughly six months per language. (Fun fact: Now try to estimate how much AppThreat has spent so far to bring the current languages absolutely free for everyone). There is really no alternative to cash.

Now you know why next-generation supply chain companies raise tens to hundreds of millions of dollars from VCs.

[sushiMix]

@prabhu
I found the issue:
It was falling back in manual go mod parsing which does not seem to handle the component naming.
I had an issue with go list -deps : error obtaining VCS status: exit status 128
Use -buildvcs=false to disable VCS stamping.
Adding GOFLAGS=-buildvcs=false to the env var solved the issue (i'm using the docker image).