mcandre:
Many software projects check third party C/C++ dependency source files directly into version control. This doesn’t integrate particularly well with SCA. As a result, developers end up with latent security vulnerabilities.
govulncheck may happen to register CVE’s for a select few (c)Go projects, but the classic habit of logically vendoring dependencies without a version identifier in package management configuration does not lend govulncheck to reliably obtaining this information from go.mod. The specific reporting gap is the lack of automation to detect which Go projects depend on which native dependencies.
conan audit and Snyk for conan can help. But they represent development environment attack surface creep. And the dev is likely to cobble together a fragile, nonportable shell script to shimmy the conan artifacts into directories found by (c)go.
Long term, would be good for go mod to grow as equally capable of managing and scanning C/C++ packages as Conan.
What if we began isolating first vs. third party C/C++ cgo code into distinct directories? The latter would generate a warning if a corresponding new go.mod cgo entry were missing.
As a precaution, cgo can also generate a warning for native code that is not clearly housed in either of the two new directories. So that we can grandfather in existing cgo projects without sacrificing security.
Third party native code should be placed within the standard vendor/ tree near where third party Go code is kept.
govulncheck and various go components, should integrate with conan and the conan CVE database, to maximize security report accuracy.
The same applies to ECMAScript, JVM, Python, Ruby, etc. projects relying on C/C++ code: Their package managers should do a better job securing native dependencies.
And someone should write a portable, pure Go MIDI driver library so that MIDI projects don’t rely on any native code.
Hello,Tolls by Mail New York
Best Regards,