给 selfhosted 做保全太累了，我想回 SaaS/PaaS

各位运维同志们，大家好呀！托PHP最近爆出的漏洞的福，不知道有多少开发和运维同志最近正忙着更新infra，甚至（被要求）把公司项目升上PHP 7。

我这儿也有一堆PHP的自建服务（幸好大多是自用，下线一会儿不打紧），大多跑在Docker的容器里。PHP发布修复的时候，Docker Hub这边又是PHP发fix之后才发image，又是发完image之后不能用的，最后我在第二天才完成修复。有的项目是我需要更新写的Dockerfile里的base image；有的项目自己发了新image，我可以直接用；还有的就直接更新apt包（Sury源的更新很及时！快说：谢谢Sury）。

终于更新完PHP的事儿了。但还没完，Node.js又出安全更新了！吭哧吭哧地修完更新完，发现LiteLLM又被投毒了（今年第二次了），又连夜查密钥换密钥！

放弃了，不干啦！当个运维累死啦！我要回SaaS/PaaS！

运维们怎么了？

还问我怎么了？问你的LLM去！或者我帮你问LLM：LLM让漏洞发现更快，也意味着运维得更频繁地筛选告警、判断影响、追踪补丁，再把更新安全地部署出去。对自托管服务来说，漏洞修复只是起点：还得等上游发包、确认镜像可用，最后挨个更新；发现越快，留给人手忙脚乱的时间就越少。

安全团队和开源项目维护者已经忙得团团转！放眼望去：

• Linus五月份的时候就吐槽，security邮件列表已经理不清楚了；大家都在同时用LLM找出同样的bug。
• 今年的CVE编号在秋天就排到十万（六位数喔！）以上了（上文Node.js安全更新里的Node2Shell HTTP2Shell就是111497）；2025年全年的CVE才49972个。^[1]
• 为了节省维护者精力，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也好，我的DokuWiki也好，它们放在Tailscale内网就没问题，甚至把它们的出站都切断掉也可以。它们又不需要外部访问，对吧！即使它们都是PHP语言写的软件。没有别人访问到它们；如果切断它们的出站，甚至它们也访问不到别人，那就少了一大半儿顾虑。

嘛，无论Tailscale还是Cloudflare Zero Trust，归根结底还是把内网架构和信任交给了别人。如果担心它们也有反水或者被攻破的一天，自己配置WireGuard网络或者Headscale，也是个能进一步收窄风险面的做法。

但大家都要用的公共服务怎么办？总不能强制所有用户都要通过VPN连接到内网才能用吧！（MDM：※不是不可能！？）

公共服务，或许还是上SaaS/PaaS比较轻松

关于最近的连环漏洞问题，冯若航老师前两天又写了文重申下云观点。我觉得吧，把防火墙配对、把攻击面收窄固然正确，但这是系统安全中最基础的基础。至于air-gap，听起来是有点道理，但实际上能air-gap进去的东西不多。备份数据确实是可以air-gap（也应该要有air-gap的版本），线上数据库可没法air-gap呀。线上数据库air-gap了，我的公共服务就没办法让别人用了！

没办法air-gap的话，放在公网上的self-hosted服务，和云上的SaaS/PaaS服务要面对的是一样的工作^[2]：安全维护还是得做吧？更新还是得做吧？有漏洞还是得修吧？备份也得搞吧？确实是不需要担心其它tenant通过Copy Fail逃逸到我这儿，但除了容器逃逸之外，漏洞的类型还有千种万种，而面对它们的只有我一人（不，我不是超级AI运维八千代）。好在我这前面还有一层Cloudflare能搞定WAF规则，不然，如果连CDN都没有配置的话，0day的消息发出来，我除了眼巴巴等着官方发fix再自己升级之外，恐怕只剩下「祈祷自己不被打」和「把服务关了」这两种选择了。

上托管SaaS/PaaS的好处是什么呢？云厂商有人力，有物力，有资讯，还有合同。云厂商有覆盖全时区的on-call engineer能24/7 on-call，我不行；云厂商有成批的人力资源和计算资源可以做review、跑测试，确保fix能用，我不行；云厂商能在各种秘密邮件列表（例如 Kubernetes 的 distributors-announce）提前拿到通知和patch，我不行；云厂商哪怕服务中断了的话，得给用户一个解释，发RCA详细解释哪里出了问题，另外也要根据SLA发补偿，我可能也做不到。

就这次的PHP事件，Cloudflare就是在PHP公布修复之前就有上WAF规则^[3]，至少能mitigate一下。Twitter的大家也奔走相告：Cloudflare上WAF规则了，别忘了开！至于经典PHP系SaaS厂商Automattic的用户就更爽了，Automattic直接把它修了，用户安坐家中什么都不用干。我一个大晚上还要盯着Docker Hub和挨个改Dockerfile的人，和人家怎么比呀！

当然，云厂商，一定要是正经厂商。可能会偶尔草台，但不能草台到像印度CA的eMudhra那样，拿4做私钥 :-)