AI编程加速创新，但存在安全风险。需结合STRIDE威胁模型与OWASP LLM十大风险清单，进行人工审查，并利用AI工具辅助安全防护。强调知识、勤勉及持续可追溯性，确保AI时代编码安全。
译自：Securing the Vibe: Reducing the Risk of AI-Generated Code
作者：Crystal Morin
氛围编程帮助人们快速将想法变为现实。它让他们在灵感来袭时，尤其是在不知从何开始时，有勇气去创造。对于开发者来说，在几天内将一个概念从第一行代码转化为一个成熟的生产应用程序的能力是强大的。但在这股将想法付诸实现的冲动中，安全性可能会被忽略。
之前，我探讨了为什么AI生成的代码本质上是不安全的，以及将其纳入项目如何导致一系列安全问题。我最大的体会是，编写拙劣且脆弱的代码在推向生产环境之前需要人工审查和纠正。
有了这种理解，组织或个人如何在使用AI生成的代码时，系统地识别和缓解安全风险，从而避免导致数据泄露呢？通过应用像 STRIDE 这样的威胁模型，以及像 OWASP LLM 应用程序十大风险 这样的清单，氛围编程者、开发者和维护者可以在不牺牲安全性的前提下，继续享受AI生成代码带来的好处。
我将其比作《星际迷航：下一代》。在其中一集里，企业号的自动驾驶系统无法穿越一片特别拥挤的小行星带。Captain Picard 被迫手动控制，以拯救飞船和船员。AI生成的代码就像我们的自动驾驶系统。它加速了进度，但当安全风暴来袭时，人类必须掌舵。
通过威胁视角审查AI生成的代码
STRIDE 威胁模型由微软开发，代表欺骗（Spoofing）、篡改（Tampering）、抵赖（Repudiation）、信息泄露（Information Disclosure）和拒绝服务（Denial of Service），是一个用于主动识别潜在安全威胁的网络安全框架。它提供了一个结构化的指南，用于评估和映射AI生成代码特有的威胁，其中一些我在下面进行了概述：
- 欺骗 (Spoofing)
- AI生成的代码可能以被盗用或虚假（欺骗性）身份提交，这使得归属和问责变得困难。
- AI生成的代码中可能存在弱验证逻辑或完全缺失，例如 Jack Dorsey 的 Bitchat。
- 篡改 (Tampering)
- AI生成的代码可能引入不安全的默认配置。
- AI生成的代码可能引入不安全的初始访问向量，供攻击者利用，例如不知情的贡献者无意中放置的错误配置。
- 抵赖 (Repudiation)
- 代码溯源或代码签名缺失会造成问责空白。例如，谁对AI生成的代码引入的缺陷负责？
- 信息泄露 (Information disclosure)
- AI生成的代码可能无意中将提示或数据集中的密钥、API或凭据嵌入到其输出中，从而泄露敏感信息。
- 拒绝服务 (Denial of service)
- 过长的代码贡献或过多的贡献可能会使维护者不堪重负，本质上造成“审查DoS”（拒绝服务）。
- 过长的代码也可能超出代码审查工具或IDE的上下文窗口，导致风险在审查过程中被遗漏。
- 权限提升 (Elevation of privilege)
- 与缺乏身份验证类似，AI生成的代码通常会忽略适当的授权检查，从而允许攻击者在极少的防护措施下提升权限。
- AI生成的代码中的逻辑缺陷可能使攻击者在应用程序中提升权限。
通过将安全问题映射到实际编码场景，STRIDE 可以在使用AI生成代码时，帮助用户采取明智和实用的防御措施。
知识就是力量，勤勉是关键
OWASP GenAI 安全项目为基于LLM的系统提供了 LLM和GenAI十大风险 清单。然而，许多风险直接映射到与AI生成的代码贡献相关的问题。
以下是一些受OWASP LLM十大风险启发，AI生成代码输出的预期风险：
- 注入缺陷: AI生成的代码可能包含未解决的SQL、命令或模板注入漏洞或错误配置。正如提示注入是对不受信任或恶意提示的武器化一样，不安全的代码在合并到现有软件中时也可以被武器化。
- 缺乏输入验证: AI生成的代码通常会选择阻力最小的路径，未能验证或清理它可能会增加攻击面，并导致无意的敏感信息泄露。
- 硬编码的秘密: AI生成的代码可能不会清理API密钥、密码或令牌，从而使敏感信息暴露。
- 糟糕的错误处理: AI生成的代码可能包含未被识别的错误（静默失败），或者向用户暴露调试信息，而不是记录它，这可能对攻击者有利。
- 不安全的默认设置: 禁用SSL检查或忽略错误处理可能会演变为软件供应链漏洞。
- 不安全的依赖项: AI生成的代码可能包含不安全或恶意的库和/或包，这反过来会扩大攻击面。
- 未经批准的组件: AI生成的代码可能引入未经验证的第三方项目或连接。类似于添加不安全的依赖项，这可能会引入漏洞并增加供应链攻击的风险。
- 代码溯源: 未经审查的AI生成的代码合并到项目中可能是一个被投毒的提交，类似于投毒训练数据。
- 权限过高的代码: AI生成的代码可能会忽视最小权限原则并建立不安全的默认设置，导致糟糕的Kubernetes和云配置或不充分的身份和访问管理角色，这可能导致应用程序中存在过多的权限。
- 复杂的代码: AI生成的代码可能对人类来说过于冗长、混乱和难以阅读，使得审查变得困难，并增加应用程序或项目被破坏或污染的可能性。这在一定程度上是影响安全态势的人为过程风险。
- 错误信息: AI生成的代码可能使用过时的实践或不准确地编写代码注释，这可能会混淆审查者并导致风险在其他方面被忽略。
- 审查过载: AI生成的代码导致的贡献增加和过多的审查周期，会导致维护者倦怠。这是另一个影响安全的人为风险。
将此清单作为代码审查的辅助工具，可以帮助开发者捕获最常见和最危险的AI生成代码故障。
AI时代仍需人工干预
保护你的氛围编程应用程序就像跳探戈：它节奏快，需要精准和控制。它要求速度和安全之间的平衡，并从你审查和维护代码的方式开始。在构思、创建或初步审查阶段尽早应用威胁建模，例如 STRIDE，而不是在代码发布之后。目标是在风险演变为漏洞之前将其暴露出来。然而，没有必要将威胁建模变成一个复杂的周期，因为即使是快速检查也能发现明显的风险。
除了威胁建模之外，你还可以通过将依赖扫描器和CI/CD管道安全检查嵌入到你的工作流程中，并通过预提交钩子阻止硬编码的秘密，从而实现安全防护的自动化。
此外，在任何新代码投入生产之前，你应该使用AI来审查AI。尽管这听起来可能有些讽刺，但AI驱动的linter或代码审查工具可以识别常见的AI编码错误，特别是在与传统的静态分析工具和代码扫描器结合使用时。然而，即使自动化扫描完成，人类也必须作为最终的把关者，做出明智的判断并提供最终批准。
最难接受的一点是：即使代码经过审查、批准和提交，安全性也并未停止。你必须通过尽可能为AI辅助的贡献维护元数据来确保可追溯性和溯源性，以支持未来的审计。包括清晰的注释，注明哪些是由AI编写的，使用了哪些模型以及代码的生成时间。
最后，进行讨论。没有意识，这一切都无法奏效。新编码员可能缺乏正式的安全培训，经验丰富的开发者应该倡导安全的AI代码教育。突出氛围编程的价值以及它可能存在的不足至关重要。就像生活中的大多数事情一样，知识就是力量。
确保编码新时代的安全
AI不会消失。在几天内从想法快速转向运行代码的能力是变革性的。但如果没有结构化的审查、威胁建模和安全防护，氛围编程既可以加速创新，也同样容易加速安全漏洞。
我的座右铭是：“使用工具；信任人类。”通过使用 STRIDE 和 OWASP 等安全框架和清单，并调整我们的审查实践以满足不断变化的需求，我们可以确保AI驱动的编码仍然是创造力的加速器，而不是安全的负担。
