这不是哪个更好的问题，在很大程度上这些活动是结合在一起的。

例如，通过选择适当的设计、使用适当的技术和定义相关的编码指南，可以预先适当地缓解一些微不足道的威胁（例如 SQL 注入和 XSS）。

另一方面，大多数安全机制和缓解措施都是无关紧要的 - 直到您了解您正在尝试缓解的威胁。

还有一点要考虑的是，您实施的任何安全机制也需要进行威胁建模。是的，有时“安全机制”实际上会引入新的威胁，这需要仔细考虑。（例如杀毒软件...）

因此，底线：迭代方法是最好的，将威胁建模作为构建设计的一部分。
就像您迭代地进行系统设计一样——首先是整体架构，然后是详细设计，然后是特定模块/功能/无论什么——每次迭代都应该有一个相关的 TM。因此，例如后期架构/预设计，您可以构建一个简单的 TM；当您了解更多细节时，请随时记录这些细节！

我同意 AviD 所说的，并且会更进一步。

将威胁建模视为一组活动，不同的威胁建模活动发生在不同的时间。在设计过程中广度优先可以帮助您发现整体威胁，在实施过程中深度优先可以帮助您发现针对您正在构建的防御的威胁（这可以被认为是设计测试用例。）

如果你是视觉的，威胁、缓解和需求之间的这种三角相互作用可能会有所帮助。（https://adam.shostack.org/blog/2017/05/threat-modeling-iot/（已更新以解决断开的链接问题））

因此，您将在“这是一个设计”之间来回迭代；这允许这些问题，所以我们改变了设计，然后我们考虑会出现什么问题。