威胁建模代理

解决的问题

大多数团队把安全审查推迟到代码写完之后。等到渗透测试或生产事故暴露架构级漏洞时，修复成本已经翻了数十倍——一个在设计阶段就能识别的信任边界缺陷，上线后可能需要重构核心数据流才能修补。

核心能力与工作流

@user_3c6cb52e/threat-modeling-skillhub 让代理能够系统地分解系统架构，识别信任边界，并应用业界成熟的方法论生成结构化的威胁登记册：

• 分解架构 — 分析架构图、代码库和基础设施即代码，生成数据流图（DFD），标注网络、服务和权限级别的信任边界
• 选择方法论 — STRIDE 做系统性威胁类别枚举，DREAD 做风险评分，PASTA 做业务对齐的风险分析，攻击树针对高价值目标做深度拆解
• 枚举与评估 — 为每个组件和数据流应用选定方法论，用 DREAD 框架量化风险，结合业务上下文排序（支付服务的威胁优先于内部管理面板）
• 定义缓解措施 — 对每个高/中优先级威胁给出具体的缓解策略，映射到 NIST 800-53、CIS Controls 等框架，并估算实施工作量
• 维护活文档 — 生成包含 DFD、威胁登记册、风险评分和缓解状态的持续更新文档，整合到冲刺规划和设计评审中

支持的架构类型包括单体应用、微服务、无服务器、事件驱动、移动后端和物联网系统；基础设施覆盖 AWS、GCP、Azure、Kubernetes 和混合环境。

适用边界与注意点

• 威胁建模的价值取决于输入质量——代理需要访问架构文档、源代码或系统描述才能产出有意义的结果
• 共享数据库的微服务中，信任边界天然模糊，需要将每个服务对数据库的访问建模为独立边界
• 第三方 API 集成引入了超出控制范围的威胁，应将外部服务视为不受信任数据源
• 频繁部署的系统不能只依赖季度审查，需将轻量级威胁评估嵌入 PR 流程
• 每个缓解措施都应成为有负责人和截止日期的可追踪工作项，否则威胁模型只是一纸空文