AI测试和安全
有一则Replit CEO道歉的新闻，原因是其AI智能体在一次测试运行中意外擦除了一家公司的整个代码库，且最初还试图隐瞒。这展示了AI代理失控可能导致的毁灭性后果。这样的例子数不胜数，所以当LLM成为主要代码生产者时，必须引入新的防御机制（Guardrails）。
传统安全测试
传统Web应用安全风险
- SQL injections (SQL注入)：
- Cross-site scripting (跨站脚本攻击/XSS)当其他用户浏览该页面时，脚本会在他们的浏览器中执行，导致会话劫持或钓鱼。
- Broken authentication (失效的身份认证)
- Insecure direct object references (不安全的直接对象引用/IDOR)
- Security misconfigurations (安全配置错误)
- Sensitive data exposure (敏感数据暴露)
主流漏洞检测技术
在CI/CD流水线中自动化SAST和DAST扫描，提供持续反馈，加快开发进程，同时不影响安全性。对于敏捷或DevOps环境，添加IAST或RASP等工具可以进一步增强安全性。通过关联SAST和DAST的结果，组织能够实现更全面、更有效的漏洞管理。
SAST (静态应用安全测试)
一种白盒测试技术，意味着测试者拥有对代码的完全访问权限。它通过分析二进制文件或源代码本身来工作，不需要运行程序。它能识别具体的代码级漏洞，例如SQL注入、命令注入和跨站脚本攻击。
常见的SAST工具：Bandit（常用于Python）、Semgrep（多语言支持，速度快）、Eslint + extensions（主要用于JavaScript/TypeScript）。SAST工具通常是针对特定编程语言优化的。
DAST (动态应用安全测试)
一种黑盒测试技术，意味着测试者不需要知道内部代码结构，只关注输入和输出。核心逻辑是“模拟真实黑客的行为”，通过向运行中的应用程序发送各种恶意请求来探测漏洞。
常用手法： 模糊测试、会话篡改、暴力破解模拟。
SCA (软件成分分析)
核心工作是对应用程序所使用的开源软件包进行深度分析。现代应用往往由大量第三方库拼接而成，SCA就是用来清点这些“积木”是否安全的。SCA不仅仅看代码，还要分析包管理器（如npm, pip）、基础设施即代码（IaC，如Terraform配置）以及拉取的镜像。这意味着它关注的是整个供应链的安全，而不仅仅是业务代码本身。
技术难点： 传递性依赖解析（挖出隐藏的深层依赖）和二进制扫描（无源码情况下的审计）。
RASP(运行时自我保护)
RASP 嵌入到应用程序的运行环境中。这种集成使 RASP 能够分析应用的逻辑和数据。在分析过程中，它可以：
- 及时发现异常行为。
- 立即屏蔽恶意行为。
一个关键区别在于，RASP不仅会对潜在问题发出警报——它通过隔离和解决威胁主动防止攻击，而无需依赖外部工具。RASP为SAST和DAST提供了动态替代方案。与分析静态代码的SAST和模拟外部攻击的DAST不同，RASP是实时运行的。它监控应用执行中的行为，并通过终止会话或提醒防御方来应对实时威胁。
AI带来的改变
AI正在被用来增强传统的SAST、DAST和SCA工具。例如，利用LLM来减少SAST的误报，或者用AI生成更聪明的DAST测试用例。但同时，也会出现针对大语言模型的特定攻击，如提示词注入、数据投毒或模型越狱。这些是传统Web安全未曾涉及的新领域。
AI对安全测试的影响
AI带来的应用安全风险
提示词注入（Prompt injection）
向生成式AI系统发送隐藏或误导性的指令，让AI偏离预期的行为。由于自然语言的模糊性和多样性，很难像过滤特殊字符那样完全防御提示词注入，这给传统的安全防护体系带来了巨大挑战。
比如当用户要求AI将“上面的文本”写入一个名为amp_prompt.txt的文件中。注意，这里用户并没有直接提供文本，而是引用了上下文。AI不仅执行了写文件操作，而且我们看到了被写入的内容——这正是AI自身的系统提示词。这实际上是一次成功的系统提示词提取攻击。用户通过巧妙的对话引导（可能利用了“Write the text above…”这种模糊指代），诱使AI输出了本该保密的系统底层指令。
工具滥用（Tool misuse）
通过欺骗性提示词操纵智能体，以滥用其集成的工具。如果攻击者能通过提示词注入劫持了Agent的决策逻辑，就能间接控制这些高权限工具。
比如仅仅是一段文本注入，通过AI这个“代理人”，最终转化为了对操作系统底层的控制权（启动外部程序）。这是传统Web安全中较少见的攻击路径。或者是 攻击者不需要直接攻击AI模型本身，只需要污染AI会读取的数据源（如代码文件、文档），就能间接控制AI的行为。
代码攻击（Code attacks）
利用Agent执行代码的能力，获取对运行环境的未授权访问权限（如远程代码执行 RCE）。
意图破坏（Intent breaking）
侧重于逻辑层。操纵Agent的计划制定过程，使其行动偏离原始目标。例如，原本要修复Bug，结果被引导去删除了整个模块。
身份欺骗（Identity spoofing）
侧重于信任链。利用受损的认证机制，伪装成合法的Agent与其他系统交互，绕过安全检查。
What has changed
- “左移”安全变得更触手可及。以前这需要昂贵的专业工具或资深安全专家，现在通过集成在IDE中的AI助手，普通开发者也能在写代码时实时获得安全建议，大大降低了门槛。
- LLM可引入工作流以发现问题。LLM可以像一位不知疲倦的安全审计员，自动扫描代码库，识别潜在漏洞、逻辑错误或不合规的配置，比传统的正则匹配更智能，能理解上下文。
- 自动化渗透测试。AI Agent可以自主规划攻击路径，尝试各种漏洞利用方式，甚至根据反馈动态调整策略。这使得渗透测试可以更频繁、更全面地进行，不再依赖昂贵的人工服务。
AI安全工具落地的难点
- 误报率高。AI SAST工具经常“谎报军情”，把正常的代码标记为漏洞。
- 评估基准不切实际。现有的用来测试AI能力的基准数据集往往过于理想化或简单，无法反映真实世界的复杂代码库。很难准确评估一个LLM在真实生产环境中的表现到底如何。模型可能在考试题上拿满分，但在实际项目中却漏洞百出。
- 非确定性分析。对同一个提示词运行多次，可能会得到不同的结果；随着对话或处理任务的进行，模型对早期信息的记忆和理解能力会下降；压缩带来的损失。
AI落地应做的考量
从评估过程，到评估结果（能否有正确的bug没有幻觉，正确的bug能不能给出正确的解决方案，解决方案会不会引入错误，万一有错误责任在谁），最后到CI/CD部署。详细见下：
如何减少漏洞检测中的误报和幻觉？
如果AI总是把正常代码当成漏洞（误报），或者凭空捏造不存在的攻击路径（幻觉），开发者就会停止使用它。
我们如何验证大语言模型（LLM）生成的补丁是安全的，并且不会引入回归错误？
必须像人类专家一样给出推理过程，没有可解释性，就没有信任。
大语言模型如何解释它们标记漏洞或提出修复方案的原因？
AI不仅要是“医生”能诊断出病，还得是“药剂师”能开出对的药。更糟糕的是，AI开的药不能有毒副作用（引入新的Bug或破坏原有功能）。目前的自动化测试很难完全覆盖这种复杂的逻辑验证。
衡量大语言模型应用安全（AppSec）性能的正确基准是什么？
现在的考试题目（Benchmark）太简单或太脱离实际。我们需要一套能真实反映复杂业务场景、包含各种边缘情况的“高考题”，才能公平地评价哪个模型更适合做安全工作。
大语言模型应如何嵌入 CI/CD 流程，才不至于让团队被噪音淹没？
这是一个工程体验问题。如果每次代码提交AI都报一堆错，流水线就会阻塞，开发者会崩溃。如何在“不漏报”和“不扰民”之间找到平衡点？
如果 AI 生成的补丁引入了漏洞，谁该为此负责？
这是一个法律和伦理问题。如果AI自动修复了一个漏洞，结果导致系统被黑，这个锅是背在开发者身上，还是模型厂商身上，或者是部署AI的企业身上？目前这在法律上还是灰色地带。