2020年RSA Conference将于2月24日在旧金山拉开帷幕，今年大会的主题是“HUMAN ELEMENT”。代表着安全产品创新方向的“创新沙盒大赛”十强厂商中，半数是做应用安全类产品的厂商，包括做应用安全测试的BluBracket、ForAllSecure，做应用安全防护的Sqreen、Tale Security，以及做漏洞管理的Vulcan Cyber，这从一定程度上反映出应用安全在安全市场上的火热程度，也指引了应用安全领域的创新方向。

与开发安全相关的厂商是BluBracket和ForAllSecure，他们的产品都宣称能够更好地帮助企业落地DevSecOps，下面我们一起来看看这两款产品。

代码安全：BluBracket

BluBracket是一家专注代码安全的厂家，并宣称是其方案是第一个完整的企业代码安全解决方案。它向用户传达的焦虑是“你的代码无处不在”，由于云和GIT等代码仓库的流行，企业的代码可能分布在各个地方，“代码在哪儿？谁能访问？代码中有哪些信息？”是BluBracket当前致力于解决的问题。

与CheckMarx、Fortify等传统源代码安全大厂不同的是，BluBracket几乎不涉及源代码的漏洞检测，更偏向于代码的安全管理、代码中的敏感信息泄露与开源组件风险。

这是一个初创公司比较聪明的做法，因为源代码的漏洞检测技术门槛太高，创业公司不太可能在短时间内形成竞争力，所以漏洞检测这部分只做敏感信息泄露和开源组件风险是非常正确的选择；同时源代码的安全管理其实往往是企业忽略的点，算是开发安全管控中比较新的方向，比如最近两年企业都比较重视的GitHub代码泄露，就属于这个方向，BluBracket把代码泄露和管控不当这类问题成体系地给出解决方案。

BluBracket的解决方案分成四步：发现和分类代码→监控代码风险→保护有价值的代码→实施安全策略。

  • 发现和分类代码：通过跟GIT等代码仓库和一些代码平台对接集成，发现企业相关代码所在的位置，并且一键对代码进行分类分级；

  • 监控代码风险：周期性地检测代码中的密钥、令牌等敏感信息泄露风险；

  • 保护有价值的代码：通过ML和AI自动识别高价值的代码，督促用户对暴露的风险进行修复，并调整安全检测和访问策略；

  • 实施安全策略：在CI/CD中集成相关的安全策略，弥补安全和开发团队之间的鸿沟。

BluBracket套件中有两个产品：CodeSecure和CodeInsight，CodeInsight主要负责对代码进行发现、分类、持续跟踪以及开源库的检测；CodeSecure主要负责对代码进行敏感信息泄露检测、访问控制、主动发现、策略定义、开源库安全检查等；从官网给出的产品界面可以看出产品功能基本与上述宣传相符，能够帮助企业发现代码位置、仓库类型、仓库操作记录、敏感信息泄露检查等。

BluBracket在其DevSecOps方案中主要强调了3点：

  • GIT集成——通过与GIT集成做到代码的访问控制、获取代码并自动分类分级、识别开源库、代码仓库异常操作的告警等；

  • 开源库的风险检查——通过CodeSecure的安全能力实现敏感信息硬编码的检查、第三方库的安全检查、代码仓库的安全配置核查、制定安全策略等；

  • 扫描速度——由于CodeSecure的安全检查非常轻量级，检测项也比较简单，所以能做到非常快的扫描，与CI/CD的pipeline集成不会拖慢整个pipeline的速度，这点在DevSecOps里非常重要，传统的源代码检查工具很大程度上是因为扫描速度导致难以在DevSecOps中应用。

整体来看BluBracket的方向比较新颖，也确实是企业目前普遍忽视的点。随着企业应用安全的水位逐渐上升，对代码安全管控的重要性也会逐渐体现出来。

但是有两点值得关注一下。一个是代码安全管控什么时候会从“普遍忽视”变为“普遍重视”。BluBracket本质上解决的是代码泄露所带来的安全问题，不管是内部泄露还是外部泄露，企业本身在安全建设中多多少少会覆盖到代码的安全控制，比如员工行为管理系统，涉及到对敏感文件的操作审计和控制；有些DLP方案将代码视为敏感数据的一种，从而进行管控等等，这类问题恐怕更像是事件驱动型，只有具体事件发生后才会专门为代码安全管控规划一套方案，以及用户POC测试的时候未必会真的发现代码泄露问题，所以在当下该如何去说服客户以及如何体现产品效果值得思考。

第二点是从整体的产品介绍中，从我个人角度看并没有发现产品拥有很高的技术壁垒，更多的是第三方集成、适配、策略收集的工作，所宣传的基于ML和AI进行代码的自动分类分级在整体安全能力上看其实价值有限，如果仅仅依靠方案比较全面来作为竞争力，会有较大的被替换风险。

模糊测试：ForAllSecure

ForAllSecure的主打产品是Mayhem，宣称是下一代模糊测试解决方案，融合代码覆盖引导和符号执行的动态分析技术，能够做到更高的程序覆盖度和漏洞发现率，并且做到零误报。

随着IoT业务的大爆发，C/C++也重回GitHub的流行榜首，对于二进制文件的黑盒安全测试几乎只能用模糊测试的方法进行覆盖。只不过由于技术门槛比较高，在很多开发安全厂商的方案里没有涉及到。模糊测试一直是开发安全方案里的一块业务，比如Synopsys的开发安全方案里就包含专门进行模糊测试的工具Defensics，用于覆盖二进制和协议方面的黑盒安全测试。随着物联网的持续火热，模糊测试在安全开发领域的重要性会逐渐增强。

ForAllSecure在产品方案层面上，通过对比SAST的高误报、SCA发现的是已知风险、DAST只能通过已知攻击手法去拟合，从而突出fuzzing对0day未知风险的发现覆盖能力。

在技术层面上，ForAllSecure专门出了一份Benchmark测试报告，对比Mayhem与其他Fuzzing工具的优势，主要体现在更高的代码覆盖度、更快的检测速度和更少的测试用例三个方面。

ForAllSecure在语言方面支持C/C++和golang，后续会对java语言支持；第三方集成方面支持与Travis CI、Jenkins CI/CD平台集成，GitLab和GitHub代码仓库集成；平台支持Linux、ARM和X86，后续会对Windows进行支持。

在DevSecOps方案上，ForAllSecure根据DevOps的流程执行五种安全检查，在Build阶段进行组件安全测试，在测试验证阶段进行威胁建模、动态测试和异常测试，在部署阶段进行回归测试。

与DevSecOps的流程整合上，官方资料描述比较简单，通过与CI/CD pipeline集成，在Build之后自动化上传可执行程序到Mayhem平台上进行安全测试，再将测试结果输出到BUG管理平台或同步到CI/CD平台上；同时也支持用户手动上传二进制文件进行安全测试。

综上来看，ForAllSecure从12年成立到现在，持续沉淀了多年的Fuzzing技术，在技术壁垒上是有一定竞争力的。随着物联网的火热，业务和市场也会越来越大。

但需要注意的问题是，当前开源的Fuzzing平台也有很多，尤其以Google的ClusterFuzz最为著名，从ClusterFuzz所用的LibFuzzer、AFL的代码覆盖引导技术和已经发现的漏洞成果上来看，都属于很高的水平。如何向客户阐述商业工具与开源工具之间的差别是关键点，如果仅仅从技术的角度说明差别，对于较高级别的客户是枯燥无味的，也难以打动用户，检测效果上细微的差别一定不是用户最关心的点，更需要从用户在日常DevSecOps活动中的问题和痛点出发，在这部分的价值上ForAllSecure的官方资料较少。

总结

本次RSA创新沙盒所选出的两家开发安全厂商，他们所做的产品与我们普遍认知的开发安全产品体系（SAST、SCA、IAST、DAST）有着明显的差异，属于比较创新的产品方向——代码安全管控和模糊测试，给了我们新的思考与启发。

在物联网、云、容器不再是趋势而已经广泛应用的当下，在未来Serverless或许真正盛行的时候，开发安全应该要做出什么样的变化去顺应IT的发展？大厂的技术壁垒可能因为某些开发模式的更改而逐渐降低，比如传统DAST的衰弱，新兴的IAST与SCA的流行，再比如无服务架构FaaS对开发安全产品要求的巨大变化。每个厂商都有机会重新定义开发安全的标准模式和产品体系，是创新者向市场领导者发起挑战的机会，当然这背后离不开对技术、业务、用户以及IT发展的深度思考，更离不开仰望天空、脚踏实地的一群创新者。

声明：本文来自默安科技，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。