本文中的“安全扫描”是指开发团队在距离产品上线日期比较近的时候，通过公司里的安全团队或者外部第三方安全公司对产品进行安全扫描，团队基于安全扫描报告，对产品中存在的安全漏洞进行修复的过程。不同的公司，不同的开发团队对它的称呼可能不一样，有人把它叫做渗透测试，也有人把它叫做安全审查、安全评估、安全检查等等。

如果不做安全扫描会怎样？

想象一下，你所在的开发团队正在开发一款互联网金融产品，所有的核心业务功能基本开发完毕。此时此刻，离计划中的上线日期只有不到三周时间。通常而言，这时候安全扫描就会介入进来，扫出一堆问题扔给团队修复。

不过这次不一样，如果我提议，不必给产品做安全扫描，就这样直接上线可好？我想，绝大多数人的反应会是下面这样的：

“神马？！不做安全扫描？那我怎么知道产品安不安全？万一出问题了怎么办？”

“我知道我们产品中一定会有安全问题，安全扫描正好可以帮助我们把这些问题暴露出来，将其修复之后再上线才是万无一失的选择。”

“虽然每次安全扫描都会扫出一堆问题来，搞得团队压力山大，但如果不做扫描，我们到是轻松了，可产品的安全性却又是个问题。”

“安全扫描可是我们安全团队的杀手锏，不让我们给开发团队做扫描，那我们的价值怎么体现出来？”

“公司规范里说了，不做安全扫描不准上线。”

“年少轻狂的年轻人，我以过来人的经验告诉你，这么做是要付出代价的。”

反应越是激烈，说明团队越是依赖安全扫描。甚至可以说，安全扫描在你的团队里，是保证产品安全的最后一道屏障，也是唯一的手段。

安全扫描是陈旧落后的手段

有人会说，最后一道屏障又怎样，唯一的手段又如何，不管红猫黑猫，抓到耗子的都是好猫。

先不谈这样做是好是坏，我们先来换个角度思考一下，如果把“安全问题”这几个字换成“功能缺陷”或者“Bug”，你还会认同这种在临近产品上线之前做一次性的、运动式的大检查，然后期待着开发团队在所剩无几的时间里快速修复掉所有Bug，还不能引入新Bug的做法吗？

答案显然是否定的。大家都明白，功能缺陷越早发现越好，否则修复成本将会非常高，越往后拖越对团队不利。

现如今，还有哪个开发团队敢说，在开发过程中不需要对软件做测试，等到最后上线前做一次集中式的测试就够了？开发团队也是极尽所能的快速响应软件质量问题，例如进行测试驱动开发，编写大量的自动化测试并且通过CI持续的对软件质量进行监控。

安全问题是如此的重要，它也是软件质量的一部分，只不过换了个名字，变了种表现形式而已，而我们却用如此落后的方式来对待它，显然不合理。

提前做安全扫描可能是空中楼阁

又有人说，安全扫描不就是太晚了一点嘛，我们把扫描时间点往前提一些不就好了吗？

思路是对的，但很可惜，要做到这一点却几乎是不可能的。因为安全扫描有一定前提条件，它只能对已经开发完成了的功能进行扫描，这也就意味着，那些还处于开发过程中的功能是覆盖不到的。而且随着开发的进行，软件功能会有所调整，之前做过的安全扫描很可能会失去意义，最终还是得等到所有功能都开发完毕了，在上线之前再做一次最终的安全扫描。于是这又回到了上面那个问题。

安全扫描的短板不止一处

安全扫描除了上面讲到的时间太晚的问题之外，还有不少短板。首当其冲的就是速度太慢，跟不上开发团队的节奏。尽管有自动化工具的帮助，但是一次全面、细致、深入的安全扫描，往往需要好几天，甚至更长时间。在如今追求快速开发上线，迅速调整以响应市场变化的环境下，开发团队没有这么多时间和耐心来等待扫描结果。

某些采用敏捷或者精益开发方式的团队，每个迭代甚至每天都有新功能上线和旧功能调整、问题修复等等，而等到几天甚至几周后，团队拿到安全扫描报告的时候，被扫描的功能可能早就被废弃了，这么做简直是在浪费资源。

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

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

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

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

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

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

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

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

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

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

迈出改变的第一步

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

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

• 这个业务需求面临着哪些威胁？
• 和这个业务需求相关联的安全需求是什么？
• 有没有什么东西是应该被保护起来的？
• 应该提前做些什么以应对可能的黑客攻击？

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

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

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

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

更多精彩洞见，请关注微信公众号：ThoughtWorks