security-auditor

security-auditor 技能概览

security-auditor 能做什么

security-auditor 是一个面向代码审计和漏洞分诊的轻量级安全审查辅助技能。它的核心是覆盖 OWASP Top 10、进行基础仓库检查，以及提供简洁的报告产出流程，而不是做深度自动化扫描。如果你希望 AI 助手帮你检查应用代码中的常见安全弱点、提示可能存在的问题，并把审计结果整理成结构化报告，这个技能是一个很实用的起点。

谁适合使用 security-auditor 技能

最适合的用户包括开发者、重视安全的代码评审者、技术负责人，以及需要对现有代码库做快速首轮审计的 agent 使用者。security-auditor skill 特别适合这样的场景：你想要比一句“帮我审这份代码有没有漏洞”更有结构的方法，但又暂时不需要上完整的 SAST 平台。

真实要解决的问题

大多数用户并不是想上一堂 OWASP 理论课，而是想尽快回答这些实际问题：

• 这个 repo 里我应该先看哪里？
• 有没有明显的认证、密钥、注入或配置风险？
• 能不能直接产出一份可交给团队处理的审计报告？
• 在把某个问题定性为漏洞之前，我应该收集哪些具体证据？

这个技能就是围绕这类工作流设计的。

这个技能的差异点是什么

security-auditor 的主要区别在于，它把下面这些内容组合到了一起：

• 面向安全审查请求的激活规则
• 以 OWASP 为导向的检查清单和 grep 风格检查模式
• 用于发现 secrets 和生成报告的辅助脚本
• 用于检查清单、OWASP 分类和修复步骤的参考文件

因此，它比单纯一段 prompt 更好用，虽然整体上仍然是轻量、以分析人员驱动为主的方案。

它不能替代什么

它不能替代以下工具或能力：

• dependency scanners
• DAST tools
• infrastructure and cloud posture review
• manual exploit validation
• language-specific secure coding expertise for every stack

当你需要的是一层有引导的审查流程，而不是一整套完整的安全体系时，再使用 security-auditor for Security Audit 才更合适。

如何使用 security-auditor 技能

security-auditor 的安装方式

如果你的 skills 工作流支持通过 GitHub 安装，最直接的安装方式是：

npx skills add https://github.com/zhaono1/agent-playbook --skill security-auditor

如果你已经在本地使用这个仓库，可以直接查看 skills/security-auditor/ 下的内容。

先读这些文件

如果你想最快上手，建议按下面的顺序阅读：

1. SKILL.md
2. README.md
3. references/checklist.md
4. references/owasp.md
5. references/remediation.md
6. scripts/find_secrets.py
7. scripts/security_audit.py

这个阅读顺序能让你先搞清楚技能边界，再看审计 checklist、修复预期，最后再了解辅助自动化脚本。

这个技能需要什么输入

security-auditor usage 的效果高度依赖于你给出的范围定义。建议至少提供：

• repository path 或目标文件
• 应用类型和技术栈
• trust boundaries
• 敏感资产
• auth model
• 部署上下文
• 这次审计中“完成”的标准是什么

一个较弱的请求是：

Audit this repo for security issues.

一个更强的请求是：

Audit the API service in ./backend for OWASP Top 10 issues. Focus on auth, IDOR, secrets exposure, SSRF, and unsafe deserialization. Assume this service handles customer billing data and uses JWT auth. Return findings with severity, file evidence, exploit path, and remediation.

security-auditor 在实际中如何被触发

从仓库内容来看，这个技能会在以下请求中被触发：

• security audit
• vulnerabilities
• security review
• OWASP-related checks

但在实际使用时，最好明确说明目标、风险重点以及你希望的输出格式，这样 agent 才不会停留在泛泛而谈的建议层面。

把模糊目标改写成更好的 prompt

如果你希望得到更好的 security-auditor guide 结果，可以按这个结构来提问：

• Scope： 要审哪个服务、目录或 PR
• Risk focus： auth、secrets、injection、SSRF、crypto、logging
• Evidence standard： 要求引用文件、路由、配置或命令
• Output： 以带 severity 和修复建议的 findings 表格输出
• Constraints： 没有代码证据就不要报告推测性问题

示例：

Use security-auditor on ./src and ./config. Check for OWASP Top 10 issues, especially broken access control, hardcoded secrets, weak hashing, and unsafe external requests. For each finding, cite the exact file and code path, explain the impact, and propose the smallest safe fix.

使用仓库自带脚本

这个仓库自带了两个很实用的辅助工具：

运行 secret 扫描器：

python scripts/find_secrets.py .

生成审计报告模板：

python scripts/security_audit.py --name "payments-api" --owner "platform-security"

这两个脚本都很简单，但很有用。find_secrets.py 可以抓出几类常见的凭据模式；security_audit.py 则能帮你生成结构化报告，方便把 findings 交接给团队处理。

这些脚本能做什么、不能做什么

secret 扫描器本身就是刻意保持轻量的。它会在文本文件中搜索少量已知模式，比如 AWS 风格的 keys、Google API keys，以及 sk- 风格 token。它会漏掉很多其他 secret 格式，也可能把一些非生产环境示例误报出来。

报告生成器本身不做分析。它只是生成一个 markdown 审计骨架，其中包含 scope、ownership、threat model、findings、remediation 和 evidence 等章节。

真实审计场景下推荐的工作流

一套实用的 security-auditor usage 流程通常是这样的：

1. 先定义审计范围和关键资产。
2. 让 agent 优先检查高风险区域：auth、routes、config、secrets、outbound calls。
3. 运行 scripts/find_secrets.py，做一轮快速凭据排查。
4. 使用 references/checklist.md 中的 checklist，避免遗漏显而易见的问题。
5. 把候选 findings 映射到 references/owasp.md 中的分类。
6. 参考 references/remediation.md 起草修复建议。
7. 只把已验证的问题写入或填入 security-audit.md。

这样做能让审计始终建立在证据之上，而不是堆一份泛泛的风险清单。

优先检查哪些高价值仓库模式

当你把 security-auditor 指向典型安全热点时，效果通常最好：

• route handlers 和 controllers
• auth middleware
• config 和环境变量加载逻辑
• 文件上传逻辑
• URL fetchers 和 webhook handlers
• serialization 和 template rendering
• dependency manifests
• logging 和 monitoring 代码

如果你让这个技能一次性审完整个 monorepo，结果通常会变得更浅。

security-auditor for Security Audit 的最佳使用场景

以下场景特别适合使用 security-auditor for Security Audit：

• merge 或发布前做一轮首轮安全审查
• 对中小型代码库进行结构化审计
• 按 OWASP 思路检查 API 或 Web 应用逻辑
• 需要给工程团队跟进的、带证据的 findings
• 作为人工审查的轻量补充

什么情况下普通 prompt 就够了

如果你只是想一次性解释某个可疑函数是否有问题，普通 prompt 往往就够了。security-auditor 的价值主要体现在你需要可重复的覆盖方式、明确的仓库阅读路径、检查清单，以及一条可落地的报告产出链路时。

security-auditor 技能 FAQ

security-auditor 适合新手吗

适合，但有一个前提：新手可以从 checklist 和 OWASP 框架中受益很多，但仍然需要自己验证 findings。这个技能能帮助你提出更好的问题、检查常见失误点，但它本身并不能保证某个问题一定可利用，也不能单独判断其业务影响。

security-auditor 技能会扫描依赖吗

不会直接扫描。参考资料里确实提到，dependency vulnerability scanning 是审查的一部分，但仓库自带脚本并不执行 package audit。你应该把这个技能和生态原生工具一起使用，例如 npm audit、pip-audit、cargo audit，或者其他等价扫描器。

它只能用于 Web 应用吗

大体上是的，这也是它最擅长的场景。这个仓库围绕 OWASP Top 10 中的 broken access control、injection、misconfiguration、SSRF 等分类展开，这些内容最自然地适用于 Web 应用和 API。它也能辅助审查相邻类型的服务，但示例和检查方式整体上仍然偏 Web。

它和通用安全 prompt 有什么不同

通用 prompt 往往要求模型临时“现编”一套审计方法。security-auditor skill 则给 agent 提供了更清晰的审计框架、明确的 OWASP 分类、辅助参考资料，以及完成常见任务的脚本。这能减少前期摸索成本，也让输出结果更稳定、更一致。

什么情况下不该用 security-auditor

如果你需要的是以下能力，就不建议使用这个技能：

• binary analysis
• cloud IAM assessment
• container hardening review
• exploit development
• compliance-only documentation without code review
• a high-confidence automated scanner replacement

如果团队预期它开箱即用就能提供非常深入、强语言特性的静态分析，那它也不是一个理想选择。

security-auditor 会提供修复建议吗

会，但深度比较有限。references/remediation.md 给的是一套基础修复流程：复现、识别影响、修补、补测试、记录变更。这个技能更擅长帮你把 remediation 过程结构化，而不是为每一种技术栈都产出框架级、可直接落地的安全代码补丁。

如何改进 security-auditor 技能

给 security-auditor 更清晰的范围定义

影响结果质量的最大杠杆，就是范围定义是否清晰。告诉 security-auditor：

• 哪些文件夹最重要
• 哪些数据是敏感的
• 谁可以访问什么
• 哪些外部系统是可信的
• 哪类 findings 应该优先处理

如果缺少这些信息，这个技能很容易退回到泛泛的 OWASP 评论层面。

不只要 findings，更要证据

更好的 prompt 应该明确要求：

• 精确的文件路径
• 代码片段或行号引用
• 攻击成立前提
• 现实中的影响
• confidence level
• 最小化修复方案

这样可以减少误报，也能让输出结果真正被工程团队拿去处理。

使用 severity 和 exploitability 过滤器

并不是每一个 code smell 都值得升级处理。你可以要求这个技能把问题分开：

• 已确认漏洞
• 很可能存在、但需要进一步验证的弱点
• 加固建议
• 在补充上下文后可判定为非问题

这样能避免你的审计报告变成一长串理论上的噪音问题。

搭配仓库原生工具一起用

security-auditor install 只是第一步。要提升输出质量，建议结合以下内容一起使用：

• 测试套件
• dependency audit 工具
• framework security linters
• secret managers 和配置审查
• 如果有的话，再加上 runtime logs 或 request traces

当这个技能能结合真实项目证据一起推理时，它的价值会明显更高。

常见失败模式

最常见的问题包括：

• 一次审的范围太大
• 报告了泛泛的 OWASP 问题，却没有代码证据
• 忽略了授权相关的业务逻辑上下文
• 过度相信这个轻量 secret 扫描器
• 把报告模板误当成已经完成的分析结果

这些问题大多可以通过更严格的 prompt 和更小的审查目标来解决。

首轮审查后继续迭代

一套更有效的工作流通常是：

1. 先让它给出候选 findings。
2. 逐条追问证据和 exploit path。
3. 要求提供带权衡说明的修复方案。
4. 让它补充遗漏的测试用例。
5. 只针对修复后的文件重新审查。

相比单次、宽泛的大审计 prompt，这种迭代式流程对精度的提升要明显得多。

用可接受的输出示例来强化 prompt

如果你想要真正可交付的报告，就要明确说出来。示例：

Use security-auditor to review ./api. Return a table with Severity, OWASP Category, File, Evidence, Impact, Remediation, and Confidence. Only include findings tied to concrete code or config. Add a short "needs manual validation" section for suspicious patterns that are not yet proven.

相比只是简单问“这段代码安不安全”，这种写法通常更容易得到可用的审计产物。

用你自己的参考资料增强这个技能

如果你会长期使用这个技能，最简单也最有效的升级方式，就是扩展它的 references，例如加入：

• 面向你所用技术栈的安全编码规则
• 组织内部认可的 severity 定义
• 针对你的框架的 remediation 示例
• 内部审查 checklist
• 已知高风险模块和 auth 模式

这样可以把 security-auditor 从一个通用 OWASP 辅助工具，逐步变成真正贴合你团队环境的审查工作流。