安全扫描技能：把 OWASP Top 10 安全审查变成开发流程里的固定动作
- 一句话定位：security-scan 是一个面向代码安全的自检技能，围绕 OWASP Top 10、身份验证与数据验证三大检查清单，配合自动化扫描脚本，帮你在合并代码之前发现常见漏洞。
- 核心能力：覆盖访问控制破坏、加密失败、注入等 OWASP 高频风险项，并给出从「关键」到「低」的四级漏洞严重度划分。
- 可落地：不只是给结论，还给出修复优先级（关键/高立即修复并阻止合并、中在发布前修复、低进入待办），并把审计结果沉淀成可归档的 Markdown 报告。
- 适合谁用：独立开发者、小型研发团队、接手遗留项目的工程师，以及大量使用 AI 生成代码、需要一道安全兜底的人。
- 安装门槛：属于「装上就能问」的轻量技能，无需部署服务器；具体安装入口与命令以官方说明为准。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 安全扫描技能Skill |
| 英文名 | security-scan |
| 技能ID | 11819 |
| 能力类型 | 代码安全扫描与漏洞检查 |
| 主要输入 | 项目代码、目录结构或具体文件片段 |
| 主要输出 | 安全检查结论、漏洞分级、审计报告与修复建议 |
它解决什么问题
写业务代码时，安全问题往往不是「不会写」，而是「想不起来检查」。访问控制有没有默认拒绝？敏感数据在传输和静态存储时是否加密？SQL 是不是用参数化查询拼出来的？密码有没有用 bcrypt/argon2 哈希？这些点在快速迭代时极易被跳过，等到上线后被扫出来，修复成本会翻好几倍。security-scan 的价值就在于把这些「靠自觉」的检查项固化成一份可反复执行的清单和脚本流程。
一键安装的思路与步骤
- 确认安装前提：需要一个支持 AI 技能（Skill）加载的运行环境或编程助手，以及可以运行的 Node.js 工具链（因为该技能的自动化脚本会调用
npm audit、npx eslint、npx secretlint等命令）。如果项目本身不是 Node 生态，清单类检查依然可用，脚本部分可按官方说明做适配。 - 通过技能入口安装：在技能市场、技能仓库或本地技能目录中检索英文名
security-scan或技能ID11819，选择安装或导入。具体的安装命令、仓库地址与目录规范，以官方说明为准。 - 验证是否生效：安装完成后，在对话中直接提出「用 security-scan 扫描当前项目的安全风险」，观察返回内容是否包含 OWASP 检查清单条目或指向
checklists/owasp-top-10.md之类的清单文件；若返回结构化的检查项与分级结论，即说明技能已正常加载。 - 固化到工作流：把「提交前跑一次安全扫描」写进团队规范，让它像跑单元测试一样成为默认动作，而不是一次性动作。
2. 该技能的主要功能和特点
- OWASP Top 10 检查清单：内置
checklists/owasp-top-10.md参考清单，当前明确覆盖 A01 访问控制破坏（端点授权、默认拒绝、速率限制、CORS 配置）、A02 加密失败（HTTPS 传输加密、静态加密、强算法、密钥管理）、A03 注入（参数化查询、输入验证、输出编码、禁用eval()处理用户输入）。 - 身份验证专项清单：参考
checklists/auth-security.md，检查密码哈希是否使用 bcrypt/argon2、会话是否妥善管理、令牌是否安全存储、注销时是否使会话失效。 - 数据验证专项清单：参考
checklists/data-validation.md，检查所有输入是否已验证、类型检查是否强制、是否设置大小限制、格式验证是否完成。 - 自动化扫描脚本：提供
scripts/security-scan.sh，把依赖审计（npm audit）、静态安全分析（npx eslint --plugin security .）与密钥泄露检查（npx secretlint .）串成一条可重复执行的命令链。 - 四级漏洞严重度模型：关键（远程代码执行、SQL 注入、身份验证绕过、敏感数据暴露）、高（XSS、CSRF、不安全反序列化、权限提升）、中（信息泄露、缺少加密、弱会话管理、日志不足）、低（缺少安全头、详细错误消息、无已知漏洞的过时依赖）。
- 结果可归档：审计报告统一保存到
docs/reviews/security-audit-{session}.md，便于在代码评审、发版评审中作为附件引用。 - 明确的修复流程：关键/高立即修复并阻止合并，中等级别在发布前修复，低级别进入待办事项跟踪，避免「报了一堆问题但没人排期」。
- 最佳实践对照表：以「做/不做」两条清单给出正向与反向约束，例如使用参数化查询、验证所有输入、编码所有输出、保持依赖更新；不硬编码秘密、不信任用户输入、不暴露堆栈跟踪、不使用弱算法、不跳过身份验证检查。
和普通工具相比强在哪？单点的 npm audit 只看依赖，ESLint 只看代码风格与部分规则，而 security-scan 把它们串成流程，并补上了「清单式的设计层检查」——比如默认拒绝、CORS 配置、会话失效这些无法被单纯静态分析完整覆盖的点。
3. 如何使用该技能？
步骤一：明确扫描范围
在对话中给出项目路径或关键文件，例如：「请用 security-scan 扫描 src/api/ 下的所有接口实现和 src/auth/ 登录逻辑，重点检查访问控制与身份验证。」
步骤二：触发清单核对
技能会按 OWASP Top 10、身份验证、数据验证三份清单逐项比对。此时你可以要求它给出「已通过 / 未通过 / 需人工确认」的三态结论，避免含糊表述。
步骤三：运行自动化扫描脚本
在项目根目录执行技能提供的 scripts/security-scan.sh，其内部等价于依次执行：
npm audit—— 依赖漏洞审计npx eslint --plugin security .—— 静态安全分析（插件可用时）npx secretlint .—— 硬编码密钥与凭据检查
步骤四：处理扫描结果并分级
把脚本输出与清单结论合并，按严重度排序：关键与高危项必须当天处理并阻止合并；中危项排入本次发布前的修复计划；低危项进入待办列表。
步骤五：生成审计报告
要求技能「把本次结果按 security-audit 格式写入 docs/reviews/security-audit-{session}.md」，报告中应包含：扫描范围、命中项、对应清单条目编号（如 A03 注入）、严重级别、修复建议。
步骤六：修复后复扫
修复完成后重新执行一次脚本与清单核对，确认高危项清零，并在报告中追加复扫记录。
输入输出示例
输入：
用 security-scan 检查
src/routes/order.js的 A03 注入风险，并说明是否需要参数化查询改造。
输出（示意）：
命中 A03 注入：发现字符串拼接 SQL；风险等级：关键；建议改为参数化查询；报告已写入
docs/reviews/security-audit-20250101.md。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| security-scan（本技能） | 对话式安全自查与清单核对 | OWASP Top 10 清单、身份验证与数据验证清单、扫描脚本、四级分级、报告落盘 | 低，安装 AI 技能即可用，脚本需 Node 环境 | 提交前自查、代码评审前置、遗留项目体检 | 优势：门槛低、能覆盖设计层检查、附带修复优先级；不足：依赖人工触发，非持续集成内建 |
| SonarQube / Semgrep 类静态分析平台 | 工程化 SAST | 规则引擎、质量门禁、CI 集成 | 中到高，需部署服务或配置流水线 | 中大型团队持续集成 | 优势：规则丰富、可自动化卡点；不足：部署与维护成本高，业务语境理解弱 |
| npm audit / Dependabot 类依赖扫描 | 依赖与供应链漏洞扫描 | 依赖版本漏洞比对、升级提示 | 低 | 第三方库安全治理 | 优势：免费、开箱即用；不足：只覆盖依赖，查不到业务代码里的注入与授权缺陷 |
| 人工安全评审 / 渗透测试 | 深度人工审计 | 业务逻辑漏洞挖掘、攻击路径验证 | 高，需专业人员与排期 | 上线前重要版本、合规审计 | 优势：能发现复杂逻辑漏洞；不足：成本高、频率低、无法每次提交都做 |
可以看出，security-scan 的生态位是「高频、低成本的第一道防线」，而不是替代专业 SAST 平台或渗透测试。
5. 该技能的典型应用场景与实际体验情况
场景一：独立开发者的上线前自查
角色：独立开发者，接手一个外包项目即将交付。痛点：没有安全团队，也没时间系统学习 OWASP。使用方式：交付前调用技能做一次全量扫描，重点核对 A01 授权与 A02 加密两项。实际体验：上手几乎没有学习成本，清单式的「打勾」过程让遗漏点一目了然；注意点是脚本里的 npm audit 只覆盖 Node 依赖，非 Node 项目需按其说明处理。
场景二：团队代码评审的前置关卡
角色：小型研发团队的技术负责人。痛点：Code Review 时安全项经常被业务逻辑讨论淹没。使用方式：要求提交者在 PR 描述中附上 docs/reviews/security-audit-{session}.md 报告链接，关键与高危项未清零不予合并。实际体验：把「安全」从主观判断变成有据可依的准入条件，评审效率明显提升；注意需要团队统一报告命名与存放路径。
场景三：接手遗留系统做安全体检
角色：新入职工程师维护一套多年未动的老系统。痛点：不知道哪些接口缺授权、密钥是否硬编码在代码里。使用方式：先用 npx secretlint . 快速排查硬编码凭据，再按 OWASP 清单逐模块核对。实际体验：能较快圈出高风险区域并形成待办清单；注意老项目可能无法直接跑通 ESLint 安全插件，应以清单核对为主。
场景四：AI 生成代码的安全兜底
角色：大量使用 AI 编程助手的开发者。痛点：生成代码能跑通不代表安全，容易忽略输入验证与输出编码。使用方式：每轮生成后追加一次「用 security-scan 检查这段代码的注入与验证风险」。实际体验：能有效拦截字符串拼接 SQL、直接 eval() 用户输入等典型问题；注意仍需人工确认业务流程层面的授权逻辑是否正确。
6. 该技能能为用户带来的价值
- 效率提升：把分散在文档、经验和记忆里的安全检查项，收敛成一次可重复执行的流程，安全自查从「半天翻资料」缩短到「一次对话 + 一条脚本」。
- 门槛降低：不需要先成为安全专家，按 OWASP Top 10、身份验证、数据验证三份清单逐项核对即可覆盖高频风险点。
- 风险前移：关键与高危漏洞在合并前被拦截，避免上线后返工，修复成本远低于线上事故处置。
- 决策可追溯：统一的报告路径与四级分级，让「修什么、先修什么、谁跟踪」有据可依，低危项也不会被无声丢弃。
- 长期收益：随着「提交前扫描」成为团队肌肉记忆，代码库的整体安全基线会持续抬升，新人接手成本同步下降。
7. 常见问题 FAQ
Q1：怎么安装 security-scan？需要付费吗？
在支持 AI 技能的环境中检索英文名 security-scan 或技能ID 11819 导入即可。具体的安装命令、来源渠道与是否收费，以官方说明为准；本技能本身提供的扫描脚本依赖 npm audit、eslint、secretlint 等开源命令，需自备 Node 环境。
Q2：它和 SonarQube、npm audit 有什么区别？
npm audit 只看第三方依赖漏洞；SonarQube 属于工程化静态分析平台，需要部署和流水线配置。security-scan 的定位是对话式自查 + 清单核对，覆盖授权、加密、注入、身份验证、数据验证等设计层检查，并给出修复优先级，适合作为高频的第一道防线，而不是替代前两者。
Q3：扫描会不会直接改我的代码？ 从技能定义看，它的职责是「识别和预防安全漏洞」并输出报告与修复建议。修复动作建议由你确认后执行，尤其是涉及鉴权逻辑与加密方案时，务必人工复核。
Q4：适合谁用？非 Node 项目能用吗？
适合独立开发者、小型研发团队、接手遗留系统的工程师，以及大量使用 AI 生成代码的开发者。非 Node 项目无法直接使用 npm audit 等脚本，但 OWASP Top 10、身份验证、数据验证三份清单是语言无关的，仍可正常核对。
Q5：扫描报告存在哪里？会不会覆盖历史记录？
报告默认保存到 docs/reviews/security-audit-{session}.md，文件名中的 session 用于区分不同轮次，建议按日期或迭代号命名，形成可对比的历史审计轨迹。