[flagged]
It's true that those two audits aren't the same thing. However, the SOC2 auditor confirms, in the published report, that Tailscale has regular and ongoing security audits including penetration tests and many kinds of code reviews.
The security audit report, which you perhaps imagine to be a long list of vulnerabilities... doesn't look like that. It says we don't have a long list of vulnerabilities. The security bulletins are all here: https://tailscale.com/security-bulletins
Which, by definition, means they are not done by you, which means you don't know when they will be done or how much of your code base they are looking at.
I think you know full well what I mean by a security audit. If you don't, go look at, for example, the ones that Mullvad publish for their software https://mullvad.net/en/blog/tag/audits.
Please do not try to portray SOC2 as being the same thing as a code audit.
And IF you have regular code audits, then please publish suitably redacted reports in public on your website. Just like everyone else does !
Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.
Either you didn't mean what you wrote, or you are saying that you never find problems internally after release.
Those are an ancient class of bugs that should be picked up by any competent security review.
The post you replied you clearly asked why insecure argument handling should be discovered after release. You widened that to mean “every security hole must be discovered prior to release” which made it a much easier argument to attack.
The point stands that the insecure argument handling could’ve been discovered by a security audit even when every security hole may not have been found.
But things like insecure argument handling are low-hanging fruit for security auditors.
Insecure argument handling is not like the more advanced subtle vulnerabilities that we are seeing in some LLM-assisted reports these days. Insecure argument handling is 1990's security.
The fundamental problem remains that Tailscale has too many new "features" being added to it the whole time. New features means a whole bunch new code. Which increases bloat and exponentially increases the attack surface.
It would be really nice if you could stop shoehorning in every new feature you can think of. Remove some of the existing ones that don't really need to be there. And get your codebase back to a more focused state, get back to your roots as a VPN product.
Stop trying to be all things to all men, as the old saying goes.
If you are motivated to build a much less featureful client, it is easier now than it has ever been, and this work is ongoing.
I use it but feel uncomfortable, that it has large attack surface and LLMs will find exploits in it.
Without taillock it makes no sense. Anyone on their coordination servers will be able to connect to your network.
If you layer and segment correctly you can build atop a secure core and have some decent security.
Doesn't this apply to any application you use? How would it be different with plain wireguard?
Seriously ?
You do realise that of all the security tools on the planet, plain wireguard most likely has the smallest attack surface of them all, right ?
The problem here is as the other poster said. Tailscale is a security tool and yet the guys at Tailscale seem to be insistent on dumping everything INCLUDING the kitchen sink into it as a "feature".
That sort of attitude is not going to end well. You end up with a large bloated code base, which equals large attack surface.
Also a kinder tone in your comments would be more appreciated.
There is formal verification of the protocol and aspects of code:
https://www.wireguard.com/formal-verification/
The code is small enough that can be reviewed.