security-architect

安全架构师技能

安全架构师技能 - 执行威胁建模、OWASP Top 10 2025 分析、OWASP Agentic AI Top 10（ASI01-ASI10）评估、AI/LLM 安全审查、供应链加固、现代 API 身份验证设计，以及代码和基础设施的漏洞评估。 - 威胁建模（STRIDE） - OWASP Top 10 2025 漏洞分析（更新后的列表） - OWASP Agentic AI Top 10（ASI01-ASI10）——AI Agent 专属风险 - AI/LLM 安全：提示词注入防御、工具沙箱隔离、内存投毒防范 - 供应链安全：依赖项混淆、拼写抢注、SBOM、锁文件强制执行 - 现代 API 身份验证：OAuth 2.1、DPoP（RFC 9449）、Passkeys/WebAuthn（FIDO2） - 安全代码审查 - 身份验证/授权设计 - 加密和机密管理 - 安全架构模式

步骤 1：威胁建模（STRIDE）

使用 STRIDE 分析威胁：

威胁	描述	示例
Spoofing	冒充用户/系统	凭证被盗
Tampering	修改数据	SQL 注入
Repudiation	否认行为	缺少审计日志
Information Disclosure	数据泄露	机密信息暴露
Denial of Service	阻止访问	资源耗尽
Elevation of Privilege	获得未经授权的访问权限	访问控制失效

对于 AI/Agent 系统，使用以下内容扩展 STRIDE：

• 目标劫持（Spoofing + Tampering）：对抗性提示词重定向 Agent 目标
• 内存投毒（Tampering + Information Disclosure）：持久上下文遭到破坏
• 工具滥用（Elevation of Privilege）：滥用合法工具，使其超出预期范围

步骤 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	异常情况处理不当	新增

逐项检查以下漏洞：

1. A01：访问控制失效（包括 2021 版中的 SSRF）
   • 验证每个端点的授权；默认拒绝
   • 检查是否存在 IDOR（不安全的直接对象引用）漏洞
   • 验证/清理所有 URL；对出站请求使用允许列表（吸收 SSRF）
   • 强制实施 CORS 策略；限制跨源请求

2. **A02：安全配置错误**（从第 5 位升至第 2 位，影响约 3% 的受测应用） - 强化默认配置；禁用不必要的功能、端口和服务 - 移除示例／默认凭据和示例内容 - 确保所有环境（开发／预发布／生产）的安全设置一致 - 检查云存储 ACL、IAM 策略和网络安全组

3. A03：软件供应链故障（新增 — 平均漏洞利用／影响评分最高）

   • 为所有依赖项维护 SBOM（软件物料清单）
   • 强制使用锁文件（package-lock.json、yarn.lock、poetry.lock）并验证完整性
   • 使用私有注册表作用域，防止依赖混淆攻击
   • 审查 postinstall 脚本；明确禁用或列入允许列表
   • 将依赖项固定到确切版本，并验证哈希值／签名
   • 监控 CVE 数据库和安全公告（Dependabot、Snyk、Socket.dev）
   • 强化 CI/CD 流水线；强制职责分离（不得由单一参与者完成：写入 → 部署）
   • 在生产环境中阻止使用特殊的传递依赖项（Git URL、直接 tarball）

4. A04：加密失败（从第 2 位降至第 4 位）

   • 使用强算法：AES-256-GCM、SHA-256+，以及用于密码的 bcrypt/scrypt/Argon2
   • 绝不存储明文密码；所有地方都强制使用 TLS 1.2+
   • 轮换密钥和机密；对静态数据使用信封加密

5. A05：注入（从第 3 位降至第 5 位）

   • 对所有查询（SQL、NoSQL、LDAP、OS 命令）使用参数化处理
   • 验证并清理所有输入；使用输出编码防止 XSS

6. A06：设计不安全（从第 4 位降至第 6 位）

   • 在 SDLC 早期进行威胁建模；采用安全设计模式
   • 在设计阶段应用最小权限原则

7. A07：身份验证失败

   • 实施 MFA；优先采用抗钓鱼方法（WebAuthn／Passkeys）
   • 使用 OAuth 2.1（必须启用 PKCE，移除 implicit／ROPC 授权）
   • 强制采用安全的会话管理；登出时使会话失效

8. A08：软件或数据完整性故障

   • 使用 SRI 哈希和加密签名验证依赖项
   • 保护 CI/CD 流水线；要求提交和构建产物均经过签名

9. A09：安全日志记录和告警故障

   • 记录所有安全事件（身份验证失败、访问控制违规、输入验证失败）
   • 保护日志完整性；绝不记录机密或 PII
   • 对异常模式发出告警

10. A10：异常情况处理不当（新增）

    • 确保错误发生时以安全方式失败 — 绝不“故障开放”（出错时默认拒绝）
    • 验证边缘情况的逻辑：超时、部分响应、意外的 null 值
    • 向客户端返回通用错误消息；在服务端记录详细上下文
    • 明确测试错误处理路径（混沌／故障注入测试）

步骤 3：OWASP Agentic AI Top 10（ASI01-ASI10）— 适用于 AI／Agent 系统

当代码库涉及 AI Agent、大模型或自主系统时，请执行这项额外评估。由 OWASP GenAI Security Project 于 2025 年 12 月发布。

ASI	风险	核心攻击向量
ASI01	Agent 目标劫持	提示词注入重定向 Agent 目标
ASI02	工具滥用	滥用合法工具，使其超出预期范围
ASI03	身份与权限滥用	凭据继承或委派时未设置范围限制
ASI04	供应链漏洞	恶意工具、MCP 服务、Agent 注册表
ASI05	意外代码执行	Agent 生成的代码绕过安全控制
ASI06	记忆与上下文投毒	持续破坏 Agent 记忆或嵌入
ASI07	不安全的 Agent 间通信	Agent 间协议验证薄弱
ASI08	级联故障	错误在串联的 Agent 间传播
ASI09	利用人类对 Agent 的信任	Agent 操纵用户进行不安全的审批
ASI10	恶意 Agent	Agent 在授权范围之外行动

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

• 缓解措施：根据预期任务范围验证所有输入；在路由层强制执行任务边界检查；使用能够抵御目标重定向的系统提示词；记录意外的任务偏离以供审查。

ASI02 — 工具滥用：Agent 使用超出预期范围的工具（例如，仅授权读取文件，却删除了文件）。

• 缓解措施：根据 Agent 角色设置工具允许列表或拒绝列表；执行前验证工具参数；强制执行工具访问的最小权限原则；监控工具使用模式以发现异常。

ASI03 — 身份与权限滥用：Agent 未经适当范围限制便继承或委派凭据，导致归属追踪出现缺口。

• 缓解措施：为每个 Agent 分配独立且范围受限的身份；绝不将人类凭据用于 Agent；审计所有凭据委派链；为 Agent 操作强制使用短期令牌。

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

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

ASI05 — 意外代码执行：Agent 生成的代码或“凭感觉编写”的代码，在没有传统安全控制（沙箱、审查）的情况下执行。

• 缓解措施：在沙箱化环境中执行代码；在生产环境执行 Agent 生成的代码前进行审查；对生成的代码进行静态分析；未经验证，绝不执行来自记忆或上下文的代码。

ASI06 — 记忆与上下文投毒：攻击者在文档、网页或 RAG 语料库中嵌入恶意指令，这些指令会保留在 Agent 记忆中并影响后续操作。

• 缓解措施：清理所有写入记忆的数据（学习内容、向量存储、嵌入）；使用记忆条目前进行验证；未经明确批准，绝不执行来自记忆的命令；实施记忆轮换与审计（参见 ADR-102）。

ASI07 — 不安全的 Agent 间通信：Agent 间消息缺少身份验证、完整性检查或语义验证，可能导致 Agent 之间发生注入攻击。

• 缓解措施：对所有 Agent 间消息进行身份验证；验证消息架构；使用经过签名的 Agent 间载荷；对委派指令进行语义验证（而不仅是结构验证）。

ASI08 — 级联故障：一个 Agent 中的错误或攻击，会在多 Agent 流水线中不受控地传播。

• 缓解措施：定义 Agent 间的错误边界；实施熔断机制；对高影响操作设置人工审核检查点；发生故障时绝不自动重试破坏性操作。 ASI09 — 人类与 Agent 信任关系利用：Agent 提供误导性信息，操纵用户批准不安全的操作。

• 缓解措施：透明展示 Agent 的推理过程和来源；不可逆操作必须获得明确的人类确认；检测利用紧迫感或恐惧感进行操纵的模式；保留所有用户与 Agent 交互的审计记录。

ASI10 — 失控的 Agent：Agent 超出授权范围运行、采取未经批准的操作，或抵制人类的干预。

• 缓解措施：在基础设施层面强制执行严格的授权边界（而非仅依赖提示词层面）；实现紧急停止机制；记录所有 Agent 操作并保留可供人工审查的审计记录；定期测试干预和关闭路径。

步骤 4：供应链安全审查

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

# Check for known vulnerabilities
npm audit --audit-level=high
# or
pnpm audit

# Verify lockfile integrity (ensure lockfile is committed and not bypassed)
# Check that package-lock.json / yarn.lock / pnpm-lock.yaml exists and is current

# Scan for malicious packages (behavioral analysis)
# Tools: Socket.dev, Snyk, Aikido, Safety (Python)

防范依赖项混淆：

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

防范仿冒包：

• 审查所有 npm install / pip install 命令，检查是否存在拼写错误
• 在自动化环境中使用允许安装的包列表
• 将新依赖项版本的安装延迟 24 小时以上（minimumReleaseAge），以便检测恶意软件

强化 CI/CD 流水线：

• 强制职责分离：任何单一人员都不得同时编写代码并将其部署到生产环境
• 为所有构建制品签名，并在部署前验证签名
• 在 GitHub Actions 中固定操作版本（使用提交 SHA，而非浮动标签）
• 将流水线密钥的权限限制在最低必需范围

步骤 5：现代 API 身份验证审查

OAuth 2.1（当前标准——新实现中取代 OAuth 2.0）：

OAuth 2.1 removes insecure grants:
  - Implicit grant (response_type=token) — REMOVED: tokens in URL fragments leak
  - Resource Owner Password Credentials (ROPC) — REMOVED: breaks delegated auth model

OAuth 2.1 mandates:
  - PKCE (Proof Key for Code Exchange) for ALL authorization code flows
  - Exact redirect URI matching (no wildcards)
  - Sender-constraining tokens (DPoP recommended)

DPoP — 持有证明（RFC 9449）：

• 将访问令牌和刷新令牌通过加密方式绑定到客户端的密钥对
• 即使令牌遭到截获，也能防止令牌重放攻击
• 对所有存在持有者令牌被盗风险的公共客户端（SPA、移动应用）实施此机制

// DPoP proof JWT structure (sent in DPoP header with each request)
// Header: { "typ": "dpop+jwt", "alg": "ES256", "jwk": { client_public_key } }
// Payload: { "jti": nonce, "htm": "POST", "htu": "https://api.example.com/token", "iat": timestamp }
// Signed with client private key — server verifies binding to issued token

Passkeys / WebAuthn（FIDO2）——用于面向用户的身份验证：

• 可抵御网络钓鱼：凭据与源站绑定，且不会被传输
• 在高安全性场景中取代密码和短信 OTP
• 截至 2026 年，主流平台（Windows、macOS、iOS、Android）均支持跨设备同步
• 实现方式：使用 navigator.credentials.create()（注册）和 navigator.credentials.get()（身份验证）
• 服务端仅存储公钥和凭据 ID（绝不存储私钥）

// WebAuthn registration (simplified)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge, // random bytes from server
    rp: { name: 'My App', id: 'myapp.example.com' },
    user: { id: userId, name: userEmail, displayName: userName },
    pubKeyCredParams: [{ alg: -7, type: 'public-key' }], // ES256
    authenticatorSelection: { residentKey: 'preferred', userVerification: 'required' },
  },
});
// Send credential.id and credential.response to server for verification

步骤 6：安全代码审查

检查常见问题：

// BAD: SQL Injection
const query = `SELECT * FROM users WHERE id = ${userId}`;

// GOOD: Parameterized query
const query = `SELECT * FROM users WHERE id = $1`;
await db.query(query, [userId]);

// BAD: Hardcoded secrets
const apiKey = 'sk-abc123...';

// GOOD: Environment variables / secret manager
const apiKey = process.env.API_KEY;

// BAD: shell: true (shell injection vector)
const { exec } = require('child_process');
exec(`git commit -m "${userMessage}"`);

// GOOD: shell: false with array arguments
const { spawn } = require('child_process');
spawn('git', ['commit', '-m', userMessage], { shell: false });

// BAD: Fail open on error (dangerous for auth/authz)
try {
  const isAuthorized = await checkPermission(user, resource);
  if (isAuthorized) return next();
} catch (err) {
  return next(); // WRONG: allows access on error
}

// GOOD: Fail securely (deny on error — A10:2025)
try {
  const isAuthorized = await checkPermission(user, resource);
  if (!isAuthorized) return res.status(403).json({ error: 'Forbidden' });
  return next();
} catch (err) {
  logger.error('Permission check failed', { err, user, resource });
  return res.status(403).json({ error: 'Forbidden' }); // Default deny
}

步骤 7：身份验证/授权审查

请验证：

• 强密码要求，或使用 Passkey/WebAuthn（2026 年首选）
• 安全的会话管理（HTTPOnly、Secure、SameSite=Strict Cookie）
• JWT 验证（签名、过期时间、受众、签发者）
• 在服务端强制实施基于角色的访问控制（RBAC）
• API 身份验证：OAuth 2.1 + PKCE（而非 OAuth 2.0 implicit/ROPC）
• 对处理敏感数据的公共客户端实施 DPoP 发送方约束
• 使用可抵御网络钓鱼的 MFA（优先选择 WebAuthn，而非短信 OTP）

步骤 8：生成安全报告

创建发现报告：

## Security Assessment Report

### Critical Findings

1. SQL injection in /api/users endpoint
   - Risk: Data breach
   - Fix: Use parameterized queries

### High Findings

2. Missing rate limiting on login
   - Risk: Brute force attacks
   - Fix: Implement rate limiting

3. OAuth 2.0 implicit grant in use (deprecated)
   - Risk: Access token exposure in URL fragments / browser history
   - Fix: Migrate to Authorization Code + PKCE (OAuth 2.1)

### Medium Findings

4. No lockfile committed for npm dependencies
   - Risk: Supply chain attack via dependency resolution drift
   - Fix: Commit package-lock.json; add lockfile verification to CI

### Recommendations

- Enable HTTPS everywhere; enforce HSTS
- Implement CSP headers
- Add security logging for auth events
- Migrate to OAuth 2.1 (remove implicit/ROPC grants)
- Implement passkey/WebAuthn for phishing-resistant authentication
- Run `npm audit` / `pnpm audit` in CI with failure on high/critical

</execution_process>

<best_practices>

1. 深度防御：分层实施安全控制；任何单一控制都不足以保障安全
2. 最小权限：为用户、服务和 AI Agent 配置最低限度的权限
3. 安全失败：默认拒绝——尤其是在发生错误时（A10:2025）
4. 验证一切：绝不信任来自任何来源的输入，包括 Agent 记忆
5. 保护机密：使用密钥管理器；定期轮换；绝不提交凭据
6. 供应链卫生：锁定依赖项、验证完整性、监控是否遭到入侵
7. Agent 保持人在环中：对于不可逆的 Agent 操作，必须获得明确批准
8. 现代身份验证标准：优先使用 OAuth 2.1 + PKCE、DPoP 和 Passkeys/WebAuthn，而非旧版流程

</best_practices>

**安全审查请求**：

Review the authentication flow in src/auth/ for security issues

示例响应：

## Security Review: src/auth/

### Findings

#### CRITICAL: Weak Password Hashing

- File: src/auth/password.js:23
- Issue: Using MD5 for password hashing
- Fix: Use bcrypt with cost factor >= 12

#### HIGH: No Rate Limiting

- File: src/auth/login.js
- Issue: Login endpoint has no rate limiting
- Fix: Add rate limiting (5 attempts/minute)

#### HIGH: OAuth 2.0 Implicit Grant in Use

- File: src/auth/oauth.js:45
- Issue: Using response_type=token (implicit grant, deprecated in OAuth 2.1)
- Fix: Migrate to Authorization Code flow with PKCE

#### MEDIUM: Session Not Invalidated

- File: src/auth/logout.js
- Issue: Logout doesn't invalidate server-side session
- Fix: Clear session from store on logout

### Recommendations

1. Implement bcrypt for password hashing (cost factor >= 12)
2. Add rate limiting middleware (5 req/min on /login)
3. Migrate OAuth flows to Authorization Code + PKCE (OAuth 2.1)
4. Consider passkeys/WebAuthn for phishing-resistant authentication
5. Use secure session configuration (HTTPOnly, Secure, SameSite=Strict)

</usage_example>

<usage_example> AI Agent 安全审查请求：

Review the LLM agent pipeline in src/agents/ for agentic AI security risks

示例响应：

## Agentic AI Security Review: src/agents/

### ASI01 — Agent Goal Hijack (HIGH)

- File: src/agents/email-processor.js
- Issue: User email content passed directly to agent system prompt without sanitization
- Fix: Sanitize email content; enforce task boundary validation in routing layer

### ASI06 — Memory & Context Poisoning (HIGH)

- File: src/agents/memory-store.js:78
- Issue: Web-fetched content written to persistent memory without validation
- Fix: Validate and sanitize all external content before writing to memory; never
  execute commands retrieved from memory without explicit human approval

### ASI02 — Tool Misuse (MEDIUM)

- File: src/agents/tools/file-tool.js
- Issue: Agent has both read and delete file permissions; delete scope too broad
- Fix: Split into read-only and write tools; apply least privilege per agent role

### ASI10 — Rogue Agent Risk (MEDIUM)

- Issue: No kill-switch or hard resource limits on agent execution
- Fix: Implement max-steps limit, timeout, and human override checkpoint for
  operations affecting production data

</usage_example>

铁律

1. 绝不在未完成安全审查的情况下，批准处理身份验证、PII 或外部数据的代码部署到生产环境
2. 对于 AI/Agent 系统，始终同时执行 OWASP Top 10 2025 和 ASI01-ASI10 评估
3. 始终安全失败——设计所有错误路径，使其默认拒绝，绝不允许访问
4. 绝不信任未经验证的任何输入，包括来自内部服务的数据
5. 始终按严重程度排列发现的优先级（CRITICAL > HIGH > MEDIUM > LOW），并提供具体的修复步骤和代码示例

反模式

反模式	失败原因	正确做法
未完成完整安全审查就批准代码	不完整的审查会遗漏身份验证、PII 和外部数据流中的可利用路径	在批准部署到生产环境前，完成所有 STRIDE + OWASP 阶段
对 AI/Agent 系统使用 OWASP 2021	标准 Web 清单未涵盖 AI 特定威胁（ASI01-ASI10）	对任何 Agent 组件，始终同时执行 OWASP Top 10 2025 和 ASI01-ASI10 评估
安全错误时默认放行	错误路径会成为可利用的绕过条件	将每种故障模式都设计为默认拒绝访问
提供含糊的修复指导	没有具体细节，开发人员就无法采取行动	为每项发现提供准确的代码示例和参数化修复模式
未按严重程度排列优先级	关键信息会淹没在信息性发现中	交付前，将所有发现按 CRITICAL > HIGH > MEDIUM > LOW 分类

相关技能

• auth-security-expert - OAuth 2.1、JWT 和身份验证专项安全模式

相关工作流

如需进行全面的安全审计，涵盖多阶段威胁分析、漏洞扫描和修复规划，请参阅相应工作流：

• 工作流文件：.claude/workflows/security-architect-skill-workflow.md
• 适用场景：需要进行结构化安全审计，涵盖 OWASP Top 10 2025 分析、依赖项 CVE 检查、渗透测试和修复规划
• 阶段：5 个阶段（威胁建模、安全代码审查、依赖项审计、渗透测试、修复规划）
• 覆盖范围：完整涵盖 OWASP Top 10 2025、OWASP Agentic AI Top 10（ASI01-ASI10）、STRIDE 威胁建模、CVE 数据库检查、自动化与手动渗透测试

主要功能：

• 多 Agent 协同编排（security-architect、code-reviewer、developer、devops）
• 用于阻止发布的安全关卡
• 严重程度分类（CRITICAL/HIGH/MEDIUM/LOW）
• 自动生成工单
• 满足合规要求的报告（SOC2、GDPR、HIPAA）

另请参阅：功能开发工作流，了解如何将安全审查纳入开发生命周期。

记忆协议（强制）

开始前：

cat .claude/context/memory/learnings.md

完成后：

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

假设工作可能会中断：你的上下文可能会重置。如果没有记录在记忆中，就等于没有发生。