I'm not sure I've ever seen a detailed technical writeup of a vulnerability before that started with such clear and concise instructions on the exact steps needed to defend against it at the start of the article before. In particular, making clear the priority of what to patch is excellent. If I'm a user of a product where a bug was found, I'm definitely interested in learning about what the bug was, how it was discovered, and whether I should be worried about other bugs in the future, but the absolute first thing I want is to do whatever I can to make sure I'm not affected by it. Listing what to patch and/or change in code might be more "boring" than the narrative of how the bug was found, and it might spoil the surprise, but I think sometimes we focus so much on the fun of the process of finding the bugs or revel in the cleverness of an attack (and those things are fun!) that we forget that the real point to it is to make our stuff safer. There's plenty of time for fun, but make sure you patch things first!
Also interesting was this recommendation: "Keep using Tailscale!
The speed and quality of Tailscale's response to our report is unlike any vendor interaction I have experienced, and suggests a deep commitment to keeping their customers safe."
Every product has security issues now and then. The real challeng is building robust processes remediate them (and to ensure that class of issue doesn't reoccur). The teams that deliver, by being transparent and fixing their stuff in a timely way, get my business.
I call this the "Vulnerability view" instead of a "Remediation view" and its something I feel a lot of Security people and tooling gets wrong when sharing information with those outside our bubble.
It is dead easy to export a vulnerability scan or penetration test report and throw it at the developers, but you will get much better outcomes and better rapport if you tell them what they need to do (i.e. patch to version x.x.x) versus telling them what is wrong ("the sky is falling!").
