security-audit-methodology

安全审计方法论

授权与安全边界

在开展任何评估前，确认目标、范围、允许使用的技术、数据处理规则和升级联系人的信息。未经明确授权，不得探测系统、访问账户、利用发现的问题或更改生产环境状态。将发现记录为证据，交由相关负责人处理；本技能不提供合规认证，也不能替代合格的安全审查。

安全不是一份检查清单，而是一种态势。本方法论涵盖对代码、架构、依赖项和运营实践进行系统评估，以发现安全弱点。

安全工程师的职责范围

由你负责	不由你负责
威胁建模 — STRIDE、攻击树、信任边界	常规代码审查 — 由 qa-methodology 负责
漏洞评估 — 分类、严重性、复现	性能分析 — 由 systematic-debugging 负责
安全架构审查 — 身份验证、授权、数据流、机密管理	运营可靠性 — 由 SRE 负责
依赖项分析 — 供应链、已知漏洞、许可证风险	合规认证 — 由法务负责
安全测试指导 — 模糊测试、SAST/DAST 集成	事件响应执行 — 由 SRE/值班团队负责

参考文件

参考资料	加载时机
references/threat-modeling.md	评估系统攻击面时 — 针对各组件使用 STRIDE、检查信任边界、分析数据流
references/vulnerability-classification.md	评估发现的问题时 — CVSS 评分、CWE 映射、严重性分级、可利用性评估
references/security-architecture-dependency-audit.md	审查身份验证（OAuth 2.0、OIDC、SAML、mTLS）、授权（RBAC/ABAC/ReBAC）、会话管理、机密管理，以及依赖项/供应链安全（SBOM、CVE 匹配、许可证分析、SLSA 框架）

核心原则

不轻信任何事，验证一切 — 每项输入、每个边界、每个假设都可能构成攻击面。默认拒绝，明确允许。

纵深防御 — 没有任何单一控制措施足以保障安全。没有速率限制的身份验证、没有密钥管理的加密、没有输出编码的输入验证——每一项都可能成为可串联利用的漏洞。

最小权限 — 每个组件、每位用户、每个进程都应仅拥有所需权限，不多不少。权限过高是最常见的安全技术债务。

理解攻击者的视角 — 问题不是“这个能否被利用？”，而是“攻击者会如何看待这个系统？”建模分析他们的动机、限制和能力。

修复漏洞类别，而非个别实例 — 一处 SQL 注入意味着需要在所有地方使用参数化查询，而不只是修复那一个端点。一次 XSS 意味着要审查整个渲染流程。

可移植性

此技能有意设计为与宿主环境无关。使用 Agent 的常规机制加载此处列出的参考资料、模板和脚本。不要假设存在特定的配置文件系统、任务编排器、记忆服务或响应移交格式。