给 selfhosted 做保全太累了，我想回 SaaS
本文亦有其他语言版本： 中文（这儿！） English
（注：话是这么说，但其实还Payton尚未回。）
各位运维同志们，大家好呀！托PHP最近爆出的漏洞的福，不知道有多少开发和运维同志最近正忙着更新infra，甚至（被要求）把公司项目升上PHP 8。
我这儿也有一堆PHP的自建服务（幸好大多是自用，下线一会儿不打紧），大多跑在Docker的容器里。PHP发布修复的时候，Docker Hub这边又是PHP发fix之后才发image，又是发完image之后不能用的，最后我在第二天才完成修复。有的项目是我需要更新写的Dockerfile里的base image；有的项目自己发了新image，我可以直接用；还有的就直接更新apt包（Sury源的更新很及时！快说：谢谢Sury）。
终于更新完PHP的事儿了。但还没完，Node.js又出安全更新了！吭哧吭哧地修完更新完，发现LiteLLM又被投毒了（今年第二次了），又连夜查密钥换密钥！
放弃了，不干啦！当个运维累死啦！我要回SaaS！
运维们怎么了？
还问我怎么了？你家LLM肯定知道！或者我也可以帮你进行一个问：LLM让漏洞发现更快，也意味着运维得更频繁地筛选告警、判断影响、追踪补丁，再把更新安全地部署出去。对自托管服务来说，漏洞修复只是起点：还得等上游发包、确认镜像可用，最后挨个更新；发现越快，留给人手忙脚乱的时间就越少。[1]
安全团队和开源项目维护者已经忙得团团转！放眼望去：
- Linus五月份的时候就吐槽，security邮件列表已经理不清楚了；大家都在同时用LLM找出同样的bug。
- 2026年的CVE发布量，已经远远超过2025啦！光第二季度就有两万多个，要知道2025年同期可是只有一万多，几乎翻了个倍。CVE编号也已经排到十万（六位数喔！）以上了（上文Node.js安全更新里的
Node2ShellHTTP2Shell就是111497。）[2]。虽然数量多不代表问题严重，但就光是决定漏洞的优先级这件事，也成了一个大问题。 - 为了节省维护者精力，kernel文档里甚至定制了一段面向LLM的报告内容要求。
- 除了大量真实的漏洞报告，当然也少不了AI slop！curl因为大量涌入的AI slop把bug bounty给停了，免得troll们为了奖金发虚假报告。
防守方固然也可以利用LLM快速修复漏洞，但就像CS里警察也要保证人质安全一样，他们也要保证服务不中断呀！现在的一个大问题就是漏洞发现速度太快，很多的开源项目里，维护人员已经不够了。用LLM生成无效漏洞报告的troll，则是给本就压力陡增的维护人员又添了一把火。
在LLM的分析和爬虫的扫描之下，互联网已然变成了一片更加、更加黑暗的森林，那怎么办？或许只能藏起来啦。
我要，钻进VPN内网！
其实在LLM发展起来以前，大家就已经相当理解互联网的黑暗森林理论了。从把网站放到Cloudflare等CDN后面，到利用Cloudflare Tunnel让服务器不再需要开放入站端口，都是应对黑暗森林的好方法。在Tailscale等内网方案相当普及的现在，则可以更进一步，把不需要公共访问的服务整个放进VPN。
我的Nextcloud也好，我的Phorge也好，它们放在Tailscale内网就没问题，甚至把它们的出站都切断掉也可以。它们又不需要外部访问，对吧！即使它们都是PHP语言写的软件，也没有别人访问到它们；如果切断它们的出站，甚至它们也访问不到别人，那就少了一大半儿顾虑。
嘛，无论Tailscale还是Cloudflare Zero Trust，归根结底还是把内网架构和信任交给了别人。如果担心它们也有反水或者被攻破的一天，自己配置WireGuard网络或者Headscale，也是个能进一步收窄风险面的做法。
但大家都要用的公共服务怎么办？总不能强制所有用户都要通过VPN连接到内网才能用吧！（MDM：※不是不可能！？）
公共服务，或许还是上SaaS比较轻松
用SaaS吧，确实是会让互联网更中心化，也确实是把自己数据的控制权交出去，还有人觉得是浪费钱。但是，在2026年这个LLM占领高地的世界，我的脑子已经被互联网上的LLM内容搅成一团浆糊了。我，要准时下班！我，要好好睡觉！所以就还是花点儿钱消灾吧。反正我VPS也在云上，转SaaS听起来也没失去太多东西就是了。
关于最近的连环漏洞问题，冯若航老师前两天又写了文重申他的下云观点。我觉得吧，把防火墙配对、把攻击面收窄固然正确，但这是系统安全中最基础的基础。至于air-gap，听起来是有点道理，但实际上能air-gap进去的东西不多。备份数据确实是可以air-gap（也应该要有air-gap的版本），线上数据库可没法air-gap呀。线上数据库air-gap了，我的公共服务就没办法让别人用了！
没办法air-gap的话，放在公网上的self-hosted服务，和云上的SaaS服务要干的是一样的活儿呀[3]：安全维护还是得做吧？更新还是得做吧？有漏洞还是得修吧？备份也得搞吧？确实是不需要担心其它tenant通过Copy Fail逃逸到我这儿，但除了容器逃逸之外，漏洞的类型还有千种万种，而面对它们的只有我一人（不，我不是超级AI运维八千代）。好在我这前面还有一层Cloudflare能搞定WAF规则，不然，如果连CDN都没有配置的话，0day的消息发出来，我除了眼巴巴等着官方发fix再自己升级之外，恐怕只剩下「祈祷自己不被打」和「把服务关了」这两种选择了。
上托管SaaS的好处是什么呢？正经云厂商有人力，有物力，有资讯，还有合同。云厂商有覆盖全时区的on-call engineer能24/7 on-call，我不行；云厂商有成批的人力资源和计算资源可以做review、跑测试，确保fix能用，我不行；云厂商能在各种秘密邮件列表（例如 Kubernetes 的 distributors-announce）提前拿到通知和patch，我不行；云厂商哪怕服务中断了的话，得给用户一个解释，一般也要发RCA详细解释哪里出了问题，另外也要根据SLA发补偿，我可能也做不到。
就这次的PHP事件，Cloudflare就是在PHP公布修复之前就有上WAF规则[4]，至少能mitigate一下。Twitter的大家也奔走相告：Cloudflare上WAF规则了，别忘了开！至于经典PHP系SaaS厂商Automattic的用户就更爽了，Automattic直接把它修了，用户安坐家中什么都不用干。我一个大晚上还要盯着Docker Hub和挨个改Dockerfile的人，和人家怎么比呀！我当然也可以把这些流程自动化，但我只是一个人类，又不是开公司，上哪儿查软件资产数据库去！我手里有的，也就是几个放着Docker Compose文件的仓库罢了。
当然，云厂商，一定要是正经厂商。可能会偶尔草台，但不能草台到像印度CA的eMudhra那样，拿4做私钥 :-)
所以我放弃了……
音乐 PHP。倒是还没 all-in SaaS，但我差不多把PHP摘干净了：
- Nextcloud的CalDAV换成了Rustical（这玩意甚至还能接入Pocket ID做OIDC）。
- 给Private Bin挂了个通知说它可能一年后下线。我估计到时候应该确实会把它关掉。
- 网站统计工具Matomo（本页就有用到）也打算换掉。目前还在评估Plausible。Umami做服务端上报太扭曲了（例如它记用户IP竟然是靠
X-Forwarded-For）。 - 我还有一个Phorge实例（Phabricator的fork），用来做个人票务系统（受delphij启发），但目前还没想好拿它怎么办。Phorge的交互很有意思[6]，所以我从Redmine迁过来了，不过目前也没找到替代品。