现代模型生成的代码，语法正确率接近100%。Veracode的2026年报告里把这件事说得很直白："语法问题实际上已经解决了。" 这听起来像个里程碑。但它恰恰是你现在遇到麻烦的原因。同一份报告测试了一百多个模型，发现平均安全通过率只有56%，"与第一份报告中的55%相比几乎没有变化"，大约44%的生成任务会引入一个危险漏洞。 功能正确性和安全性，最终被证明是两个独立的问题。而其中只有一个接近被解决。 这个结果既不是孤例，也不新鲜。2022年IEEE安全与隐私会议上，纽约大学Tandon分校的一个团队让GitHub Copilot跑了89个安全相关场景，生成了1689个程序，发现其中大约40%存在MITRE CWE Top 25中的漏洞。这篇论文后来被选为《Communications of the ACM》的研究亮点。 2024年11月，乔治城大学安全与新兴技术中心评估了五个大语言模型，报告称它们生成的代码片段中，几乎一半含有可被利用的缺陷。 四年时间，四支独立团队，四套方法论，每一次都得出同样的答案。 2023年ACM CCS会议上，斯坦福大学的Neil Perry、Megha Srivastava、Deepak Kumar和Dan Boneh把开发者放进了实验里：47名参与者，五项安全相关的编程任务，三种语言，其中33人配了AI助手，14人没有。使用助手的那组写出的代码安全性明显更低，而且更倾向于相信自己写的代码是安全的。 这是一项小规模研究，但它解释了为什么这个问题不会自我纠正：正常情况下能抓住问题的机制——开发者对自己担心的代码多看一眼——恰恰是工具关掉的那个机制。 上述研究测量的都是应用代码。但基础设施代码是更棘手的情况，因为一个配置错误的安全组永远不会失败：它完全按照写的那样工作，向任何请求的人提供流量，唯一会提出异议的，是读diff的那个人。 没有人能靠阅读来审查这个体量，我也不能。能做的是把规则写下来，写成一种计算机在每次变更时都会检查的形式——这就是Policy as Code的含义。 在一份实操手册中，作者带你构建这套检查：指向一个真实的漏洞仓库，看着最显而易见的版本放过眼前九个违规中的五个，然后修复它。 最终你会知道如何做到这些事： - 针对 terraform show -json 产出的JSON编写Rego策略 - 像测试应用代码一样测试策略，用fixture和覆盖率报告 - 构建一个带退出码契约的命令行闸门，让CI流水线可以信任它 - 在Kubernetes准入阶段用CEL拦截不合规的工作负载 - 让模型写一条策略，再由 opa check 和你自己的测试决定是否保留 - 用同一个策略引擎为AI智能体的工具调用做授权 手册里给出了几个关键术语的直白解释。Policy as Code，是把组织已经达成一致的规则写成一个程序，它接收一个提议的变更并返回一个决定。Rego，是Open Policy Agent评估的查询语言，它是声明式的：一条规则体就是一组必须全部成立的条件。 Plan JSON，是Terraform即将做什么的机器可读描述，由 terraform show -json 生成。策略读的是它，所以你的 .tf 文件永远不会到达策略那里。 准入控制，是Kubernetes API服务器内部的一个点，对象在被存储之前可以在这里被拒绝。CEL，即Common Expression Language，是Kubernetes在API服务器内部原生评估的小型表达式语言，不需要部署webhook。 还有一个词值得单独记住：false clearance，指策略放过了本应失败的一个资源。没有人会注意到这种情况，所以除非你主动去找，它永远不会被测量。 同样的判断发生在三个地方，只有中间那个是Kubernetes特有的。
热门跟贴