每个代码仓库都需要一个显式威胁模型同步步骤

安全团队的一个老问题：项目启动时做了威胁建模，写了文档，然后再也没人更新它。六个月后，架构早已面目全非，威胁模型还停在第一版。

这不是态度问题，是流程问题。

静态威胁模型为什么会失效

传统威胁建模基于 STRIDE 框架——Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege——在项目早期识别威胁、评估影响、制定防御策略。这套方法在架构相对稳定的时代运转良好。

现代软件不再稳定。微服务架构下，一个中等规模的系统可能包含数十个独立部署的服务，每天都有新的依赖引入、接口变更、权限调整。代码仓库按小时更新，威胁模型却按季度（乐观估计）维护——这中间的 gap，就是攻击者的机会窗口。

持续威胁建模（Continuous Threat Modeling，CTM） 就是为了堵上这个窗口。核心思路是把威胁建模从一次性的文档活动，变成嵌入 CI/CD 流水线的持续过程。

显式同步步骤的意义

"同步步骤"不是一个隐喻，而是字面意义上的 pipeline step——在每次代码变更时，自动检查当前 repo 状态与威胁模型是否仍然对齐。

具体来说，这个步骤应该做以下几件事：

1. 检测架构变化 新增的 API 端点、变更的数据流、引入的第三方依赖——这些都是潜在的攻击面扩展。同步步骤需要感知这些变化，并触发对应的威胁评估。

2. 验证现有控制措施 威胁模型里记录的缓解措施是否还在？某个身份验证中间件有没有被意外移除？访问控制规则有没有被新代码绕过？这些需要自动验证。

3. 标记需要人工审查的变更 不是所有变更都能自动处理。高风险的架构调整需要安全团队介入。同步步骤的职责之一是准确识别"这里需要人看一眼"，而不是把所有问题都推给人工。

AI 驱动的威胁建模：能力与边界

GitHub、IriusRisk 等平台已经在将 AI 引入这个领域。多智能体工作流可以自动分析代码变更、生成威胁场景、更新风险登记表。

这类智能编码工具在重复性高、模式明确的威胁识别上表现不错——比如检测常见的 OWASP Top 10 漏洞、识别已知的不安全配置。

但也有明确的边界。AI 智能体的行为存在不确定性，复杂的业务逻辑安全问题、供应链攻击的识别、以及涉及多系统交互的威胁场景，目前仍需要有经验的安全工程师参与。过度依赖自动化可能产生虚假的安全感。

这也是为什么"显式同步步骤"的价值不只在于自动化本身，更在于它创造了一个强制检查点——无论自动化程度多高，都有一个明确的时机让团队确认安全状态。

如何在实践中落地

对于大多数团队，从以下几个地方开始：

从单个高风险仓库开始，不要试图一次性改造所有 repo。选择处理敏感数据或面向外部的服务，先建立流程，再推广。

在 CI/CD 配置里明确声明这个步骤。不要把安全检查藏在某个脚本里，要让它在 pipeline 配置文件中可见、可追溯。团队每次看到 pipeline 定义，都应该看到威胁模型同步这个步骤存在。

区分"阻断"和"提醒"。不是所有威胁模型偏差都应该阻断部署。建立分级机制——高风险变更阻断 CI、中低风险生成告警并记录，让团队能在速度和安全之间做出有意识的权衡，而不是被迫绕过检查。

保持威胁模型文件与代码在同一个 repo。这是最容易被忽视的一点。当威胁模型和代码分开存放，同步就成了人工操作。放在一起，才能真正实现版本关联和自动化对比。

社区采用现状

坦白说，每个 repo 配置显式威胁模型同步步骤，目前在大多数工程团队里还不是标准实践。理论认可度很高，实际落地率偏低。

主要阻力来自两个方向：一是工具链还不够成熟，自动化程度有限，前期配置成本不低；二是安全与工程团队之间的协作摩擦，威胁模型传统上属于安全团队，而 CI/CD 配置属于工程团队，这个步骤天然需要两个团队协同负责。

这也意味着，现在投入建立这个实践的团队，将在供应链安全压力持续上升的背景下获得先发优势。相关的AI 安全法规讨论也在推动企业重新审视安全流程的系统化程度。

关键结论

把威胁建模变成持续过程的关键，是在每个 repo 的 CI/CD 流水线里加入一个显式的同步步骤。这个步骤不需要一开始就完美，但它必须存在——作为一个可见的、可追溯的检查点，让安全不再只是项目启动时的一次性工作。

更多关于 AI 驱动开发流程的实践，可以参考智能体技能系统的工作原理和如何构建生产级 Claude Code 技能。

---

觉得有用？订阅 LoreAI，每天 5 分钟掌握 AI 动态。