Security Architect 是一个整合型安全技能，覆盖完整的安全生命周期：威胁建模、安全设计原则、安全编码实践与法规合规。其目标是确保安全从项目一开始就被纳入设计，而不是在最后阶段才附加。该技能由四个原有技能整合而成：threat-modeling（STRIDE 威胁分析与风险评估）、security-first-design（安全原则与安全设计模式）、secure-coding-review（OWASP Top 10 与漏洞检测）、compliance-validator（GDPR、HIPAA、SOC2、PCI-DSS 合规）。
适用场景
在以下情况使用 Security Architect：启动新项目（设计阶段）；进行安全架构评审；审查代码中的安全漏洞；确保法规合规；响应安全事件；规划安全认证（SOC2、ISO 27001）；设计认证与授权系统。
主要能力
威胁建模：应用 STRIDE 方法论识别威胁，评估风险等级（可能性 × 影响），创建威胁模型与缓解计划，识别攻击面与信任边界。
安全设计：应用安全原则（纵深防御、最小权限、零信任），设计安全的认证与授权，实现加密与密钥管理，设计安全的 API 与数据保护。
安全编码：依据 OWASP Top 10 审查代码，检测注入漏洞（SQL、XSS、命令注入），识别失效的认证与访问控制，确保安全的数据处理与验证。
合规验证：确保符合 GDPR、HIPAA、CCPA、SOC2、PCI-DSS，实现数据主体权利（访问、删除、可携带），设计审计日志与保留策略，配置加密与访问控制。
工作流程
第一部分：威胁建模（STRIDE）
STRIDE 框架包含六类威胁：Spoofing（身份伪造，对应认证）、Tampering（篡改，对应完整性）、Repudiation（抵赖，对应问责）、Information Disclosure（信息泄露，对应机密性）、Denial of Service（拒绝服务，对应可用性）、Elevation of Privilege（权限提升，对应授权）。每类威胁均给出示例与缓解措施，例如身份伪造可通过多因素认证（MFA）、强密码策略、短过期 JWT、安全会话管理缓解；篡改可通过输入验证与净化、全站 HTTPS/TLS、签名令牌、哈希完整性校验缓解；抵赖可通过全面审计日志、交易数字签名、不可变日志存储、用户行为追踪缓解；信息泄露可通过静态与传输加密、最小权限、密钥管理（AWS Secrets Manager、Vault）、RBAC 缓解；拒绝服务可通过限流与节流、输入验证、自动扩展、CDN 与 DDoS 防护（Cloudflare）缓解；权限提升可通过每个请求的授权检查、最小权限、ABAC、定期权限审计缓解。
威胁建模流程分为五步：识别资产（用户数据、业务数据、系统凭据、基础设施）；识别信任边界（用户↔Web 应用、Web 应用↔API、API↔数据库、内部服务↔外部 API、管理员↔生产系统）；对每个边界应用 STRIDE 提问；评估风险（风险 = 可能性 × 影响，可能性分高/中/低，影响分严重/高/中/低，风险等级分严重/高/中/低并对应处理时限）；定义缓解措施（记录缓解策略、实施成本、残余风险、负责人与时间线）。
第二部分：安全优先设计
五项安全原则：纵深防御（多层安全控制，如防火墙、认证、授权、加密、审计日志）；最小权限（用户/系统仅拥有所需最小权限）；零信任（永不信任、始终验证，内部网络也不可信）；默认安全（默认配置即安全，用户需主动选择较低安全选项）；安全失败（出错时以不损害安全的方式失败，如拒绝访问、记录错误但不向用户暴露细节）。
安全设计模式涵盖：认证（OAuth 2.0 + OpenID Connect，使用 Auth0、AWS Cognito 或 Okta，短过期 JWT，安全令牌存储，敏感操作 MFA）；授权（RBAC 或 ABAC，定义角色，每个 API 请求检查授权，中间件如 @requireRole('admin')，IDOR 防护）；数据保护（传输 TLS 1.3，静态 AES-256，密钥管理服务，加密 PII 字段）；API 安全（限流、认证、输入验证，如每用户每分钟 100 请求，服务间 API 密钥，用户到服务 OAuth 令牌，白名单允许值）；密钥管理（永不提交密钥，使用 AWS Secrets Manager 或 HashiCorp Vault，环境变量配置，定期轮换密钥，使用 IAM 角色）。
第三部分：安全编码审查（OWASP Top 10）
覆盖 OWASP Top 10（2021）：A01 失效的访问控制（URL 篡改、缺少授权检查、IDOR，示例给出坏代码与好代码对比）；A02 加密失败（明文密码、HTTP 代替 HTTPS、弱哈希，示例展示 bcrypt 哈希）；A03 注入（SQL 注入、XSS、命令注入，示例展示参数化查询与 DOMPurify 净化）；A04 不安全设计（无限流、缺少威胁建模、无安全需求）；A05 安全配置错误（默认管理员密码、目录列表、生产环境堆栈跟踪，示例展示通用错误消息）；A06 易受攻击和过时的组件（使用 npm audit、Dependabot）；A07 身份识别和认证失败（弱密码、无 MFA）；A08 软件和数据完整性失败（供应链攻击）；A09 安全日志和监控失败（无审计日志）；A10 服务器端请求伪造（SSRF，验证 URL）。
第四部分：合规验证
GDPR（欧盟数据主体）：合法处理依据、数据主体权利（访问、更正、删除、可携带）、隐私设计与默认、72 小时数据泄露通知、高风险处理需 DPIA。实施清单包括同意机制、DSAR 流程、删除权实现、数据可携带导出、隐私政策与 Cookie 横幅、与供应商的 DPA、泄露通知流程。
HIPAA（美国医疗数据）：PHI 必须加密、访问控制与审计日志、BAA、泄露通知。实施清单包括静态 AES-256 与传输 TLS 1.3 加密 PHI、基于角色的 PHI 访问控制、所有 PHI 访问的审计日志、与云提供商的 BAA、泄露通知流程、定期安全风险评估。
SOC 2（处理客户数据的 SaaS 公司）：信任服务标准（安全、可用性、机密性）、访问控制与监控、变更管理、事件响应。实施清单包括安全政策文档、员工背景调查、强制 MFA、静态与传输加密、审计日志与监控、事件响应计划、供应商管理计划、定期安全培训。
PCI-DSS（处理信用卡数据的组织）：永不存储 CVV/CVC、加密持卡人数据、定期更新与修补系统、限制对持卡人数据的访问。实施清单包括使用支付处理器（Stripe、Braintree）而非自行存储卡、如存储则使用令牌化、PCI 合规托管、网络分段、漏洞扫描与渗透测试、强访问控制。
示例
示例一：SaaS 应用威胁模型。以项目管理 SaaS 为例，资产包括用户凭据、项目数据、支付信息、API 密钥；信任边界包括用户浏览器↔Web 应用、Web 应用↔API 服务器、API 服务器↔数据库、API 服务器↔Stripe API。对边界一进行 STRIDE 分析，列出威胁、风险与缓解措施，并给出优先缓解项：实施 MFA、添加限流、启用 CSP 头。
示例二：安全代码审查发现。审查用户认证端点，发现严重问题 SQL 注入（A03）、高危明文密码（A02）、中危无限流（A04），并给出推荐修复代码。行动建议：部署前修复严重与高危问题，上线后处理中危问题。
示例三：GDPR 合规实现。实现数据主体权利，包括访问权（DSAR）的数据导出接口示例，以及删除权（匿名化而非删除以保留法律合规）的接口示例。
限制
资料未提供该技能的具体安装方式、支持的平台、收费模式或价格信息，暂未提供。