安全厂商的AI最佳实践，把RCE标成了安全

刚看到这个新闻，忍不住想多说几句。上周三我在跟联影的老同事聊AI辅助诊断的部署流程，他说现在有个趋势：有些安全厂商开始用AI自动生成“最佳实践”文档，然后直接推给开发者。我当时的反应是，这东西要是没经过临床验证——不对，是没经过安全验证——就敢往外发，胆子不小。结果今天就看到这个案例：Safeguard.sh 发布的Elixir安全指南里，把远程代码执行这类漏洞标注成了“安全”。

这个猫头鹰在草地上低空飞的样子，让我想起某些AI安全产品，—看起来在巡视，实际只盯着自己熟悉的那一小块地，漏掉了更大的威胁。

先说短期的问题。Safeguard.sh 这个案例不是个例。我查了下，单是2024到2025年，Meta的Llama Stack被曝出CVE-2024-50050，vLLM有CVE-2025-30165，都是因为序列化方式不安全导致的RCE。这些漏洞的严重程度，CVSS评分基本都在9.0以上。而Safeguard.sh的指南，据说因为Elixir的Atom限制功能默认开启，就认为RCE在这里“不构成威胁”。问题是，那个限制只禁止创建新Atom，并不阻止运行时创建新函数——这就像给大门加了把锁，但窗户全开着。

我在医疗AI产品里见过类似的问题。模型团队给我看一个肺炎检测模型的准确率，95%以上，看起来很漂亮。但我一问，他们用的测试集全是同一台CT机拍的，换个设备型号，准确率直接掉到82%。这就是典型的“在实验室里看起来安全，进到真实环境就漏了”。做AI安全产品的人，如果真拿着AI生成的“最佳实践”当圣经，那跟用单一设备数据训练出来的模型一样，鲁棒性堪忧。

长期看，这暴露了一个更深层的问题：AI安全产品本身的信任度谁来验证？CISA今年出了新的AI安全指南，要求供应商做技术验证，证明自己的AI产品不会引入新的风险。但问题在于，这些指南本身也是参考了AI生成的内容，交叉验证的链条越来越长，最后谁来做那个“临床验证”的角色？

我在医疗行业待久了，对“慢就是快”这句话体会很深。一个AI诊断模型从论文到进医院，至少要经过多中心试验、伦理审批、注册证申请，周期两三年。不是效率低，是命关天的事，快不得。AI安全产品虽然不直接涉及人命，但一旦出问题，连锁反应可能比医疗AI更严重，想想看，一个生成式AI工具写的安全指南，被上千家开发团队采用，然后因为一个标注错误，导致整个基础设施出现RCE漏洞。

我这边测下来，比较好的做法是：不管AI生成了什么，最终的安全决策必须由人来复核，而且复核的人不能是同一批写代码的人。就像医疗AI，诊断结果必须由放射科医生签字确认，不能由AI自己说了算。Safeguard.sh 这次翻车，很大程度上是因为他们把AI的输出当成了“官方文档”，而官方文档往往不需要再被质疑。

AI安全产品不能只做“看起来对”的事，得经得起真实场景的拷问，就像我们的医疗AI产品，刷榜刷得再高，到了医院也得老老实实过临床验证。

---

本文编译自 Hacker News，原文：Security Vendor's AI Best Practices Labels Critical Elixir RCE Safe
版权归原作者所有，本文为基于公开报道的编译与独立分析。