一个思考：安全测试驱动产品安全？

01

—

引言

最近两天，有幸参加了“华为合作伙伴网络安全管理前移赋能培训会”，让我感叹大厂的强大、以及对合作伙伴的无私输出。会上的一些内容，引发了我对安全测试的深入思考。

在与同事晚饭后，快速回了酒店。回想白天的培训内容，一时兴趣，决定听着窗外滴答和淅淅沥沥的雨声，奋笔疾书写下这番感悟。在此，感谢华为公司采购网安与隐私保护部的组织，感谢公司和领导的支持、让我们有机会走进华为南研所学习。

02

—

内容回顾

华为不仅介绍了对供应商的网络安全管理要求，更是引入了供应商的实践案例。重新回顾这两天的课程安排，如果从课程内容+讲师实力来评价，我获益最多的是 - - 华为网络安全红线落地解读指导：

• 内容很丰富：在经历了多年的国家级攻防演习产品安全、冬奥产品安全等重大活动保障后，在运营QAXSRC和DevSecOps多年以后，亲切地与其内容产生共鸣，红线中不少要求都是过去遇到的产品安全问题，是那些令我们痛过、应急过的被攻击要点，惊叹现在竟然被按照不同维度做了提炼和总结;
• 讲师有经验：能把很多文字要求进行分类、标记，串入一些场景和案例讲出来真不容易。一听就能感觉到是实操过的，并且经验丰富。尤其是开场白（不要把安全红线仅用于安全测试，要嵌入设计环节）和问答环节（自信的回答各种供应商的问题），令我印象深刻。后来才知道讲师是ICSL实验室的，反正水平挺高、讲得挺好。

03

—

安全测试

虽说做了很多年的安全测试，但还是忍不住去查一下：在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。

看定义，说的没问题、但不够清晰与明确。但是，我们把其定位错了？在甲方应用安全团队中、或在乙方安服团队中，大家说起安全测试时，可能重点关注成果：产品经过安全测试，发现的漏洞数。久而久之，我们在做工作汇报时也会聚焦于此，并且想方设法地、乐此不疲的要挖出更多漏洞。

3.1 错误定位安全测试的原因

如果更早有CSO思维：如何才能避免漏洞，而不是一直发现漏洞？可能在产品安全的建设方向上，会把握得更精准。不过现在反应过来，也还来得及。初步尝试分析，想到了一些原因：

• 救火习惯了，往前进一步就好：大多数人的（现实）想法吧，产品安全事件处置多了、处置完后，有条件的就想到了找几个人、在产品发布前做下安全测试，这样就行了；
• 安全测试人员大多非科班出身：身为安全测试从业人员，能清楚的认识到自身对IT、软件开发工作的不全面认识，无论是专业技能、还是工作方式与流程，都会有些不一样，如果之前只是搞渗透、安全团队没和研发呆一块儿的，感受应该很明显；
• 最根本原因还是安全上的投入：这个理儿无论是在何时、何地、哪个行当，都是对的。毕竟资源是行动上最大的阻碍，没有投入就不会有收获，因为这是天经地义的。

3.2 安全测试不应仅发现漏洞

平时在与测试团队、一些软件安全标准、与华为采购安全团队接触，以及参加本次培训，得到的最强烈感受是：安全测试是检验安全需求、安全设计是否落地的方法与过程，此外还能发现意料之外的安全问题。所以重点应该是“验证”，而非漏洞数。不过对于新发现的漏洞，也应该重视并反哺到安全需求和设计中，实现正向的良性循环。

3.3 安全测试不止一堆扫描工具

没做过安全测试的人，总会被一连串的扫描工具所征服。不过扫描器虽好，可不要被其“假象”所迷惑。当我们去年重点运营QAXSRC后，做了很多高额奖励的挖洞活动、维系了一群优质的白帽子，以至于前7个月收到的高危漏洞数就约是上一年度的3倍，收洞预算更是超支了很多。好在老板认可其价值，审批我们追加的预算，并把奖金池填的满满当当。于是我们就留足精力，开展复盘分析、“向左”反馈提升研发安全体系。

经过分析，不难发现：很多漏洞一层层穿过我们的“SAST-IAST-DAST-人工测试”大闸，流落到白帽子手里。其实我们也一直在：

• 完善漏扫体系，比如引入多款异构、功能相同的扫描器，加入扫描体系；
• 提升扫描器检测能力，比如每次复盘都要重点关注SAST的检测规则，尽可能想办法补充；
• 开展专项治理，针对不方便自动化检测、又普遍存在的安全问题；
• 扩大手工测试的覆盖面，发现更多逻辑类、扫描器不友好的产品漏洞；
• 引入常态化的产品安全蓝军（一年四季以攻破产品为目的），借用公司的优质挖洞力量（邀请公司各个漏洞挖掘实验室）...

但是，还会漏出去很多漏洞，由此说明：产品安全，真的不能只依靠安全扫描工具。（本段写了这么多，估计是受现场的影响 - 某供应商分享，建设了很多安全检测工具，似乎就做得很好了，估计还受一些不良印象的外部交流影响 - 支持前场做客户交流，一些客户也会这么认为，花钱买了检测工具就能做好安全。）

3.4 安全测试相互驱动安全设计

继续接着上一段的内容，为什么还会有漏洞漏出去呢？这肯定是一个复杂的问题，比如：安全测试能力、安全扫描能力、研发安全流程被旁路... 进而，如何做才能有效的让更少漏洞遗漏出去？从华为的实践，以及站在一个理性的角度来思考，应该就是安全测试与安全设计相互成就了（其实早就知道了，但是没做到，此次会议是在不断重复、坚定脑海里的想法）：

• 根据安全需求或安全设计红线，编写安全测试用例，在每个阶段（写安全需求/写安全设计/写安全测试用例）均进行安全落实情况检查，测试阶段是最后一道关卡，在进行安全测试、检验安全需求或设计是否都实现了、生效了；
• 根据安全测试结果，甚至运营阶段产生的产品安全事件，反向补充安全需求或安全设计红线。

以上应是一个动态、长期的过程，唯有这样不断地良性循环迭代，才能提升产品的安全性。

04

—

安全驱动力

还是继续接着上一段的内容，回顾自家的产品安全建设历程，似乎很难去引导或管理诸多、所有产品线建立安全需求/安全设计红线。因为没人，不仅是安全团队，产品线也没有那么多人来配合；没技术，没时间...诸多现实的问题，一股脑的冒出来，想起来都很头大。

4.1 自上而下的权利驱动

难道，真的要回到“资源”这个话题上来？那撬动资源的人，就只能是老板或公司高管了，只有他们站在公司发展方向上决策，才可能做成这件事儿。参照华为，任总签署了开源治理相关发文，据说当年经他手签字的文件屈指可数，由此华为有了开源治理实体高管和干活团队；参照另一家供应商的分享，CEO挂帅担任首席安全官，同时成立了PSIRT团队、安全设计团队、安全测试团队、秘书处开展产品安全工作。

4.2 以客户为中心的需求

要进一步提高产品安全治理成效，我还得继续梳理着这一线头。不如，从以服务客户为中心，满足华为这一客户的安全需要/要求，去找领导汇报？或许是个好办法吧，不过此时已到后半夜，大脑开始转不动了，希望有比较好的说法去推动这件事儿。最后，放弃了这两天不舒服的午休方式，在华为南研所内散步，在幽美的自然和人文环境中，真还发现了“宝藏”：

此图，感觉可以激励自己！想送给在产品安全之路上的同行们，也献给关注我的粉丝们！