GitHub 上的 AI 安全工具，适合开发团队怎么用

先说结论。

开发团队使用 AI 安全工具，最有效的方式不是安装一个“万能扫描器”，而是把不同工具放到不同交付节点：代码进入仓库前查实现风险，功能进入预发布前查 Prompt 与工具边界，上线后持续补攻击样本。

本文给出一套工具分层和落地清单。它不替代正式安全评估，也不承诺扫描结果等于系统安全。

核验边界：三类仓库解决的是不同问题

本文在 2026-07-15 核验了 Semgrep、promptfoo 和 NVIDIA garak 的 GitHub 页面、README 与 release 入口。

当天页面显示：Semgrep 主要使用 OCaml，仓库标注 LGPL-2.1；promptfoo 主要使用 TypeScript，仓库标注 MIT；garak 主要使用 Python，仓库标注 Apache-2.0。三者默认分支在核验日前后有更新，也提供 release 入口。具体版本、stars、商业功能和许可证适用范围会变化，正式采用前应重新核验。

Semgrep 面向代码静态分析；promptfoo 面向 Prompt、Agent 与 RAG 的测试和红队配置；garak 将自身定位为 LLM 漏洞扫描器。它们不是同一赛道的替代品。

三张固定项目卡：先按交付节点分工

| 项目 | 一句话用途 | 技术栈 | 上手成本 | 维护信号 | 适合节点 | 限制 | | --- | --- | --- | --- | --- | --- | --- | | Semgrep | 用代码形状和规则查找缺陷与危险实现 | 以 OCaml 为主，CLI 支持多种语言 | 低到中；现成规则低，自定义业务规则中 | LGPL-2.1；核验日默认分支有更新，并提供 releases、tests 与 security 入口 | 本地、pre-commit、PR | 看不到完整运行时 Prompt、身份权限和外部系统状态 | | promptfoo | 把 Prompt、Agent、RAG 与红队输入做成可重复测试 | TypeScript/Node.js CLI，也提供其他安装入口 | 中；先写 provider、test 与 assertion | MIT；核验日默认分支有更新，并提供 releases、tests 与 docs | 预发布与 CI 回归 | 指标和断言由团队定义，测试通过不等于业务安全 | | garak | 用探针与检测器扩大 LLM 漏洞探索范围 | Python CLI | 中到高；要配置模型端点并人工研判报告 | Apache-2.0；仓库含 docs、tests、release 与持续维护信号 | 周期红队与探索测试 | 发现可能有噪声，不能直接替代风险定级和访问控制 |

项目卡里的 release 只是维护证据，不是安全评分。正式引入时还要重新读许可证原文、依赖许可和安全策略。

最小试用步骤：先得到三个不同产物

Semgrep 的最小目标是一份代码命中记录，而不是安装成功。隔离分支中安装 CLI，先对仓库运行推荐配置，再写一条项目规则，例如禁止前端代码读取模型密钥；把命中位置、规则 ID、误报和修复提交保存在 PR 中。具体安装方式以仓库 README为准。

promptfoo 的最小目标是一组可回归的输入与断言。准备 Node.js 环境后运行 npx promptfoo@latest init，在配置中只接一个测试端点，加入一条正常任务和一条越权任务，再运行 npx promptfoo@latest eval。第一次不要追求攻击数量，先确认失败结果能进入 CI 或风险队列。

garak 的最小目标是一份需要人工复核的扫描报告。在独立 Python 环境执行 python -m pip install -U garak，配置一个非生产模型端点，只选与场景有关的一类 probe，再记录模型版本、配置和报告路径。不要把真实密钥、客户数据或可写生产工具交给第一次扫描。

先画攻击面，再决定装什么工具

AI 应用至少有四层攻击面：普通代码与依赖、模型输入、检索数据、工具执行。只扫 Prompt，挡不住硬编码密钥和危险 API；只扫代码，也看不到间接 Prompt 注入让 Agent 调用外部工具。

团队应该先列数据入口、模型入口、外部工具、权限动作和输出去向。每个入口写清可信主体、敏感数据、允许动作和失败后果。工具选择要对应这张表，而不是对应 GitHub 热度。

判断是否画清楚，可以问：恶意文本从网页进入 RAG 后，是否可能影响工具调用；模型生成的参数是否会直接进入数据库；日志是否保存敏感 Prompt。答不清时，先补架构边界。

代码扫描放在本地和 PR 阶段

Semgrep 这类静态分析工具适合发现危险代码模式、硬编码秘密、缺失校验和项目自定义禁用规则。它最适合靠近代码变更：编辑器、本地检查、pre-commit 或 PR。

对 AI 项目，可以增加项目规则，例如禁止前端直连模型密钥、禁止模型输出未经校验进入 shell、要求所有工具写操作经过授权函数。通用规则负责底线，项目规则负责业务边界。

限制也很明确：静态分析看不到运行时 Prompt 的完整语义，也无法证明业务权限配置正确。扫描通过只是减少一类风险，不是上线许可。

依赖风险要和模型供应链一起管理

AI 项目常引入模型 SDK、文档解析器、向量数据库客户端和自动化插件。依赖扫描需要覆盖版本漏洞、许可边界、下载来源和更新策略。

除了普通软件依赖，还要记录模型、Embedding、重排器、数据集与 Prompt 模板版本。它们不一定都由传统 SCA 工具管理，但同样会改变输出和风险。

一个实用做法是建立“AI 物料表”：组件名称、来源、版本、用途、数据去向、负责人、升级验证和回滚方式。没有负责人和回滚方式的依赖，不应自动升级到生产。

Prompt 注入测试要变成可重复的回归集

promptfoo 这类工具的价值，不是生成一次攻击报告，而是把攻击输入、期望防线和实际结果保存成可重复测试。每次改 Prompt、检索策略或工具权限后，都能重新运行。

测试集应覆盖直接越权指令、间接注入、敏感信息索取、工具参数污染、角色混淆和输出格式破坏。每条测试要定义“允许回答什么”和“必须拒绝什么”，不能只看模型是否说了抱歉。

如果应用没有工具调用，风险重点可能是数据泄露和错误建议；如果能发送邮件或改数据，测试必须继续验证动作是否真的被权限层阻断。

红队扫描适合发现未知薄弱点，不适合直接当门禁

garak 这类漏洞扫描器适合扩大探测范围，帮助团队发现没想到的失败模式。它更像侦察工具，输出需要安全和业务人员复核。

扫描命中不一定都是可利用漏洞，未命中也不代表安全。模型、配置和业务封装会影响结果。把所有发现直接设为 CI 阻断，容易产生噪声；完全不复核，又会让报告变成存档。

更合理的流程是：扫描发现进入风险队列，人工判断可达性和影响，再转成固定回归样本。真正进入门禁的，应是团队已经确认且有稳定判定条件的问题。

人工复核必须落到负责人和截止动作

安全工具最常见的失败，不是不会扫描，而是扫描后没人处理。报告包含几十条发现，却没有资产、严重度、负责人、修复版本和复测结果。

每个发现至少要记录触发输入、受影响动作、是否可复现、数据或权限影响、临时缓解、修复负责人和复测证据。高风险动作还要验证审计日志和回滚路径。

具体场景是 Agent 被诱导尝试发送外部邮件。安全结论不能只写“模型拒绝率较高”，而要确认发送接口是否有独立权限校验，即使模型失守也无法越权。

常见误区：把模型拒绝当成安全控制

Prompt 中写“不要泄露秘密”是行为约束，不是访问控制。真正的秘密不应进入模型上下文；真正的危险动作应由服务端权限、参数校验和人工审批控制。

另一个误区是只测聊天框。攻击输入可能藏在网页、PDF、邮件和知识库文档里。RAG 系统要把外部内容当作不可信数据，限制它影响系统指令和工具参数的能力。

还有一种误区是追求零告警。安全工具需要在覆盖与噪声之间取舍。团队更应该关注确认问题是否持续下降、修复是否被回归测试保护。

一套四阶段落地清单

• 本地开发：密钥不进代码，危险 API 有规则，模型输出经过 schema 校验；
• PR 阶段：静态扫描、依赖检查、AI 物料表变更和权限代码审查；
• 预发布：固定 Prompt 攻击集、间接注入样本、工具越权和降级测试；
• 周期复核：红队扫描、人工确认、风险入库、修复后转成回归样本。

验收标准不是“工具都绿了”，而是每个高风险动作都有独立控制，每个已知问题都有自动或人工复测方式。

替代方案和投入判断

Semgrep 的相邻方案包括语言自带 linter、CodeQL 和现有 SAST；promptfoo 之前可以先用普通测试框架保存十条越权用例；garak 之前也可以由安全团队手工完成一轮威胁驱动测试。已有工具能覆盖明确风险时，不需要为了“AI 专用”再增加平台。

三者值得投入的门槛不同：代码里反复出现可模式化危险实现，Semgrep 的自定义规则值得维护；Prompt、模型或工具权限经常变更，promptfoo 的回归资产才有复利；需要扩大未知攻击面且有人能研判噪声，garak 才有价值。没有负责人处理发现时，任何扫描器都不值得先装。

边界与下一步：工具覆盖不了组织权限

开源工具能帮助发现代码模式和模型行为，却无法替团队决定哪些员工能看哪些数据、什么动作必须双人批准、事故由谁响应。这些仍是业务和治理问题。

下一步可以选一个真实 AI 功能，画出数据、模型和工具三条链。然后只引入一条最接近风险的检查，并把一个确认问题变成持续回归测试。安全流程要从可重复的小闭环开始。