As the article also mentions: instead of checking if your program has a dependency on something that contains vulnerabilities, govulncheck checks if vulnerable code is actually reached. I find that so awesome. (And I know, someone is going to point out that hipster language foo does this too and better — it’s not the norm).
Great tips in here - I was not aware of `go vet` nor `go test -race`.<p>FWIW, while go is not memory safe, I do find that it's much easier to be safe in go than it is in other languages. Its verboseness lends to a very clear understanding of what's happening in any given function. I absolutely hated this at the start, but now ~3 years into maintaining a go codebase, I find it quite nice both for debugging as well as editing old code. I know exactly what each function does, and what the structure of data is in any given context.<p>Another interesting side effect is that AI tools seem to work amazingly well with golang, given how context is often local to the function.
Don’t forget about capslock: <a href="https://github.com/google/capslock">https://github.com/google/capslock</a><p>Assess your 3P modules for dangerous capabilities
Semgrep is another great option to get value out of static analysis checks against both the language and a few common frameworks. It remains a popular choice for security folks writing static detection rules (and contributing them to the commons).<p>You can check the open rules here;
<a href="https://github.com/semgrep/semgrep-rules/tree/develop/go">https://github.com/semgrep/semgrep-rules/tree/develop/go</a>
Does go have a bad security reputation?<p>I get that anything can be insecure and its a constant battle as this article suggests, but i thought it was quite secure and stable generally (say on a par with .net or any other tool you may use to make a web app at least?)
I've been maintaining a Go app for about 9 years now and I can just upgrade the Go version + mod for vulnerabilities (GitHub tells me about them automatically idk) and it works with no changes 99% of the time. I can't overstate how this makes maintaining it very stress-free.<p>My JS apps on the other hand...
Go is nice, but the recent trend of using generics for many stuff is making harder and harder to keep Go code readable imho. See an example here <a href="https://eli.thegreenplace.net/2024/ranging-over-functions-in-go-123/" rel="nofollow">https://eli.thegreenplace.net/2024/ranging-over-functions-in...</a><p>I'm not saying it's hard to read, but it's harder than previous Go code that used little or no generics at all.
Somewhat related, I learned a surprising fact recently: Go is not actually memory safe. In particular because atomicity is only guaranteed for word size values, double word values(interface pointers, slices) can introduce memory unsafety in the presence of concurrency[0].<p>It's one of those things that feels obvious when you see it.<p>0: <a href="https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html" rel="nofollow">https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...</a>
Please note, currently, there are no tools to detect the new footguns created by the new semantics of 3-clause "for;;" loops: <a href="https://github.com/golang/go/issues/66156">https://github.com/golang/go/issues/66156</a><p>> The second step is to keep the Go versions in our projects current. Even though we don’t use the latest and greatest language features, bumping the Go version gives us all security patches for discovered vulnerabilities.<p>It is not always a good strategy to use the latest toolchain version. There are often some fresh bugs in it. From the security perspective, it is better to use the previous version, which is also still being maintained.