-
My own experience is that the Go stdlib has resulted in worse security than, for example, rust.
The reason for that is that both the Rust and Go stdlib have a stability promise, so anything built into them can't change if it's insecure.
For example, the 'tar' package in go by default returns unsanitized paths, and has led to a bunch of CVEs: https://github.com/golang/go/issues/55356
The go stdlib can't change the tar package to make it secure by default because it would be a breaking change to do so.
Rust, on the other hand, has a tar package outside of the stdlib, and so it can evolve to be more secure and over time find a better interface.
We've seen that with various other packages, where the Go stdlib HTTP implementation defaults to no timeouts, and thus makes it easy to DoS yourself. Ditto for DNS. The tls package has similar backwards compatibility warts that make it less secure by default.
Forcing backwards compatibility with network protocols by baking them into the stdlib has largely not been a security win in my experience.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Don’t forget about capslock: https://github.com/google/capslock
Assess your 3P modules for dangerous capabilities
-
I'd point out that one advantage Go has over Rust in terms of security are the coverage of standard libraries. Go has great support for HTTP clients/servers, cryptography primitives, SSH, SQL, JSON, secure RNG, etc. all in officially maintained standard libraries. The Rust ecosystem has some standards here but the most widely used HTTP client, just as an example, is mostly maintained by one guy[1]. I think that adds considerable security risk vs Go's net/http.
1. https://github.com/hyperium/hyper/graphs/contributors
-
