This right here is why Go's 'statically link everything' is going to become a big problem in the long run when old servers are running that software and no one has the source code anymore.
At least the ones I meet tend to take that approach...
Same with containers. Statistics clearly show the security impact.
Cautiously posting that link, because I'm not against vendoring. You just need a process around keeping your dependencies up to date / refreshed automatically. The ability to vendor is one thing, how you use it is another.
I agree with your statement, but what I usually see in real life is that once dependencies are vendored in they never change.
That's what dynamic linking and Linux distributions are for.
The time to write a patch and deliver it to running systems goes down to days or, more often, hours.
If only there was some kind of "open" source, so that it could be included along with the binaries. :P
I think the bigger problem is all the bootstrapping issues where you need "living" build systems to build more build systems etc.
There are lot's of old projects out there relying on some ancient VS2003 installation. Same will happen with modern languages in a decade - code goes stale, and it get's more and more difficult to pull down the versions of software it was originally built with.
It would be interesting to see e.g. a Go executable format that ships with the source, build tools and documentation that would compile to the current platform on demand. Should be doable in a Docker image at least.
They're either going to miss things or have false positives. They sure improve the situation, but you can't find all of the issues automatically.
We can! It's one thing to know that there's no major technical obstacle to having a security-oriented static analysis suite for your language of choice. It's quite another for one to actually have already been written.
The primary wrinkle tends to be around justifying the cost of building one. For companies that use small languages, that means a non-trivial cost in engineer time just to get a research-grade scanner. For companies whose products are security scanners, it means waiting until there's a commercial market for supporting a language.
This is a problem I've been struggling with. I sympathize a great deal with developers who want to use the newest, most interesting, and above all most productive tools available to them. This stacks up awkwardly against the relatively immature tooling ecosystem common in more cutting-edge languages with smaller communities and less corporate support.
Also, the Go community tends to frown at adding superfluous dependencies - this is a statement I got while looking for web API frameworks. Said frameworks are often very compact as well, a thin wrapper around Go's own APIs.
I've also worked on a project which had to be future-proofed solidly; all documentation for all dependencies had to be included with the source code.
TL;DR it's down to the developer's approach.