谈论网络安全架构，我们不可避免地要提到安全架构师的另一个主要输出点：架构审查。因此，我们第一步需要知道的是：安全架构审查意味着什么？最初的目标可能是在项目开始之初确定潜在威胁，并提出相应的解决方案。第二点呢从另一个方面看，旨在提高安全团队的影响力。高质量的输出，当然是提升影响力，增强话语权。普通话也不过是刷一下存在感而已。士人阶层自古以来就存在，即使处于架构师阶层、前和后领域、网络领域、数据库领域以及安全领域的同学们都有可能自恃“清高”。很有可能，这是因为参考架构审查的安全架构师不能切中要害，缺乏全局观点，以及前面提到的一些准备知识，更多的情况是安全部门不适合被其他架构师认可。当然，安全性架构师本身也有一部分问题，比如在审查中关注的重点太过随意，系统不足，或没有对业务的特性不清楚，没有提前充分了解，以致在沟通时问题缺乏针对性等等。

在SDL的观点中，如果体系结构审查出现问题，那么SDL的第一步就失败了。了解了架构评审的目的之后，还要记住一点，尽管在此阶段不一定要执行它，但是它必须在架构评审阶段被提出。因此，如何使项目的架构符合预期的方向呢？如何才能产生更好的输出？基于WHY,WHAT,HOW步骤，我们看看HOW部分：

基于PRD文件进行设计领域的风险检查，并对大型项目进行威胁建模。将安全研发和安全测试相关知识分别输出给研发同学和测试同学。当架构评估会议时，确认并输出解决方案或缓解措施。介绍相关的安全产品，并且可以作为持续部署提供。对输出方案进行闭环检测，跟踪相关落点和漏洞情况。与架构师相比，安全架构师更加关注安全领域，当然这并不意味着他们不需要基本的架构知识。因此，在进行架构审查时，最原始、最直接地了解业务方的是PRD文档中的对应框架构图，请注意业务提供的框架图和全局框架图之间的区别。

使用上面的架构图，可以非常直接地了解业务逻辑、物理部署、数据流等，熟练的安全架构师能够更直接地发现相应的问题。但是要达到所谓的知己知彼，百战不殆，还得靠“踩坑”。比如，在业务逻辑架构中使用阿里云ODPS服务进行权限控制，这看起来似乎是安全的，但数据是否打了标记却很容易被忽略。若未标注，则此数据流权限控制依赖于ODPS，具有某些缺陷。理解了整个体系结构后，威胁建模的步骤应该是第一步分解应用程序，找出外部依赖性，找出入口点，分析服务所使用的资产，由此产生的攻击面，针对相应的数据流进行分析等等。(你这老太婆还真是个天才，说得像教科书一样)。这些都是理论上的，当然也包括设计领域和相关的Checklist。在分析威胁时，从系统功能、系统部署、系统依赖等方面，对STRIDE中的古老的威胁建模习惯，介绍的很少。因此，威胁是如何划分优先级的？具体请参阅微软建议的DREAD。