其次，留给安全扫描的时间窗口十分有限，它往往只能在产品功能完成之后，最终上线之前才能进行，在这种情况下，往往只有一次机会进行扫描，也只能给团队提供一次性的安全反馈。但实际情况却是，业务需求在不断发展和变化，开发团队也在持续对产品功能做出调整，除非每次产品功能发生变化之后立即进行一次安全扫描，否则以现有的模式，是没有办法及时给开发团队提供安全性反馈的。

　　最后，安全扫描的成本也是不得不考虑的因素。购买外部安全公司的安全扫描服务到是很方便，可是动不动就是几十万的支出不是任何团队都能承受得起的。通过自有安全团队做安全扫描看上去可能更加经济实惠，毕竟是公司内部资源，但是别忘了，自建安全团队也是有成本的，而且要招到杰出的安全工程师也不是件容易的事情。

　　既然安全扫描有这么多缺点，那为什么还有如此多的团队在用它？

　　抛开安全问题暴露出来之后，解决起来是如何痛苦这件事情不谈，其实安全扫描也并非一无是处。

　　尽管安全扫描在时间上晚了一些，速度上慢了一点，还不可持续，但由于软件开发本身是个复杂的过程，开发团队在产品安全性上总有疏忽大意的时候，只要进行安全扫描，atv，大多数时候都会有所“收获”。这样的话，一方面安全扫描帮开发团队发现了问题，另一方面安全团队也体现出了自身价值，正是在这样的背景下，安全扫描无论是对于开发团队还是安全团队而言，都具有难以抗拒的诱惑力。

　　此外，有时候做安全扫描也是一种无奈之举，因为有些开发团队不见黄河不死心，除非你把安全问题明确的摆在他们面前，否则他们意识不到问题的严重性，不会轻易的主动去关注安全问题。

　　除了安全扫描，还有别的什么办法？

　　既然安全问题这么重要，安全扫描又是如此的低效，那我们该怎么做才能更好的解决这个问题呢？答案其实早就摆在眼前了，软件的安全性是软件质量的一部分，为何不尝试一下把它和功能需求一样，都当做头等公民来看待呢？那些用于保证软件质量的最佳实践对于软件安全性同样适用。

　　更具效率的做法是，在产品开发的全生命周期里，直接植入安全最佳实践，我们把它叫做Build Security In（简称BSI）。例如，在分析业务需求的时候，主动去分析安全需求，给用户故事建立安全验收标准；在开发过程中时刻关注安全，通过自动化的安全测试持续性的关注产品安全；在测试过程中，不仅测试产品看其是否满足了业务需求，还基于安全验收标准设计并执行安全测试用例。

　　传统的安全扫描是从后外前推，倒逼着开发团队做改变，而BSI的做法则是从前往后梳理，融入到日常的开发过程中。正是因为提前并且持续性的关注产品安全，所以在后续的开发中，团队才会有意识的去做安全防御，使得最后开发出来的软件默认就已经具备了不错的安全性，给团队带来的冲击和压力也是最小的。

　　迈出改变的第一步

　　安全扫描已经深深的烙在了很多开发团队的骨髓里，突然之间要改变这一切势必不容易，但是我们还是可以做很多尝试来逐渐改变这个现状。在这里我推荐一些比较好的切入点，开发团队可以作为参考，迈出改变的第一步。

　　每当在创建用户故事的时候，多问几个和安全相关的问题，比如：

这个业务需求面临着哪些威胁？

和这个业务需求相关联的安全需求是什么？

有没有什么东西是应该被保护起来的？

应该提前做些什么以应对可能的黑客攻击？

　　然后，团队共同给这个用户故事设定安全相关的验收标准。

　　开发人员在每日代码审查的时候，多问一下：“这样设计，或者代码这么写，有没有什么安全风险？安全验收标准满足了吗？”

　　每当测试人员拿到一张用户故事对其进行测试的时候，也问问自己：“除了测试产品看其是否正确实现了业务需求之外，还需要基于安全验收标准设计并执行哪些安全测试用例？”

　　上面这些提问看似简单，但是当你在团队里问出这些问题的时候，你一定会惊讶于它们带来的影响力。试试呗。