6 ms·

(Tailscale CEO) You have posted here multiple times that "none of the code has had a security audit" and that the SOC2 audit "is not the same thing." It's true

(Tailscale CEO) You have posted here multiple times that "none of the code has had a security audit" and that the SOC2 audit "is not the same thing." 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 https://tailscale.com/security-bulletins

traceroute66 2mo ago
The majority of your security bulletins are as the result of third-party reports to you. 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 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 !
- apenwarr 2mo ago
  (Tailscale CEO) I don't know what to tell you. The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. They don't need bulletins. Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.
  - traceroute66 2mo ago
    But why should insecure argument handling bugs (as per your recent SSH bulletin) be found after release ? Those are an ancient class of bugs that should be picked up by any competent security review.
    - apenwarr 2mo ago
      Is your theory that "any competent security review" will find every security hole in a product? Because that sure would be great if it were true. Unfortunately it does not match my experience.
      - traceroute66 2mo ago
        Every security hole ? No, of course not. 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.
        TheTaytay 2mo ago
        It appears that you have a major bone to pick with Tailscale and direct replies to your concerns do not seem to matter. They have a good security track record and are extremely widely deployed. I don’t see the evidence for your assertions that it is bloated and insecure.
        raggi 2mo ago
        fwiw, we have been working on increasing modularity options in the client and a substantial volume of features can now be built out of the clients, see https://github.com/tailscale/tailscale/tree/main/feature https://github.com/tailscale/tailscale/tree/main/feature for details. 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.
      - inigyou 2mo ago
  - gowld 2mo ago
    > The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. Either you didn't mean what you wrote, or you are saying that you never find problems internally after release.
r0b05 2mo ago
That link is a list of incidents while the parent comment is referring to security audits of the code.
maxgashkov 2mo ago
<s>Read</s> Skimmed the report (and cheers for not gating it behind request-to-obtain) and I'm a bit surprised to not see any mentions of pentests which I'd expect given the large surface you host. What gives?
- wbl 2mo ago
  Because that's in the SOC2.
- maxgashkov 2mo ago
  (it seems they list it under the contract with Latacora, disregard)

traceroute66 2mo ago

The majority of your security bulletins are as the result of third-party reports to you. 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 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 !

apenwarr 2mo ago
(Tailscale CEO) I don't know what to tell you. The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. They don't need bulletins. Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.
- traceroute66 2mo ago
  But why should insecure argument handling bugs (as per your recent SSH bulletin) be found after release ? Those are an ancient class of bugs that should be picked up by any competent security review.
  - apenwarr 2mo ago
    Is your theory that "any competent security review" will find every security hole in a product? Because that sure would be great if it were true. Unfortunately it does not match my experience.
    - traceroute66 2mo ago
      Every security hole ? No, of course not. 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.
      - TheTaytay 2mo ago
        It appears that you have a major bone to pick with Tailscale and direct replies to your concerns do not seem to matter. They have a good security track record and are extremely widely deployed. I don’t see the evidence for your assertions that it is bloated and insecure.
      - raggi 2mo ago
        fwiw, we have been working on increasing modularity options in the client and a substantial volume of features can now be built out of the clients, see https://github.com/tailscale/tailscale/tree/main/feature https://github.com/tailscale/tailscale/tree/main/feature for details. 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.
    - inigyou 2mo ago
- gowld 2mo ago
  > The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. Either you didn't mean what you wrote, or you are saying that you never find problems internally after release.

r0b05 2mo ago

That link is a list of incidents while the parent comment is referring to security audits of the code.

maxgashkov 2mo ago

<s>Read</s> Skimmed the report (and cheers for not gating it behind request-to-obtain) and I'm a bit surprised to not see any mentions of pentests which I'd expect given the large surface you host. What gives?

wbl 2mo ago
Because that's in the SOC2.
maxgashkov 2mo ago
(it seems they list it under the contract with Latacora, disregard)