1. 为什么要把安全审计做成一个 Skill如果你最近在折腾 Codex、Claude Code 或者 OpenCode 这类 AI 编程助手估计对 Skill 这个词已经不陌生了。我这次想分享的是我自己正在维护的一个项目security-audit-skill简单说就是把安全审计这件事做成一整套可复用的 Agent 技能包。它不是一段提示词也不是一个规则文档而是一个有目录、有脚本、有检查清单的完整工具集让 AI 在写代码、改代码、合并代码的时候顺手就把漏洞审计做了。我做出这个项目的直接原因很现实AI 生成代码的速度已经远超人工审计的速度。一个组员用 AI 半小时就能提交一次几百行的改动安全团队根本来不及逐行看。而且 AI 生成的代码特别容易踩几个固定坑拼 SQL 字符串、把用户输入直接塞进 HTML、忘记做鉴权、把密钥写死在配置文件里。这些问题靠人盯效率太低靠传统的扫描工具又经常误报最好的办法是让 Agent 自己按一套标准流程去查这就是 Skill 最合适的用武之地。这篇文章我会从设计思路、目录结构、规则库建设、实际编码、集成方法到问题排查完整拆一遍 security-audit-skill 的做法。适合正在做 AI 编程助手落地、想给团队加一道自动化安全闸门的人参考。就算你现在还没用过任何一个 Skill只要照着下文的结构走一遍也能自己做出一套能用的安全审计技能包。1.1 AI 写代码的速度快到让人没时间做审计现在的 AI 编程助手已经不是“补全几行代码”的水平了很多场景下它能直接生成整个模块、整套测试、甚至完整的部署配置。代码产出量大之后安全隐患也会同步放大。这个放大不是线性增长而是指数级的因为 AI 生成的代码往往基于训练数据里的“平均写法”而平均写法的安全水平通常不高。我见过最典型的情况是一个后端接口用 AI 生成逻辑上完全正确但参数校验缺失SQL 直接用的 f-string 拼接管理员接口没加角色判断。从功能测试角度看全绿从安全角度看全是洞。问题就在于功能测试能靠自动化跑安全审计这种需要“经验和规则结合”的工作长期处于人工瓶颈。把安全审计做成 Skill本质上是把安全专家的判断规则转译成 Agent 能执行的指令。这样 AI 生成完代码紧接着就能自检一遍。就算不能根除所有漏洞至少把最典型的几类问题拦在合并请求之前这个价值已经非常大了。1.2 Skill 不是提示词而是一套可执行的工作协议可能有人会觉得安全审计这件事直接在对话里说“请你审计一下这个项目”不就行了确实可以但效果很不稳定。提示词是一次性的你说得稍微含糊一点Agent 就把审计做成了简单的代码浏览输出一堆“可能存在风险”这样正确的废话。Skill 的思路完全不一样它把任务拆成一套明确的工作协议什么时候触发、先看哪些文件、按什么顺序查、怎么判断严重级别、最后输出什么格式。这就像你在公司里给新人一份 SOP而不是只交代一句“你注意安全”。有了 SOP不管谁来执行流程都是稳定的有了 Skill不管哪个会话加载审计逻辑也都是稳定的。security-audit-skill 的核心就是一个 SKILL.md 主文件加上规则库、辅助脚本、报告模板。Agent 一旦判断当前任务属于安全审计就会主动加载这套技能包按里面的步骤执行而不是自由发挥。这是它和普通对话式安全审查最本质的区别。1.3 security-audit-skill 要解决的具体问题这个项目要解决的差不多是三件具体的事。第一代码层面的常见漏洞审计。也就是 OWASP 里那类高频问题注入、XSS、SSRF、越权访问、反序列化风险等等。第二密钥和敏感信息泄露。这个真的值得单独拉出来做因为直到今天仍然有大量仓库把密钥传到了远端。第三依赖和供应链风险。AI 生成代码时特别喜欢顺手 import 一堆依赖这些依赖本身有没有漏洞Agent 凭自己的“记忆”是判断不准的但 Skill 里可以规定它去调用专门的扫描命令。需要说明的是这个 Skill 的目标不是替代渗透测试。它更像上线的红绿灯能把最危险的问题先拦下来但真正复杂的业务逻辑漏洞还是需要人来判断。这是我做这个项目从一开始就确定的边界也建议大家不要在工程里神话 AI 审计。2. Skill 的结构设计先想清楚规则再动笔写指令动手写 SKILL.md 之前我建议你先别急着打字先把整个技能包的结构想清楚。一个 Skill 的设计质量决定 Agent 调用它的成功率。如果你只是把几十条安全规则堆在一个文件里Agent 大概率会看得眼花最后只挑几条它熟悉的执行。我设计 security-audit-skill 时遵循了几个原则规则粒度要小、分类要清楚、每一步都要可验证、输出要有固定模板。下面详细拆一下。2.1 目录结构给 Agent 一个过得去的“工作台”一个合格的安全审计 Skill不应该只是一个 Markdown 文件。我的目录结构是下面这样的security-audit-skill/ ├── SKILL.md ├── rules/ │ ├── web_app/ │ │ ├── owasp_top10.md │ │ ├── input_validation.md │ │ └── authz_and_authn.md │ ├── secrets/ │ │ └── hardcoded_credentials.md │ ├── dependencies/ │ │ └── supply_chain.md │ └── infra/ │ ├── docker.md │ └── kubernetes.md ├── scripts/ │ ├── scan_secrets.py │ └── run_audit_tools.sh ├── templates/ │ └── audit_report_template.md └── references/ └── sdl_checklist.mdSKILL.md 是这个技能包的入口负责告诉 Agent 什么时候用、怎么用;rules 目录放规则每类安全风险一个独立文档scripts 目录放辅助脚本用来做确定性扫描比如查密钥、跑依赖漏洞检查;templates 目录放结果模板保证输出稳定。之所以把规则拆成多个文件而不是全塞进 SKILL.md是因为 Agent 在处理长文档的时候会“注意力稀释”靠后的规则经常被忽略。拆成独立文件之后SKILL.md 只需要做轻量级的引导Agent 在执行具体步骤时再去读对应子文档准确率会高不少。2.2 SKILL.md 的 YAML Frontmatter 该怎么写现在不少 Agent 框架都支持通过 YAML Frontmatter 来描述技能包的元信息。这部分看似简单实际很影响体验。我一开始写得太随意导致 Agent 半天不触发后来调了快一周才稳定下来。我建议至少保留这几个字段--- name: security-audit description: 使用结构化流程对代码库进行安全审计覆盖 OWASP Top 10、硬编码密钥、依赖漏洞和云基础设施配置风险。 when_to_use: - 用户要求安全审计、安全审查、漏洞扫描或代码安全检查 - 代码变更涉及 SQL 拼接、文件上传、权限校验、外部请求等敏感逻辑 - 合并请求或 CI 流程中需要自动执行安全评估 version: 1.0.0 ---name 要短方便 Agent 内部引用。description 要准确但别太长重点是让模型能判断什么情况下激活它。when_to_use 是个容易忽略的字段我强烈建议写具体一点。比如这里面的第二项“代码变更涉及 SQL 拼接、文件上传、权限校验”会让 Agent 在开发过程中也能主动触发审计而不是只等用户说“请审计”。Frontmatter 之后是正文。SKILL.md 的正文尽量不要超过 300 行重点写执行步骤、规则文件的引用方式、输出模板的位置。如果正文太长Agent 反而抓不住主干。2.3 工作流设计安全审计任务如何被拆解一个稳定的工作流作用远大于几条分散的规则。我把审计流程分成五个阶段SKILL.md 里也按这个顺序来写。第一阶段收集上下文。Agent 先确认要审计的目标目录读取目录结构、语言类型、依赖清单、CI 配置搞清楚这个项目是什么技术栈因为不同技术栈的检查重点差别很大。第二阶段静态代码走查。按规则库里的清单逐项检查比如搜索 SQL 拼接、dangerouslySetInnerHTML、eval、unserialize 这类危险模式。这里要引导 Agent 记录文件路径和行号不能只说“发现风险”。第三阶段密钥扫描。运行 scripts/scan_secrets.py也人工检查 .env、配置文件和注释里有没有痕迹。第四阶段依赖与供应链检查。调用 osv-scanner、pip-audit、npm audit 等工具把结果归纳成依赖风险清单。第五阶段输出结构化报告。按 templates/audit_report_template.md 生成报告标明风险等级、证据位置、修复建议。我在实际使用中发现这个流程对 Agent 来说非常友好因为它每一步都有明确的终点。不像自由式审计Agent 做一会儿就不知道下一步该干嘛容易戛然而止。3. 审计规则库从 OWASP 到供应链的检查项规则库是 security-audit-skill 的灵魂。我在第 2 节里说过规则要拆成独立文件。这一节重点说说每个规则文件里到底该写什么这些都是我在多个项目里试错之后沉淀下来的高频检查项。3.1 Web 应用安全覆盖 OWASP 高频问题Web 漏洞是审计的重点也是规则文件里最容易写乱的部分。我不建议一上来就追求覆盖 OWASP 的全部条目而是先把出现频率最高的几类写成表格。漏洞类型危险信号推荐修复方向SQL 注入使用 f-string、format、字符串拼接构造 SQL直接执行用户可控的查询改用参数化查询或 ORM 预编译XSSinnerHTML、document.write、v-html、dangerouslySetInnerHTML使用文本渲染必要时做白名单过滤SSRF请求目标 URL 来自用户输入且未校验域名/IP限制协议、域名白名单禁止云元数据地址访问CSRF状态变更接口缺少 CSRF Token引入 Token 校验SameSite Cookie越权访问接口逻辑未校验对象属主仅依赖前端隐藏按钮服务端强制鉴权和资源所有权检查命令注入拼接 shell 命令或使用 eval、exec、os.system使用参数数组方式执行严格白名单校验反序列化漏洞直接反序列化用户输入未限定类型使用安全的数据格式配置序列化过滤器规则文件里除了这张表我还会写一两个具体例子告诉 Agent 什么样的代码算风险。模型是靠模式匹配来识别的例子写得越典型识别越准。但要注意规则文件千万不要变成一本万能的漏洞百科那样太长Agent 读不完反而影响效果。3.2 密钥泄露最容易抓到的“低级错误”密钥泄露这个检查项是我觉得性价比最高的。因为不需要特别复杂的逻辑正则一匹配基本就是实锤。而且一旦真实密钥被推到远端再撤回也大概率已经泄露了。扫描脚本里通常要覆盖这些模式AWS Access KeyAKIA 开头的 20 位大写字母数字私钥块RSA、EC、OPENSSH 开头GitHub Tokenghp_ 开头Stripe Keysk_live_ 开头常见云厂商的服务账号 JSON 片段除了正则还要让 Agent 检查几个特定的高危文件.env、.env.local、application.yml、config.php、settings.py。这些文件一旦出现在仓库根目录基本就是危险信号。我的扫描脚本也会跳过 .git 目录和 node_modules否则会扫出一堆测试样例里的假阳性。还有一个容易忽略的点图片和日志里也可能有密钥。比如截图里贴了 API Key日志里打了 Token。规则文件里要提醒 Agent如果报告里出现“日志输出敏感信息”也要算风险条目。3.3 依赖与供应链安全不是跑一次 npm audit 就够依赖安全这块光靠 Agent 自己“想”是没用的。它能记住的漏洞库非常有限而且可能过时。正确做法是让 Skill 调用专业工具。我在规则文件里定义了这样一套检查顺序先看锁文件存不存在比如 package-lock.json、pnpm-lock.yaml、poetry.lock没有锁文件这件事本身就是风险然后跑漏洞扫描工具最后检查依赖源看有没有 install 脚本在装包之后执行了额外命令。常用命令参考# Node.js 项目 npm audit --json # Python 项目 pip-audit # 通用开源漏洞扫描 osv-scanner -r . # 容器和文件系统综合扫描 trivy filesystem --scanners vuln,secret,config .要提醒 Agent 的是工具输出的原始 JSON 不适合直接丢进报告。规则文件里会要求它对扫描结果做一次翻译把模块名、风险等级、受影响的版本范围、修复版本提炼出来再写进审计报告。这样整个输出才有人读得懂。3.4 云与基础设施配置审计现在大多数项目已经不是“一个单体应用跑在一台机器上”的模型了Docker、Kubernetes、云存储几乎看不到不用的。AI 生成这些配置的时候也特别容易顺手就写出高危配置。我在 infra 规则里沉淀了几类检查项Dockerfile是不是用了 root 用户、是不是把密钥作为环境变量传进镜像、基础镜像有没有固定 tag、.dockerignore 是否存在。KubernetesPod 是否配置了 privileged、是否挂载了宿主机敏感目录、Secret 是不是用明文写在 YAML 里、探针和资源限制有没有缺失。云存储对象存储桶是不是设置成了公共读写、访问策略是否绑定了超大范围的通配符。IAM权限策略是否用 * 代替了具体资源、是否给普通服务账号配了管理员权限。基础设施的规则文件一般比较长所以我会要求 Agent 只基于现状做对比判断不要脑补。它看不到实际云控制台的状态时就针对代码仓库里的配置文件做静态审计这已经是很大的价值。4. 从零手写一套可用的 security-audit-skill结构讲完接下来就是动手实现的环节。我会带你走一遍我实际创建这个 Skill 的完整过程。你不用完全复制我的模板按你的技术栈和团队习惯做删减就行。4.1 初始化目录与脚手架先创建一个目录并生成基本结构mkdir -p security-audit-skill/{rules/{web_app,secrets,dependencies,infra},scripts,templates,references} touch security-audit-skill/SKILL.md touch security-audit-skill/templates/audit_report_template.md如果你用 Git 管理我建议把 rules 和 scripts 提交到仓库方便团队共享。还有一个细节在这个 Skill 仓库里记得建一个 .gitignore否则扫描脚本可能把自己仓库里的测试文件都误判成风险。目录创建之后先把 templates/audit_report_template.md 写好。这个操作很多人会忽略但它其实是整个输出质量的保障。有了模板Agent 每次输出的结构就不会跑偏。模板大概是这样的# 安全审计报告 审计范围{{目标路径}} 审计时间{{时间}} 技术栈{{语言与框架}} ## 风险概览 | 严重级别 | 数量 | | --- | --- | | 高 | {{n}} | | 中 | {{n}} | | 低 | {{n}} | ## 风险明细 ### [高] {{风险标题}} - 文件位置{{path}}:{{line}} - 风险描述{{说明}} - 修复建议{{建议}} (重复)4.2 SKILL.md 实例一份可以直接改的模板下面这个 SKILL.md 是我当前在用的简版你可以直接复制改。注意 Frontmatter 里的 when_to_use 要按你自己的场景调整正文里的步骤也可以往你的规则目录上靠。--- name: security-audit description: 对指定目录或代码仓库执行安全审计包括 OWASP 常见漏洞、硬编码密钥、依赖与供应链、基础设施配置输出结构化审计报告。 when_to_use: - 用户要求安全审计、安全检查、漏洞扫描、渗透测试辅助 - 代码变更涉及 SQL、文件上传、认证授权、外部网络请求、加密逻辑 - 需要在新合并请求或上线前做安全评估 version: 1.0.0 --- # Security Audit Skill 你是安全审计助手。请严格按照本技能定义执行不要跳过步骤。 ## 执行步骤 1. 收集上下文查看仓库结构识别主语言和框架读取依赖清单。 2. 读取 rules 目录下对应的规则文件。 3. 执行静态代码检查以 rules/web_app/owasp_top10.md 为清单逐项排查。 4. 运行密钥扫描脚本python3 scripts/scan_secrets.py target 5. 运行依赖漏洞扫描按 rules/dependencies/supply_chain.md 中列出的工具执行。 6. 检查基础设施配置rules/infra/docker.md 与 kubernetes.md。 7. 按 templates/audit_report_template.md 输出报告。 ## 输出要求 - 每条风险必须包含具体文件路径和行号。 - 严重级别分为高、中、低三档。 - 对于无法确认的风险明确标记为“待人工确认”不要直接断定。 - 不输出与审计无关的内容。这里有个细节我在步骤 7 里特别提到了“无法确认的风险要标记为待确认”这个约束极大减少了误报对团队的影响。AI 审计本来就是做初筛把确定性问题快速挑出来把不确定项交给人就够了。4.3 编写辅助审计脚本脚本的作用是给 Agent 提供“确定性”。LLM 可以判断代码模式但遇到密钥扫描这种活手工看代码效率低而且容易漏。下面这个 Python 脚本是我的起步版本用来扫常见的硬编码凭证#!/usr/bin/env python3 scan_secrets.py - 扫描仓库内可能被硬编码的密钥和凭证。 import pathlib import re import sys SECRET_PATTERNS [ (rAKIA[0-9A-Z]{16}, AWS Access Key), (r-----BEGIN (RSA|EC|OPENSSH|PRIVATE) PRIVATE KEY-----, Private Key), (rghp_[0-9A-Za-z]{36}, GitHub Token), (rsk_live_[0-9A-Za-z]{24,}, Stripe Live Key), (rxox[baprs]-[0-9A-Za-z-]{10,}, Slack Token), ] IGNORE_DIRS {.git, node_modules, venv, dist, build, .venv, target} def scan_dir(root: pathlib.Path): findings [] for path in root.rglob(*): if not path.is_file(): continue if any(part in IGNORE_DIRS for part in path.parts): continue try: text path.read_text(encodingutf-8, errorsignore) except Exception: continue for line_no, line in enumerate(text.splitlines(), 1): for pattern, kind in SECRET_PATTERNS: if re.search(pattern, line): findings.append((path, line_no, kind, line.strip()[:120])) return findings if __name__ __main__: target pathlib.Path(sys.argv[1]) if len(sys.argv) 1 else pathlib.Path(.) results scan_dir(target) if not results: print(未发现明显的硬编码密钥。) sys.exit(0) for path, line_no, kind, snippet in results: print(f{path}:{line_no} [{kind}] {snippet}) sys.exit(1)脚本不是我写的核心核心是让 Agent 学会使用它。如果测试项目里有大量样例密钥扫出来一堆也正常。你可以在 SKILL.md 里加一句“忽略测试目录中的虚构示例”脚本里也做了 ignore 目录两边配合。依赖扫描那个环节我通常不写复杂脚本因为现有工具足够好用。我会在 SKILL.md 里定义好命令执行顺序并规定输出结果如何写进报告。4.4 集成到 Codex / Claude Code / OpenCodeSkill 写好之后最关键的一步是让 Agent 能找到它。不同工具的目录规范不一样但思路是一致的把整个 security-audit-skill 目录放进 Agent 会扫描的 skills 路径。以目前常见的几个工具为例Codex 系通常是放在 ~/.codex/skills/security-audit-skill/ 或项目目录下的 .agents/skills/ 里。Claude Code 系放在 ~/.claude/skills/ 或项目根目录的 .claude/skills/ 下。OpenCode同样支持在项目级 .opencode/skills/ 或用户级配置目录里放技能包。放置之后建议先做一次“触发测试”。最简单的办法是随便指一个小项目直接输入“请对当前目录做一次安全审计”。看 Agent 是不是主动加载了 SKILL.md再检查输出格式是否符合模板。如果 Agent 没反应问题大概率出在 when_to_use 和 description 写得不够明确上。如果你是在 CI 里用还可以把执行命令封装成非交互模式让 Agent 跑完直接输出 JSON 格式的报告再交给下游的缺陷管理平台。5. 实际跑起来的常见问题与排查任何一个真实跑过的 Skill都会有各种边界情况。这一节我把踩过的坑和排查思路整理成速查表方便你遇到问题时直接查。5.1 Agent 根本不触发 Skill这是最常见的问题我一开始也栽在这里。明明 Skill 装好了问它“检查一下项目的安全问题”它却直接走普通对话模式回答。可能原因排查方法解决方式description 与用户表述不匹配检查 Frontmatter 中的 description 是否涵盖“安全审计”“漏洞检查”等触发词扩充触发词加上业务场景描述when_to_use 条件过于苛刻看是否只在场景 A 下触发导致场景 B 不触发放宽 when_to_use增加常见场景技能包路径不对确认目录是否放在 Agent 扫描范围内查看工具文档调整到正确路径同时安装了多个相似 Skill存在同名或描述类似的其他技能包改名或用更精确的 description 区分还有个隐藏坑有些工具要求技能包目录里必须包含 SKILL.md文件名不能写错大小写也要对。我就犯过一次把 SKILL.md 写成 skill.md 的低级错误结果 Agent 完全忽略。5.2 审计结果太泛抓不住重点刚开始跑的时候报告经常是一大堆“建议加强输入验证”这种空话没有具体位置也没有证据。这是因为 Agent 没有理解“证据优先”的规则。解决办法是在 SKILL.md 里强制要求每条风险描述不少于两行证据一行写文件路径一行写代码片段。如果 Agent 找不到具体位置宁可跳过也不要输出没有证据的模糊结论。同时把“不要泛泛而谈”直接写进输出要求里模型对明确的指令执行力会高很多。5.3 误报太多团队不想用误报多通常有两个原因一是密钥正则太宽把示例代码里的 fake key 也算进来了二是规则文件没有说明忽略范围。我会做三层处理。第一脚本层面过滤 ignore 目录第二规则层面明确“测试代码、示例脚本、fake 开头的 key 都不能算风险”第三输出层面增加“待人工确认”级别把置信度不高的项分进去。这样团队看到的报告会清爽很多对报告的信任度也会逐渐建立起来。5.4 怎么把安全审计结果嵌入 CI/CD做团队落地的时候不能总指望人主动让 Agent 跑审计更合理的方式是把它塞进自动化流水线。我的做法是专门写一个非交互入口脚本它调用 SKILL.md 对应的执行流最后把所有发现写到 security-report.json。CI 配置里在代码合并之前跑一次只对“高”级别风险做强校验中低风险允许提醒但不拦截。这个策略能避免“安全闸门太紧导致开发流程停滞”的问题团队接受度会高很多。5.5 Skill 在大型仓库里跑得很慢审计一个大仓库时Agent 要读的文件很多有时还会超时。我的经验是不要一次性扫描全仓库而是按 diff 做增量审计。在 SKILL.md 里可以增加一个变量让 Agent 只审计 git diff 涉及的文件。这样既快又精准因为增量提交里的安全问题往往就是本轮引入的。只有在全量发布或者做季度安全评估时才跑完整扫描。6. 后续扩展与维护思路security-audit-skill 做出来不是终点它需要持续维护。安全领域的规则变化很快如果技能包不更新三个月后它可能就成了“淘汰的安检仪”。6.1 规则库如何持续更新我维护这套规则库主要有两个来源一是跟踪 OWASP、CWE 等公开标准的变化二是从自己团队的真实漏洞报告里提炼模式。每次在项目里发现一个新的典型安全问题我都会顺手把它固化进 rules 目录像写文档一样写一段风险描述、几个例子、几条修复建议。这样积累起来的规则库非常实用因为它们不是从网上抄的而是从真实事故里提炼的Agent 用起来命中率特别高。我还会给每个规则文档加上更新日期方便审计报告里标注“本规则基于 2025 年某月的风险情报”这对安全合规也有帮助。6.2 与其他专业工具联动Skill 里的 LLM 判断和传统安全扫描工具其实可以互相补充。我的规则库里会定义一组“后端工具调用”比如Semgrep 做自定义代码规则扫描gitleaks 做密钥泄露检测osv-scanner 做开源依赖漏洞检查Trivy 做容器和云配置扫描Checkov 做 IaC 策略检查LLM 负责读这些工具的输出去掉误报补上修复建议再把结果汇总成报告。这种组合比“纯靠 LLM 看代码”或者“纯靠工具跑扫描”都要靠谱因为工具的规则是确定性的而 LLM 的判断力正好可以帮工具处理上下文相关的问题。6.3 让 Skill 变成团队共享的安全资产一旦这套 skill 在你自己项目里跑通了就可以把它推广成团队基础设施。放在独立的 Git 仓库里配上 README 和贡献模板任何人发现了新的风险模式都能提 merge request。这样安全审计的规则库就变成了团队共同维护的知识资产而不是某个人电脑里的私人脚本。我也建议每隔一段时间做一次“技能包评审”对照最近发生的事故看规则库里是不是漏掉了什么。这种评审不需要多复杂只要负责人能把新风险点补进去就行。7. 一点个人维护心得最后分享几点我在实际使用中的体会不算什么高深理论但都是踩过坑之后沉淀下来的。第一不要一上来就做大而全的规则库。先把最典型的五类问题做好硬编码密钥、SQL 注入、危险函数调用、依赖漏洞、危险配置。这五个高频项能拦住绝大多数低级事故。等团队用顺了再慢慢扩展规则文件。第二报告里一定要带“证据行号”。任何审计结论没有具体文件位置就等于没查。逼着 Agent 输出证据行号既能减少空话也方便开发人员复核。第三把“待人工确认”作为一个正式级别写进报告。AI 审计的定位是初筛不是终审。有了这个机制团队不会因为误报产生“狼来了”的疲劳感。这套 security-audit-skill 我跑了小半年最大的变化不是它发现了多少严重漏洞而是它让团队在提交代码时真正开始在意安全问题。开发同学看到报告里清晰的证据会自己回头改代码。我觉得这就值了。你可以先拿一个小项目试一版跑通之后再逐步扩展不用等规则库完美了才上生产。
