3.7.3　因地制宜的SDL实践

1. 重度的场景

对于公司内研发的偏底层的大型软件，迭代周期较长，对架构设计要求比较全面，后期改动成本大，如果安全团队人手够的话，这种场景应该尽量在事前切入，在立项设计阶段就应该进行安全设计和威胁建模等工作。相比在事后贴狗皮膏药，这种事前的时间投入是值得的，门槛主要还是人。

对于较大软件的“大版本”，包括每个产品初始版本，还比如标杆产品的1.0到2.0类似这种里程碑式的版本发布，修改和增加了很多功能点，甚至修改了底层的通信协议，这种也需要较完整的SDL，当然这种版本跳跃有时候只是对外的一种营销手段，不一定是技术上的大修改，这个就要看实际情况了。

2. 轻度的场景

对于架构简单、开发周期短、交付时间要求比较紧的情况，显然完整的SDL就太重度了，这个时候，攻防驱动修改就足以解决问题。

其他的诸如小版本发布，技术上没有大的修改，也没必要去跑全量SDL，否则就太教条和僵化了。