我是怎么把研发安全做“没”了的

言归正传，老板说，我的职责是在研发同事的日常研发过程中不同环节介入不同安全能力，从而实现对项目进行上线前安全质量管控。再详细点说就是在下面图里的开发编码和测试阶段，介入安全厂商不同商用 工具 进行安全检测和修复，并且以制度形式完善落地效果。

想想我王大锤是什么人，这点小事在我手里简直信手拈来，一想到自己接下来的无限前景，简直….嘿嘿嘿。

说干就干，首先，是研发环节，简单说就是 程序员 写代码的环节，这个环节我们马栏山不省心集团介入的是标准的SAST（静态应用安全测试）。

把项目源码导入，它就会自动化利用已有规则进行安全检查，嘿你别说，这工具还挺灵光，一个项目就能扫出3000+漏洞！再来我把漏洞报告提交给研发人员修复，我的工作就万事大吉啦！

然而我还是Too Young，研发同事没一会就拎着平底锅过来找我说，他们拿着报告测试了前500个漏洞，居然有450个是误报，于是他们当场炸毛，要求我给他们验证这3000+个漏洞哪些需要他们修复，否则他们不处理该报告。

OMG，光一个项目就3000+个漏洞等着让我去一一验证，我哪还有时间去完成我的工作进度，一想到老板还在等我的部门产出，我仿佛看到了各色奖金在离我而去。

没办法，为了大局考虑，我决定放松在研发阶段的安全检查，毕竟，我们还有后面测试环节的安全介入不是~

测试环节我们马栏山不省心集团介入的是标准的DAST（动态应用安全测试），也就是俗称的漏扫，方式是在测试环节将项目地址提供给某商用工具，该工具会自动构造请求与项目交互，随着测试时间越长，工具构造的请求能够进入的项目功能逻辑分支就越多，检测深度就越完善，效果就越好，而且由于是动态测试，误报率的情况比SAST简直不知道好到哪里去！

然而事实告诉了我，我不仅Too Young，而且还Naive。

我忽略了一个严重的问题，集团研发项目进度普遍较快，各环节里程碑时间都较为紧凑，研发人员工作量、交付压力普遍较大，故在有限时间下，习惯性将主要精力聚焦在功能问题，主观意识上未将研发安全归为己任，加上DAST工具和规章的介入会在一定程度上打乱他们工作安排和进度，所以实际使用过程中DAST的介入扫描时间、深度往往不尽如人意。

很多研发、测试人员故意就只拿它测了个大概，拿我们安全工具“走过场”，漏洞依然遗留，导致上线后的项目安全能力“千疮百孔”。

看着手拿白帽子漏洞报告的老板逐渐垮下来的嘴角，我不禁感到丝丝凉意……于是决定拿出我最后的倔强。

既然项目已经上线，不敢贸然做业务切割的排查，于是我购买了最为一流的WAF，把规则控制得天衣无缝，什么？你说我有 SQL 注入？有XSS？有本事利用给我看呐！

然而，万万没想到，运维同事说我的WAF拦截干扰了他们的正常业务，要求我交出WAF的规则控制权，由他们进行拦截规则管控，于是所有规则被他们限制到最宽松，“为正常业务让路”，一同被让进来的，还有一众数不清的攻击利用手段，于是，我最后的倔强，分崩离析。

我是王大锤，我成了马栏山不省心集团的研发安全工程师，万万没想到，最终一通操作之后，我从研发到测试甚至上线后的安全建设全部名存实亡，成功把研发安全做“没”了。。。

看着这摊狼藉，一想到已经没法升职加薪，当上总经理，出任CEO，迎娶白富美，走向人生巅峰，我最终决定抄起《企业安全从入门到跑路》，开辟另一番天地。

王大锤的从业经历，相信大家都会有所感触。那不妨我们今天就来分析一些问题出在哪里，以及应该如何进行应对。

简单归纳起来，上述问题的核心无非是SAST误报高无法落地、DAST过度依赖构造请求的准确率，导致的不定量漏报；以及上述两个环节对研发过程的侵入性，而导致的落地推进阻力，最终使得安全不得不以被动防御的姿态运用在项目上线之后。

那反过来说，如果我们能够解决DAST的漏报问题，通过新型技术进一步精化其检测能力，并以该环节为安全保证基础反推研发环节SAST的规则构建，实现规则告警“少而精”，解决SAST的高误报问题，同时在这两个环节做到柔和无感知，不更改相关人员原有工作方式，降低落地阻力，上述的各种问题，是不是就能解决了呢？

这正是默安科技正在专注的主要方向之一——研发安全技术革新，通过完整自研“服务+工具+平台”SDL全流程方案，基于微软经典SDL（安全开发生命周期）模型，将赋能服务贯穿需求分析、架构设计、研发、测试回归以及发布迭代全流程。

微软SDL（安全开发生命周期）模型

通过赋能将专业安全能力赋予研发各环节人员，并在各环节提供不同工具（STAC、SAST、IAST、常态化安全运营），使赋能知识真实应用落地，最终以统一平台展示、分析、回归、闭环安全问题，并向安全部提供SIEM(安全信息和事件管理)，根据各流程频现的漏洞类型、研发人员知识盲区等再次提供针对性培训和制定规章制度，实现制度精准逆推落地。

测试环节以交互式安全测试（IAST）替换原有DAST，交互式应用程序安全测试通过无感知的方式获取功能测试人员测试交互流量，并以此取代动态应用安全测试的自行构造模式，同时基于模糊测试（fuzz）思想对流量进行攻击代码随机插入和攻击流量构建，自动化对被测程序进行安全测试，并在测试过程中借助插桩监控平台对被测程序的运行轨迹进行实时跟踪和介入，一旦攻击流量触发安全问题，插桩平台不仅可以第一时间捕获安全问题，精确定位到漏洞所在的代码文件、行数、函数及参数。

通过这种方式，交互式应用安全测试既能保证检出漏洞的有效性，有效降低误报漏报率，还能够精准定位漏洞，帮助研发人员更好地进行漏洞修复和回归，有效提升测试过程安全检测能力。

同时，IAST的新型测试模式还可以覆盖更多传统DAST无法触及的安全范畴，包括逻辑类漏洞检测自动化、双向加密数据获取等，实现更为良好的安全检测能力。

测试环节有了IAST这样强力的安全支持后，SAST将不再是割裂的一环，我们就可以在SAST部分进行规则精简，确保只检出与其核心规则匹配的安全问题，所有与其规则匹配度较低，存在“模棱两可”情况的潜在安全隐患，SAST均可以通过反馈机制交由下一环节的IAST部分进行实际运行攻击测试。

换言之，通过阶梯式检测方案，在研发不同阶段介入最为适合的检测方式和最优检测规则，确保在每个流程上都只检出真实漏洞。而所有需要确认的漏洞，交由IAST过程使用真实漏洞攻击代码进行检测，确保更为有效的真实漏洞检出概率并降低误报导致的人工分析成本。

同时SAST通过与git、svn等代码仓库联动，自动化拉取全量或增量代码进行代码安全检查，以波谷时间检测方式在上班时间前根据提交历史以邮件形式同时相关责任人，降低对相关人员工作方式更改和落地阻力。

通过上述测试和研发环节的安全建设，大量漏洞得已在项目上线前被解决，故上线后的安全能力将不再必须以被动防御的姿态进行。

同时，上线迭代的项目安全风险来源已不仅仅只有其本身，该项目使用的服务器、服务器提供的中间件以及项目本身这三个维度均可能是风险来源，故默安科技建议用户使用常态化安全运营方案，对项目上线后所在的服务器资产、中间件以及项目本身进行7*24小时周期性安全检查，相当于有一个安全团队或渗透测试工程师全天候管理线上资产、站点以及中间依赖的安全问题，有效确保安全健壮性。

在上述环节完成后，我们则可以进行最后一轮安全前置，即项目需求分析、架构设计环节基于业务场景的威胁建模（STAC），以威胁建模赋能和提供针对性checklist方式教会需求分析和架构审计人员对项目内场景潜在风险进行识别和剥离，通过威胁建模针对性提出安全方案，用于后续研发等环节的解决或规避，完成SDL的最后一环，真正实现从需求分析、架构设计、研发、测试以及上线运营五个环节的安全能力全方位介入。

回到文章开头的故事，主人公王大锤如果能够拥有这样的系统化专业方案，相信他想把研发安全做“没”都难~