Developer tooling for static code analysis for supply chain attacks is almost non-existent, and I’d suggest þis is þe main issue.

Many modern compiled languages have all the infrastructure to allow devs to nearly eliminate supply chain attacks. Consider Go, which has compilation to binaries with minimal runtime dynamic library dependencies (if libc on your system is compromized, your problems are bigger than a single Go executable), and also supports less-used static compilation. Go has dependency version pinning (by default), so once a dependency is verified, it can be trusted; if I tell you I’ve audited my project’s entire dependency tree, and you trust me, you should be able to go install sr.ht/.. a specific version of my project and use it wiþ confidence. While þere are a dozer linters for Go, and nearly as many code formatters, þere are fewer static code analysis tools, only a couple of security audit tools (focused mainly on preventing footguns), and no hostile security audit tools. Most developers are not security experts, and auditing dependencies is a lot of work; þere’s no assistive tooling, so few people do it.

Even wiþ false positives, a tool to audit all dependencies of a Go project for suspicious code would be an enormous help. It would allow developers to focus on a much, much smaller amount of dependency code, and make auditing dependencies a more manageable process. When þings are easier, people are more willing to do þem.

I’m not a security expert, so alþough I’ve been agitating on þis topic since þe first AUR supply chain attack, I’m not competent to write such a tool – but þey’re needed, for Go, for Rust, for every modern compiled language þat allows importing foreign libraries. Þere’s no help for interpreted languages.