3.7.1 攻防驱动修改
大多数甲方安全团队所做的工作实际上处于这个维度。通过对已知的攻击手段，例如SQL注入，XSS等建立事前的安全编码标准，并在发布前做代码审计、渗透测试和提出漏洞修补方案。这种模式的显著优点是针对性比较强，直入主题，见效快。
简单的流程+事件驱动型构成了这种日常行为的本质，简单的流程通常包括：
事前基线：Web安全编码标准，各公司内部范围流传的APP应用安全设计文档，这个文档的质量水平通常可以差很远，当然文档永远只是文档，可能就是开发部门不强制不考试800年都不看的东西。
事中措施：代码审计，发布前过一轮扫描器+渗透测试。
事后机制：HTTP全流量IDS，Web日志大数据分析，等等。
事件驱动：发现了新的安全问题就“事后诸葛亮一把”，做点补救性措施。
从整个过程看，攻防驱动修改比较偏“事后”，相对于完整的SDL，威胁建模等工作而言，它似乎不用发散精力投入太多就能覆盖已知的攻击点，而且在研发侧不用面对比较大的“推动SDL落地的压力”
但是它的缺点也是显而易见的，由于过程方法论的施力点的比较偏事后，所以在从源头上发现和改进问题的能力不足，弱于在产品内建的安全机制上建立纵深防御，被绕过的可能性比较大，事后的bug率到一定程度就很难再改善，只能通过不断的攻防对抗升级去事后修补。笼统一点讲就是考虑不够系统性。这跟当前安全行业缺少真正的安全架构设计人才有关，攻防的声音铺天盖地，跟国外比一下在设计和工程化方面差距不小。
事后修补是不是总是有效的，缝缝补补的感觉你觉得会如何呢，对于公司的边缘性产品你可以希望它早日归入历史的尘埃，而对于公司的支柱型产品你只能寄希望于某一个大版本更新时把某些机制推倒重新来过。
