预生产安全审计 是做什么的？
对指定版本进行决策有用的安全评估。说明检查了什么、证据支持什么、哪些尚不清楚，以及如何修复和验证每个问题。除非用户要求其他语言，报告默认使用英语。
仅使用当前主机可用且授权的功能。将捆绑引用解析为此技能文件夹相对路径。不假定本地文件访问、shell/扫描器、浏览、连接器或委派。当某项功能不可用时，审查提供的证据并记录U-###缺口。如果无法写入请求的文件系统目标，则以可下载的构件或Markdown文本形式提供报告，并说明该交付限制。
选择检查项前进行校准
- 识别请求的评估、目标版本或提交、部署目标、可用证据和现有授权。保留用户的范围和之前的回答。
- 阅读范围界定问题。如果尚未请求或明确包含仓库审查，则在检查仓库内容之前先解析Q-00。请求审计仓库或代码已经回答了该问题；不要再问。如果用户排除仓库审查，则从所选文档/配置/运行时证据出发，并记录该限制。
- 仅检查在范围内的项目元数据和文档，不执行项目代码。将事实与推论和用户陈述分开记录。提出一组简短且必要的剩余问题，并按产品、暴露、托管、身份、数据和可用访问进行分支。在等待期间继续独立授权的工作；沉默不能解答未解决的范围选择。
- 在报告中记录范围快照、所选模块、适用控制ID、允许的检查以及未解决的问题。当回答改变范围时更新此快照。
路由到相关模块
始终使用审计方法和发现与优先级。仅当模块的界面存在或需要调查时才加载其详细信息。不要仅仅因为模块存在就加载所有模块。
使用35领域覆盖图将原始评估领域关联到控制ID。当工具辅助检查在范围内时，按照扫描器执行程序使用Gitleaks、Semgrep CE、Trivy和ZAP；根据证据和可用性选择工具，并记录实际运行、错误和遗漏。仅手动请求不会激活扫描器。
对于依赖清单，首先重用目标匹配的SBOM，如果需要生成且允许时，再使用Trivy。本机包图、Syft和源导入分析是可选的补充；遵循同一参考中的清单程序。保持包关系与代码导入和运行时关系分开。
| 界面 | 模块 | 路由指导 |
|---|---|---|
| 每个评估 | 架构 | 确定资产、信任边界、关键操作、暴露和责任。 |
| 账户、权限、租户、会话或服务身份 | 身份与访问 | 即使产品没有登录，也要包括基础设施身份。 |
| Web界面、API、工作者、文件或集成 | 应用与API | 针对实际的输入、输出、协议和业务路径选择控制。 |
| 数据、凭据、加密、数据库或存储 | 数据与机密 | 即使没有个人数据，也要包括凭据和元数据。 |
| 已部署的服务或计划中的部署 | 基础设施与部署 | 匹配提供商和部署模型；区分预期配置与观察到的运行时。 |
| 源代码、依赖项、构建或发布过程 | 供应链 | 当包含仓库审查时，检查发现的CI/CD定义、其脚本/模板、信任转换和部署门控，无需等待第二次权限问题。有效的平台设置仍作为独立的证据来源。 |
| 正在进入或已投入运营的服务 | 运营与弹性 | 评估检测、恢复、事件处理、可用性和所有权。 |
| LLM、RAG、AI工具、代理或MCP | AI与代理 | 审查模型输入、数据访问、委派权限、输出和资源限制。 |
| 移动、桌面或浏览器扩展客户端 | 移动与桌面 | 选择平台章节并单独审计后端。 |
对于不受支持的专业界面（如工业设备或定制硬件），记录覆盖限制和所需的专家审查。不要暗示软件模块可以完全评估它们。
检查并记录
- 遵循审计方法的证据、授权和执行规则。审计请求授权分析和报告创建；不会自动授权生产变更、破坏性探测或发布敏感结果。
- 仓库审查涵盖约定的文件、源路径、清单、相关历史和CI/CD定义。包括硬编码的机密、不安全的回退值、环境特定的目标以及固定的安全/身份策略。尊重更窄的路径/历史排除；不要将普通常量标记为没有安全后果的漏洞。
- 在工作时维护证据分类账、控制矩阵、发现、未知项、审计路径边和依赖边。将所有实质性声明与确切的源位置或观察结果以及已检查的版本/环境关联起来。
- 将扫描器输出视为线索，直到上下文化。在分配确认的缺陷或发布后果之前，追踪相关的调用者、守卫、数据路径、配置和部署假设。
- 在清单之后，应用供应链模块的重点当前建议分类（SC-003），优先处理关键组件和已知被利用或关键/高严重性问题。记录确切的包/版本匹配、日期来源、已验证的修复、本地暴露和查询覆盖；离线或失败的查找保持为明确空白。
- 在覆盖范围、发现、修复和图表中使用相同的控制ID。对具有相同根本原因的发现进行去重，同时保留受影响的界面。
- 对于长期审查，在支持时委派独立模块。为每个审查者提供范围和ID分配，然后在写报告之前协调共享信任边界和冲突的主张。
- 如果访问或工具不可用，记录限制并继续有用工作。失败的检查不等于通过的检查。未知的控制不等于不适用。
提供报告
使用报告模板。默认在审计项目的security-audits/<YYYY-MM-DD>-<revision-or-target>/security-audit.md创建新文件，除非用户指定其他目标。如果目标已存在，使用无冲突的后缀。不要将目标报告保存到此技能内部、覆盖先前的评估或提交/上传报告，除非被请求。
包括所需的两个Mermaid图表：
- 分析路径图： 从范围和工件通过已执行的检查到发现、支持的结论和空白，展示可观察的审计线索。显示检查了什么以及检查在哪里停止。这是一个证据图，不是私人推理或虚构的时间线。
- 已分析的依赖图： 包括已检查的组件、包依赖、服务、身份系统、存储和外部集成，带有明确的边类型、证据引用和检查覆盖。将未检查的边界如实包括在内。
使用审计方法中的图谱契约从分类账构建图表。包括节点/边表，以便报告在没有Mermaid渲染的情况下仍然可用。对于大型依赖图，按运行时/服务、包/构建或CI/CD信任关系在依赖部分下拆分。对于已审查的管道，显示触发/输入 → 作业 → 运行器/身份 → 工件 → 环境，区分实际的门控、信任边界和未检查的设置。
报告必须包含优先的修复计划、负责人或未分配的角色、修复之间的依赖关系、验收测试、剩余风险以及未解决的决策。使用发现规则陈述有边界的就绪性建议；该技能不批准部署或认证合规性。
最终质量检查
- 验证范围、修订、证据链接、控制状态以及所有发现/未知ID在文本、表格、图表和计划中一致。
- 检查图表边的方向和标签。区分声明、观察到的行为、推论和不可用的证据。删除所有模板示例数据。
- 确保没有凭据、个人数据样本、敏感提示内容或私有基础设施标识符被不必要地泄露。
- 每个发现都需要具体的纠正和验证标准。每个关键未知需要下一步行动及其发布决策后果。
- 说明哪些检查实际运行、哪些失败或跳过，以及图表是否已渲染或仅进行了语法审查。切勿声称进行过未发生的测试、渲染或运行时验证。
- 简洁地交付文件位置、主要发布阻塞项和覆盖限制。将修复的实施留给授权的后续行动，除非请求中已包含。