My vulnerability scanner is better than yours

Professionally, I have to deal with a lot of noise from vulnerability scanners, at work and in my open source maintainer role. I don’t really understand what went wrong in the industry regarding vulnerability scanning. Most solutions I’m exposed to are generic over several languages and tend to report a lot of false positives. False positives in alerting make you numb and over time you will start ignoring reports. Literally the most important thing is to make sure that when you get alerted something is vulnerable in some way, so that you can react.

For the ExternalDNS project, I‘ve been receiving a lot of issues regarding vulnerabilities of the project, sometimes true, sometimes false positives. Back in the day, I built my own automation to have vulnerability reporting based on trivy (before it got hacked) that never really made me happy because it also reported some false things. And last but not least, I regularly got emailed by the vulnerability scanner of the engineering division of Marriott, most likely because they took my email from the commits and decided I was the right person to reach out to (I was not and I never replied).

I needed a solution for ExternalDNS. The only valid solution was govulncheck, which comes with only one problem and a lot of powerful things. Govulncheck as your trusted vulnerability scanner

If you are writing Go software, you can only trust govulncheck. It‘s the best software because it not only scans for vulnerabilities, but it can check if the code is in use in your software. I do not care if I am importing a library that has a vulnerability if I‘m never calling that function and the vulnerability can never be exploited, I‘d rather do work to patch my software only if the risk is somewhat real. Now the issue I encountered with govulncheck is that it requires quite a bit of memory resources to run and I was often running into OOMs for ExternalDNS, because of the relatively high number of dependencies it imports. This happened both on my development VM and in GitHub Actions, which is the CI system that I use to build a report of vulnerabilities that I can check regularly. To fix that, I forked the project and I‘ve been telling myself that I need to bring the change back upstream. Anyhow, now I can run govulncheck and have a perfect list of vulnerabilities for the latest version of ExternalDNS and the latest staging image, so that I always know how the project is actually doing and understand if I have to rush to make a release to protect our user base from actual unwanted risks. It‘s golden.