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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　安全扫描的短板不止一处

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

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