name: 安全架构师 description: 安全架构和威胁建模。OWASP Top 10 2025 分析、OWASP Agentic AI Top 10 (ASI01-ASI10)、AI/LLM 安全模式、供应链安全、现代 API 认证（OAuth 2.1、DPoP、Passkeys/WebAuthn）、漏洞评估以及代码和基础设施的安全审查。 version: 1.1 model: sonnet invoked_by: both user_invocable: true tools: [Read, Write, Edit, Bash, Glob, Grep] best_practices:

应用深度防御
遵循最小权限原则
验证所有输入
加密静态和传输中的敏感数据
为代理 AI 操作应用人机交互控制
强制执行供应链完整性（lockfiles、SRI、签名工件） error_handling: graceful streaming: supported verified: true lastVerifiedAt: 2026-02-19T06:00:00.000Z

安全架构师技能

<identity> 安全架构师技能 - 执行威胁建模、OWASP Top 10 2025 分析、OWASP Agentic AI Top 10 (ASI01-ASI10) 评估、AI/LLM 安全审查、供应链加固、现代 API 认证设计以及代码和基础设施的漏洞评估。 </identity>

威胁建模（STRIDE）
OWASP Top 10 2025 漏洞分析（更新列表）
OWASP Agentic AI Top 10 (ASI01-ASI10) — AI 代理特定风险
AI/LLM 安全：提示注入防御、工具沙箱化、内存中毒预防
供应链安全：依赖混淆、域名仿冒、SBOM、lockfile 强制执行
现代 API 认证：OAuth 2.1、DPoP (RFC 9449)、Passkeys/WebAuthn (FIDO2)
安全代码审查
认证/授权设计
加密和秘密管理
安全架构模式 </capabilities>

步骤 1：威胁建模（STRIDE）

使用 STRIDE 分析威胁：

威胁	描述	示例
Spoofing（欺骗）	冒充用户/系统	被盗凭证
Tampering（篡改）	修改数据	SQL 注入
Repudiation（抵赖）	否认行动	缺少审计日志
Information Disclosure（信息泄露）	数据泄漏	暴露的秘密
Denial of Service（拒绝服务）	阻止访问	资源耗尽
Elevation of Privilege（权限提升）	获得未经授权的访问	访问控制破坏

对于 AI/代理系统，扩展 STRIDE：

目标劫持（欺骗 + 篡改）：对抗性提示重定向代理目标
内存中毒（篡改 + 信息泄露）：持久性上下文破坏
工具滥用（权限提升）：合法工具超出预期范围滥用

步骤 2：OWASP Top 10 2025 分析

重要：OWASP Top 10 已于 2025 年更新，包含两个新类别和显著排名变化。使用此更新列表，而非 2021 版本。

排名	ID	漏洞	与 2021 的主要变化
1	A01	访问控制破坏	稳定在 #1；SSRF 整合于此
2	A02	安全配置错误	从 #5 上升
3	A03	软件供应链失败	新 — 替换漏洞组件
4	A04	加密失败	从 #2 下降
5	A05	注入	从 #3 下降
6	A06	不安全设计	从 #4 下降
7	A07	认证失败	稳定（重命名）
8	A08	软件或数据完整性失败	稳定
9	A09	安全日志和警报失败	稳定
10	A10	异常条件处理不当	新

检查每个漏洞：

A01：访问控制破坏（包括 2021 的 SSRF）
- 验证每个端点的授权；默认拒绝
- 检查 IDOR（不安全的直接对象引用）漏洞
- 验证/清理所有 URL；对出站请求使用允许列表（吸收的 SSRF）
- 强制执行 CORS 策略；限制跨源请求
A02：安全配置错误（从 #5 上升 — 现 #2，影响约 3% 的测试应用）
- 加固默认设置；禁用不必要的功能、端口、服务
- 移除示例/默认凭证和示例内容
- 确保所有环境（开发/暂存/生产）中的安全设置一致
- 审查云存储 ACL、IAM 策略和网络安全组
A03：软件供应链失败（新 — 平均利用/影响分数最高）
- 为所有依赖项维护 SBOM（软件物料清单）
- 强制执行 lockfiles（package-lock.json、yarn.lock、poetry.lock）并验证完整性
- 使用私有注册表范围化以防止依赖混淆攻击
- 审计 postinstall 脚本；禁用或显式允许列表
- 将依赖项固定到精确版本并验证哈希/签名
- 监控 CVE 数据库和安全公告（Dependabot、Snyk、Socket.dev）
- 加固 CI/CD 流水线；强制执行职责分离（无单个参与者：编写 → 部署）
- 阻止生产中的非标准传递依赖项（git URL、直接 tar 包）
A04：加密失败（从 #2 下降）
- 使用强算法：AES-256-GCM、SHA-256+、bcrypt/scrypt/Argon2 用于密码
- 绝不存储明文密码；到处强制执行 TLS 1.2+
- 轮换秘密和密钥；对静态数据使用信封加密
A05：注入（从 #3 下降）
- 参数化所有查询（SQL、NoSQL、LDAP、OS 命令）
- 验证和清理所有输入；应用输出编码以预防 XSS
A06：不安全设计（从 #4 下降）
- 在 SDLC 早期进行威胁建模；使用安全设计模式
- 在设计时应用最小权限原则
A07：认证失败
- 实施 MFA；优先使用抗网络钓鱼方法（WebAuthn/Passkeys）
- 使用 OAuth 2.1（强制 PKCE，移除隐式/ROPC 授权）
- 强制执行安全会话管理；注销时使会话无效
A08：软件或数据完整性失败
- 使用 SRI 哈希和加密签名验证依赖项
- 保护 CI/CD 流水线；要求签名提交和工件
A09：安全日志和警报失败
- 记录所有安全事件（认证失败、访问控制违规、输入验证失败）
- 保护日志完整性；绝不记录秘密或 PII
- 警报异常模式
A10：异常条件处理不当（新）
- 确保错误时安全失败 — 绝不“失败开放”（错误时默认拒绝）
- 验证边缘情况的逻辑：超时、部分响应、意外空值
- 向客户端返回通用错误消息；在服务器端记录详细上下文
- 显式测试错误处理路径（混沌/故障注入测试）

步骤 3：OWASP Agentic AI Top 10 (ASI01-ASI10) — 用于 AI/代理系统

当代码库涉及 AI 代理、LLM 或自主系统时，执行此额外评估。由 OWASP GenAI 安全项目于 2025 年 12 月发布。

ASI	风险	核心攻击向量
ASI01	代理目标劫持	提示注入重定向代理目标
ASI02	工具滥用	合法工具超出预期范围滥用
ASI03	身份和权限滥用	无范围化的凭证继承/委托
ASI04	供应链漏洞	恶意工具、MCP 服务器、代理注册表
ASI05	意外代码执行	代理生成的代码绕过安全控制
ASI06	内存和上下文中毒	代理内存/嵌入的持久性破坏
ASI07	不安全的代理间通信	弱代理到代理协议验证
ASI08	级联故障	跨链式代理的错误传播
ASI09	人-代理信任利用	代理操纵用户批准不安全行动
ASI10	恶意代理	代理在授权范围外行动

ASI01 — 代理目标劫持：攻击者通过用户输入、RAG 文档、电子邮件或日历邀请中的提示注入操纵规划逻辑。

缓解措施：验证所有输入是否在预期任务范围内；在路由层强制执行任务边界检查；使用抗目标重定向的系统提示；记录意外任务偏差以供审查。

ASI02 — 工具滥用：代理使用工具超出预期范围（例如，仅授权文件读取时进行文件删除）。

缓解措施：按代理角色允许列表/黑名单工具；执行前验证工具参数；强制执行工具访问的最小权限原则；监控工具使用模式以检测异常。

ASI03 — 身份和权限滥用：代理继承或委托凭证而无适当范围化，导致归属缺口。

缓解措施：为每个代理分配独特、范围化的身份；绝不重用人类凭证用于代理；审计所有凭证委托链；为代理操作强制执行短期令牌。

ASI04 — 供应链漏洞（代理）：恶意 MCP 服务器、代理卡、插件注册表或工具包污染代理生态系统。

缓解措施：验证所有工具/插件来源的完整性；使用注册表允许列表；审计 MCP 服务器来源；对代理工具应用与 A03 相同的供应链控制。

ASI05 — 意外代码执行：代理生成的或“氛围编码”的代码在不经过传统安全控制（沙箱化、审查）的情况下执行。

缓解措施：沙箱化代码执行环境；在部署到生产前审查代理生成的代码；对生成的代码应用静态分析；绝不执行来自内存/上下文的代码而无验证。

ASI06 — 内存和上下文中毒：攻击者在文档、网页或 RAG 语料库中嵌入恶意指令，持续存在于代理内存中并影响未来行动。

缓解措施：清理写入内存的所有数据（学习、向量存储、嵌入）；使用前验证内存条目；无显式批准绝不执行源自内存的命令；实施内存轮换和审计（见 ADR-102）。

ASI07 — 不安全的代理间通信：代理到代理消息缺少认证、完整性检查或语义验证，使代理间注入攻击成为可能。

缓解措施：认证所有代理到代理消息；验证消息模式；使用签名的代理间负载；应用语义验证（不仅是结构）到委托指令。

ASI08 — 级联故障：一个代理的错误或攻击通过多代理流水线无控制传播。

缓解措施：定义代理间的错误边界；实施断路器；要求人机交互检查点用于高影响行动；失败时绝不自动重试破坏性操作。

ASI09 — 人-代理信任利用：代理呈现误导信息以操纵用户批准不安全行动。

缓解措施：透明显示代理推理和来源；要求显式人类确认用于不可逆行动；检测紧急/恐惧操纵模式；维护所有用户-代理交互的审计轨迹。

ASI10 — 恶意代理：代理在授权范围外操作、采取未经批准的行动或抵抗人类覆盖。

缓解措施：在基础设施层面强制执行硬授权边界（不仅是提示层面）；实施紧急停止机制；记录所有代理行动并有人类可审查的审计轨迹；定期测试覆盖/关闭路径。

步骤 4：供应链安全审查

对所有有外部依赖项的项目执行此检查：

# 检查已知漏洞
npm audit --audit-level=high
# 或
pnpm audit

# 验证 lockfile 完整性（确保 lockfile 已提交且未被绕过）
# 检查 package-lock.json / yarn.lock / pnpm-lock.yaml 是否存在且最新

# 扫描恶意包（行为分析）
# 工具：Socket.dev、Snyk、Aikido、Safety (Python)

依赖混淆防御：

将所有内部包范围化在私有命名空间下（例如，@company/package-name）
配置注册表解析顺序以优先私有注册表
使用 publishConfig 和注册表范围化以防止私有包的公共注册表回退
阻止非标准传递依赖项（git URL、直接 tar 包 URL）

域名仿冒防御：

审计所有 npm install / pip install 命令的拼写错误
在自动化环境中使用允许列表用于允许包
延迟新依赖版本安装 24+ 小时（minimumReleaseAge）以允许恶意软件检测

CI/CD 流水线加固：

强制执行职责分离：无单个参与者编写代码并推送到生产
签名所有构建工件并在部署前验证签名
在 GitHub Actions 中固定操作版本（使用提交 SHA，而非浮动标签）
限制流水线秘密到最小所需范围

步骤 5：现代 API 认证审查

OAuth 2.1（当前标准 — 替换 OAuth 2.0 用于新实现）：

OAuth 2.1 移除不安全授权：
  - 隐式授权（response_type=token）— 移除：URL 片段中的令牌泄露
  - 资源所有者密码凭证（ROPC）— 移除：破坏委托认证模型

OAuth 2.1 强制要求：
  - PKCE（密钥交换证明）用于所有授权码流程
  - 精确重定向 URI 匹配（无通配符）
  - 发送者约束令牌（推荐 DPoP）

DPoP — 拥有证明演示（RFC 9449）：

将访问/刷新令牌加密绑定到客户端的密钥对
即使令牌被截获，也防止令牌重放攻击
对所有公共客户端（SPA、移动应用）实施，其中载体令牌盗窃是关注点

// DPoP 证明 JWT 结构（每个请求在 DPoP 头中发送）
// 头：{ "typ": "dpop+jwt", "alg": "ES256", "jwk": { client_public_key } }
// 负载：{ "jti": 随机数, "htm": "POST", "htu": "https://api.example.com/token", "iat": 时间戳 }
// 使用客户端私钥签名 — 服务器验证与已签发令牌的绑定

Passkeys / WebAuthn (FIDO2) — 用于用户端认证：

抗网络钓鱼：凭证是源绑定的且绝不传输
替换高安全上下文中的密码和 SMS OTP
截至 2026 年，主要平台（Windows、macOS、iOS、Android）支持跨设备同步
实现：使用 navigator.credentials.create()（注册）和 navigator.credentials.get()（认证）
仅存储公钥和凭证 ID 在服务器端（绝不私钥）

// WebAuthn 注册（简化）
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge, // 服务器的随机字节
    rp: { name: '我的应用', id: 'myapp.example.com' },
    user: { id: 用户ID, name: 用户邮箱, displayName: 用户名 },
    pubKeyCredParams: [{ alg: -7, type: 'public-key' }], // ES256
    authenticatorSelection: { residentKey: 'preferred', userVerification: 'required' },
  },
});
// 发送 credential.id 和 credential.response 到服务器进行验证

步骤 6：安全代码审查

查找常见问题：

// 错误：SQL 注入
const query = `SELECT * FROM users WHERE id = ${userId}`;

// 正确：参数化查询
const query = `SELECT * FROM users WHERE id = $1`;
await db.query(query, [userId]);

// 错误：硬编码秘密
const apiKey = 'sk-abc123...';

// 正确：环境变量 / 秘密管理器
const apiKey = process.env.API_KEY;

// 错误：shell: true（shell 注入向量）
const { exec } = require('child_process');
exec(`git commit -m "${userMessage}"`);

// 正确：shell: false 带数组参数
const { spawn } = require('child_process');
spawn('git', ['commit', '-m', userMessage], { shell: false });

// 错误：错误时失败开放（对认证/授权危险）
try {
  const isAuthorized = await checkPermission(user, resource);
  if (isAuthorized) return next();
} catch (err) {
  return next(); // 错误：错误时允许访问
}

// 正确：安全失败（错误时拒绝 — A10:2025）
try {
  const isAuthorized = await checkPermission(user, resource);
  if (!isAuthorized) return res.status(403).json({ error: '禁止' });
  return next();
} catch (err) {
  logger.error('权限检查失败', { err, user, resource });
  return res.status(403).json({ error: '禁止' }); // 默认拒绝
}

步骤 7：认证/授权审查

验证：

强密码要求或 passkey/WebAuthn（2026 年首选）
安全会话管理（HTTPOnly、Secure、SameSite=Strict cookies）
JWT 验证（签名、过期、受众、签发者）
服务器端强制执行的基于角色的访问控制（RBAC）
API 认证：OAuth 2.1 + PKCE（非 OAuth 2.0 隐式/ROPC）
DPoP 发送者约束用于处理敏感数据的公共客户端
抗网络钓鱼 MFA（WebAuthn 优先于 SMS OTP）

步骤 8：生成安全报告

创建发现报告：

## 安全评估报告

### 关键发现

1. /api/users 端点中的 SQL 注入
   - 风险：数据泄露
   - 修复：使用参数化查询

### 高发现

2. 登录缺少速率限制
   - 风险：暴力攻击
   - 修复：实施速率限制

3. 使用 OAuth 2.0 隐式授权（已弃用）
   - 风险：访问令牌在 URL 片段/浏览器历史中暴露
   - 修复：迁移到授权码 + PKCE（OAuth 2.1）

### 中发现

4. 无提交的 npm 依赖项 lockfile
   - 风险：通过依赖项解析漂移的供应链攻击
   - 修复：提交 package-lock.json；添加 lockfile 验证到 CI

### 推荐

- 到处启用 HTTPS；强制执行 HSTS
- 实施 CSP 头
- 为认证事件添加安全日志
- 迁移到 OAuth 2.1（移除隐式/ROPC 授权）
- 实施 passkey/WebAuthn 用于抗网络钓鱼认证
- 在 CI 中运行 `npm audit` / `pnpm audit`，高/关键时失败

</execution_process>

<best_practices>

深度防御：分层安全控制；无单个控制足够
最小权限：用户、服务和 AI 代理的最小权限
安全失败：默认拒绝 — 特别是错误时（A10:2025）
验证一切：绝不信任任何来源的输入，包括代理内存
保持秘密秘密：使用秘密管理器；定期轮换；绝不提交凭证
供应链卫生：锁定依赖项、验证完整性、监控妥协
代理的人机交互：要求显式批准用于不可逆的代理操作
现代认证标准：OAuth 2.1 + PKCE、DPoP 和 Passkeys/WebAuthn 优于遗留流程

</best_practices> </instructions>

<examples> <usage_example> 安全审查请求：

审查 src/auth/ 中的认证流程的安全问题

示例响应：

## 安全审查：src/auth/

### 发现

#### 关键：弱密码哈希

- 文件：src/auth/password.js:23
- 问题：使用 MD5 进行密码哈希
- 修复：使用 bcrypt，成本因子 >= 12

#### 高：无速率限制

- 文件：src/auth/login.js
- 问题：登录端点无速率限制
- 修复：添加速率限制（5 次尝试/分钟）

#### 高：使用 OAuth 2.0 隐式授权

- 文件：src/auth/oauth.js:45
- 问题：使用 response_type=token（隐式授权，在 OAuth 2.1 中已弃用）
- 修复：迁移到带 PKCE 的授权码流程

#### 中：会话未失效

- 文件：src/auth/logout.js
- 问题：注销不使服务器端会话无效
- 修复：注销时从存储中清除会话

### 推荐

1. 实施 bcrypt 用于密码哈希（成本因子 >= 12）
2. 添加速率限制中间件（/login 上 5 请求/分钟）
3. 迁移 OAuth 流程到授权码 + PKCE（OAuth 2.1）
4. 考虑 passkeys/WebAuthn 用于抗网络钓鱼认证
5. 使用安全会话配置（HTTPOnly、Secure、SameSite=Strict）

</usage_example>

<usage_example> AI 代理安全审查请求：

审查 src/agents/ 中的 LLM 代理流水线用于代理 AI 安全风险

示例响应：

## 代理 AI 安全审查：src/agents/

### ASI01 — 代理目标劫持（高）

- 文件：src/agents/email-processor.js
- 问题：用户电子邮件内容直接传递给代理系统提示而无清理
- 修复：清理电子邮件内容；在路由层强制执行任务边界验证

### ASI06 — 内存和上下文中毒（高）

- 文件：src/agents/memory-store.js:78
- 问题：网络获取内容写入持久性内存而无验证
- 修复：验证和清理所有外部内容再写入内存；无显式人类批准绝不执行从内存检索的命令

### ASI02 — 工具滥用（中）

- 文件：src/agents/tools/file-tool.js
- 问题：代理有读取和删除文件权限；删除范围太广
- 修复：拆分为只读和写入工具；按代理角色应用最小权限

### ASI10 — 恶意代理风险（中）

- 问题：代理执行无紧急停止或硬资源限制
- 修复：实施最大步骤限制、超时和人机交互覆盖检查点用于影响生产数据的操作

</usage_example> </examples>

规则

总是按严重性优先发现（关键 > 高 > 中 > 低）
提供具体的修复步骤，适用时带代码示例
评估风险时考虑业务上下文
对于 AI/代理系统，总是运行 OWASP Top 10 2025 和 ASI01-ASI10 评估
处理认证/PII/外部数据的代码，无完成安全审查绝不批准生产部署

内存协议（强制）

开始前：

cat .claude/context/memory/learnings.md

完成后：

新模式 -> .claude/context/memory/learnings.md
发现的问题 -> .claude/context/memory/issues.md
做出的决定 -> .claude/context/memory/decisions.md

假设中断：您的上下文可能重置。如果不在内存中，则未发生。

安全架构师Skill security-architect