intel
Detecting vulnerable go packages
@pdxjohnny brought this up elsewhere and I figured I should put it here.
Go wasn't originally designed with dynamic libraries, only static copies of libraries, which means many Go applications could have old libraries compiled in. There's no reason we shouldn't be able to detect those using cve-bin-tool, but we don't currently have any checkers for Go-specific libraries. I don't know the Go ecosystem very well, but this issue is open for folks to suggest "interesting" Go packages (ones that are or were at least somewhat popular and have known vulnerabilities) that might make for useful checkers.
Here are some go packages with vulnerabilities that I've found through a quick search
Just scanned the docker binary (version 20.10.3), a program written in Go. It ijust appears as a normal Linux binary with the inevitable link to Glibc :-) and found 94 CVEs with the linked version of GlibC
Not sure if that helps but one of the advanatges of cve-bin-tool is that it is agnostic to the programming language used to create the binary. If cve-bin-tool starts looking at Go imports, should it then start looking at other langauges e.g. Java?
Yeah, java has the same problem: lots of folk embedding .jar files to avoid api changes. It's definitely a good target.
In theory we can read jar files already (they're just zip files with some metadata, basically) but just like go, I don't think we have any checkers for specific java libraries yet. I believe the one that was attempted (apache-commons, i think?) turned out to be a bust in the signature department. Another one I think might be interesting is jackson-databind (cve details link: https://www.cvedetails.com/vulnerability-list/vendor_id-15866/product_id-42991/Fasterxml-Jackson-databind.html), although I think there might be other jackson-* packages that are also interesting.