前言
前段时间微信群里有朋友说起，今年RSAC创新沙盒入围的企业，感觉毫无新意和亮点，平淡无奇;紧接着另一个朋友有感而发，说及最近看到的分析师文章，总觉得炒冷饭和哗众取宠成分居多，也十分平庸;于是大家都纷纷聊起来，安全行业近两年创新不够。很有道理的观察，笔者完全同意。不过要补充一点：不是因为别人变矮，而是因为我们的眼界变高：过去四年，笔者亲眼目睹了国内安全技术的飞速发展，在某些领域，国内先进水平厂商至少能跟创新沙盒入围者相提并论，甚至还有明显胜出。即使国内行业大生态对创新并不友好，天量预算被巨头把持，去年业界增长也令人失望，但革新与开拓并未被遏制，无论是大厂或是初创小公司均有耀眼贡献。
于是，创新沙盒评论便愈发难写，介绍入围者的文章多到汗牛充栋，读者并不感冒浅尝即止的内容，堆砌华丽词藻更会被嗤之以鼻，笔者亟需找到一些独特的角度才能满足眼界变高的读者们的胃口。如果我们能抛弃吹捧，透过花哨探究本质，试图不放过产品和业务的弱点，对提高自己独立思考的能力便有莫大好处。
今年，让我们以拥有或依赖开源项目的创业公司作为开局。
Duality Technologies
创新沙盒也有赛道一说：密码学自然是一条，每年都会出现一家入围。在笔者看来，还要加上一条Team8：安全创业孵化器，班底是前以色列网络安全部队Unit 8200，每年必霸占一席。16年是Illusive，17年是Claroty，18年是Hysolate，今年便是Duality，拭目以待Portshift明年会不会出现。
Duality使安全的数据协作成为可能，企业可以将高级分析和AI应用于加密数据，无需公开原始数据即可获得对数据的洞察。没有惊奇，技术方向是同态加密的应用，17年入围公司Enveil也是。Duality，对偶，公司名字真是妙手天成，恰到好处地融合了应用场景与数学含义。
同态加密被正式广泛研究已经有十年历史，现有算法都是基于格密码(Lattice)理论的。Duality创始团队有两位大学教授，长期研究密码学，创建了开源项目PALISADE，高度模块化的通用格密码实现库，包含同态加密算法，有DARPA等政府机构的资金支持。这是个价值极高的基础设施级别的开源项目。题外话，Lattice-based算法是可以对抗量子计算机的，其实有很多加密算法在理论上也是安全的，并没有一般科普文章写得那么夸张;类似DH也可以用格密码改造。
Duality的产品是个多方共用的中间平台，官方设计了三种应用场景。
数据所有者可在不公开敏感数据的前提下利用第三方分析和AI，此过程中数据受到端到端加密保护。还可在不受信任的云环境中操作。
分析模型所有者能安全地将其模型提供给数据所有者进行高级计算和分析，能确保其宝贵的AI算法模型产权在整个过程中得到完全保护。
多方安全协作处理敏感数据。同态加密在链接和计算过程中保护每一方的资产，确保数据隐私和整个过程的法规遵从性。
请注意，上述三种场景对于算法的要求是有区别的。在隐私和数据保护监管收紧的大环境下，安全多方计算目前也是个大热点。大部分读者可能会以为保护数据隐私就够了;而实际情况是，分析函数的秘密性也要保护，这也是数学家们努力的方向之一。
格密码体制由于其运算具有线性特性，比RSA等经典公钥密码体制具有更快的实现效率;又由于该类密码体制安全性基于NP-Hard或NP-C问题，使其能进行量子防护。此外，格运算具有同态性，这也使格密码算法能适用于各种同态加密的应用场景。因此，有希望发展成下一代大范围应用的标准密码库。
密码学是信息安全的重要基石。但在历史上，除RSA成长为一家巨头外，几十年来专注加密的公司屡见不鲜，却难有大作为。而Duality是一家安全行业极为少见的、对重要开源项目拥有话语权的创业公司，笔者抱有很高的期望。
开源项目的经济原理与商业模式
过去二十年的互联网创新与开源项目息息相关。免费开发代码且使用限制极少，听起来美好到不像真实世界;因此，不少学者试图用经济学原理解释其背后的原因。自然也有不少投资者冲进来试图分一杯羹，不过理想丰满现实残酷，出现了很多失败案例。那么，创业公司和开源项目，应该是什么样的关系，才有成功机会呢?
如果我们仔细观察RedHat这几乎是巨头成功案例，就会发现其除了大家熟知的开源许可外，还拥有大量商业授权许可。而这些商业许可所维护的，是众多RedHat自研的核心代码，这才是其庞大帝国的根基。因此，衡量创业公司价值，无论是开源还是闭源，归根结底都会回到技术壁垒这一基础问题上。
有些投资者看项目，嘴上说的是看技术水平，其实内心深处对此不屑一顾，看的还是收入数字。听起来没问题啊，收入是不是衡量市场对技术认可程度的表现呢?卖开源发行版且销售能力不错的初创公司是不是值得竞相追逐呢?
这背后的逻辑值得商榷。首先，在今天，服务的壁垒已经不能仅靠人员团队了，信息咨询服务巨头Accenture也拥有很多代码和系统的积累，正如RedHat依赖其自有知识产权模块一样。安全行业里的MSSP也是如此：如果想提供SOC服务，自己没有一套先进的运营平台系统，是没有任何竞争能力的。其次，对开源项目的代码维护审批没有话语权的，那并不是产品公司，那是集成商;应该按集成商的商业模式衡量其估值。原因很简单，技术壁垒才有溢价，包装发行版无法获得溢价。第三，全球范围内，已经出现多起开源项目运营公司增加商业使用限制的许可条款的案例，这对卖开源发行版的业务模式绝对是当头重击。大部分开源项目是基础通用型的，需要找到合适应用场景才能大规模商业化。
而Duality正是一家满足上述逻辑的开源项目创业公司，笔者也希望其能挖掘在密码领域和行业应用的发展潜力，做大做强。下面我们再来看看其它有开源项目的入围者。
Capsule8
Capsule8是业界专为Linux生产系统构建的实时零日漏洞检测平台，无论是容器、虚拟机、还是裸物理机。官方宣传口径。你信吗?反正我是直接忽略。国内就好多做的，更甭提全球范围。创始人John Viega履历光彩夺目，业界资深专家，团队也有不少著名黑客。
主机防护，相信大部分读者都很熟悉，笔者此处就不过多介绍了，捡些Capsule8特有的讲讲。其产品平台强调的能力包括：可见、检测、调查、瓦解、集成，花了浓重笔墨渲染自动化防护。
Capsule8的开源sensor用Go写成，基于Kprobes，使用gRPC。笔者的反应，看起来是Google派系的。果然，稍后就翻看到官方视频专门演示与Google云管理界面集成，技术路线就决定其它云没那么容易集成了。当然，用Capsule8自身管理界面也可以支持AWS和Azure。多云也是有技术壁垒要克服的。
技术路线选择很费脑力，也必须认真，否则会导致事倍功半。Capsule8初创时的战略瞄准容器，自然Go是较好的选择，因为容器世界底层是Go语言的天下。生产环境中性能十分重要，虽然Go性能比不上C，尤其是Regex处理速度差距较大，而Kprobes开销也不小;但考虑到兼容稳定与未来扩展，如此选择还是蛮有道理的。
选择部署哪个开源agent这事儿也两难。Capsule8的sensor是轻，只采集跟安全相关的数据，主要有FileEvent、KernelFunctionCallEvent、NetworkEvent、PerformanceEvent、ProcessEvent、SyscallEvent、UserFunctionCallEvent、ContainerEvent等;部署一个agent只做0-day检测感觉性价比不高。不过，osquery在内核调用检测方面是短板，目前只支持auditd，Kprobes和eBPF的支持还在开发中，不知道要等到啥时候。甲方同学需要自己权衡。
采集主机数据之后，还要看看管理端是如何进行数据分析以实现检测的。
说实话，成立两年多的公司，这管理界面有些寒酸。大规模部署，看报警恐怕会疯掉。有查询界面也是题中应有之义，新产品需要支持威胁猎捕Threat Hunting。笔者最关心的检测技术说明，居然找了半天找不到。不提机器学习，不提行为分析，不提Yara，不提数据分析，总不会报警全靠人看吧。比赛上台面对评委时，难道也要回避这块关键技术能力不说?就看到演示界面里一堆Interactive Shell Executed了，貌似是基于一些预先定义的规则，不知道如何更新。
看过演示再对比这张安全运营能力图，结论是产品团队未来要走的路还很长。如此看来，Capsule8的开源项目也没多高价值。笔者只能去RSAC展台现场看看产品新版本做到什么程度。
Capsule8的投资者是美国两个频繁出手安全领域的VC：ClearSky和Bessemer (BVP)。有趣的是，他们与创新沙盒结缘颇深，在其投资名单上可以看到很多熟悉的公司，如这几年的Axonius、BigID、Claroty、CloudKnox、CyberGRX、Hysolate。
ShiftLeft
ShiftLeft是应用安全的持续改进平台，于自动化工作流中，将下一代静态代码分析(以快速准确地识别漏洞)与应用插桩检测(以保护生产环境应用)结合在一起。这种“理解运行状态的代码分析”和“理解代码的运行时保护”的结合提供了精确、自动化、和覆盖全面的应用安全解决方案。组合方案，前者是SAST，还有些许SCA，后者是部署在生产的IAST、以及RASP的混合体。官方宣传后者确实有些新意，能加快DevOps的速度。工作流如下图所示：
公司名起得也不错。Shift Left Testing，左移测试，是软件领域历史悠久的概念。这名词也让笔者回忆起小时候在单片机上拨动二进制开关输入左移位运算指令的操作。左移的含义，跟现在业内宣传的安全规划前移至应用系统架构设计阶段是类似的。将关键测试实践前移到SDLC早期阶段，尤其适用于敏捷开发、持续迭代、和DevOps场景。传统上，测试活动多发生在研发后期，往往需要更长时间才能找出问题所在，并且需要花费更多的时间来修复。左移是指将代码缺陷的识别和预防转移到更早的阶段，否则如果后期测试出问题，往往能做的就只是修补，而非正确的修复。
应用安全是行业持久热点，新方向新技术层出不穷。ShiftLeft吸引人的产品创新有两处，一是在静态代码分析时引入图算法，比之前传统代码检测算法能更好地发现某些类别的漏洞;二是在静态分析阶段引入所谓安全DNA概念，用于指导生产环境中的IAST和RASP的执行。
首先，SAST的创新来自于学校研究，基于代码属性图CDG的漏洞发现，论文如下。
此研究成果诞生了开源项目Joern，可以扫描Java和C/C++代码，并生成三类属性图：抽象语法树、控制流、和数据流。再使用图算法用自定义查询就能发现潜在漏洞。值得吹嘘的战绩，一次性发现Linux kernel里的18个新漏洞。显然是高价值的开源项目，吸引了很多眼球。ShiftLeft成立后，Joern得到继续发展，现在的产品名称为Ocular。官方称目前OWASP基准测试成绩较好。当然，没有银弹，图算法也不能通吃所有类型漏洞。下图展示了如何用CDG发现代码中潜在数据泄漏的弱点，很有趣的思路。
而所谓安全DNA，是指容易出现弱点的代码位置，例如引入第三方开源库、模块间传递参数、敏感数据使用等等。所谓MicroAgent，实质就是程序插桩，保证程序原有逻辑完整性的基础上，插入一些探针进行信息采集，还可以根据预定义策略做些简单响应。有了开发阶段静态分析产生的安全DNA信息，插桩可以更有的放矢，检测效率更高，降低误报。通常，快速开发迭代过程中，时间不够用来修复所有潜在问题，必须有所取舍;而未修补之处是否存在风险，可以放到生产环境继续监控。此种方式也加快了DevOps进程。
之后，将这些报警传回控制台，再用来反哺开发代码阶段，于是便覆盖大部分SDLC和DevOps流程。
延伸思考，Joern自然也可以用于红队。上面提到过，CDG可以绘制数据流，那么自然而然地我们会想到，合法数据输入可作为暴露在外，如果能梳理此输入数据在程序中被处理的代码段有哪些，我们就可以有针对性地检查，那些代码段中是否存在没做好“消毒”的地方，例如内存越界。Heartbleed漏洞即属于此类型。如果没有数据流图，在庞大代码量中，准确定位并发现潜在风险，只能靠运气了。
这个实例说明，只有掌握了新的技术，才能在对抗中获取有利位置。再优秀的安全团队，没有先进工具的武装，战斗力都会大打折扣。
篇幅所限，笔者就不深入解释了。目前看产品完成度较高，在创业公司里算出类拔萃的。与其两轮大额融资也有关，毕竟钱多更容易扩大团队完成更多工作。
上面讲到的三家拥有开源项目的入围者，读者更喜欢哪个?
不知道大家有没有注意到，ShiftLeft也符合笔者前面所讲的开源商业模式。以开源Joern为基础，识别巨大市场需求，补充整合优秀人才，继续开发更先进的技术模块，组合成更复杂的产品，建立竞争壁垒。成熟完整的管理团队，从开源项目中发现潜力新秀，用股份相邀所有者亦即学院派研究人员，强强携手，再造商业公司，如此套路在今天已经屡见不鲜。Duality也是相同轨迹。
如果哪位读者对自有研究成果信心十足，欢迎找笔者聊聊。我们在采用先进技术打造全球领先产品并服务好各行业头部用户这方面，积累了不少成功经验。
DisruptOps
DisruptOps为多云基础设施提供持续自动化监控的优秀安全实践，以提升云业务运营的安全性并降低成本。读者也许已经在朋友圈看过此公司的介绍文章，都是唬人的名词：多云、自动化、敏捷、编排、DevSecOps、持续评估、优秀实践、云原生等等，还发明了Guardrail护栏一词的新用法。
多云管理市场的商业机会与重要性，笔者在去年创新沙盒文章就强调过。然而，DisruptOps你是在逗我嘛?翻遍其网站，所有能力都是针对AWS的，说好的多云呢?笔者开始时还不相信自己，以为漏掉重要内容，于是专门用了搜索引擎：
未见任何Azure踪影，确实只有AWS。目测DisruptOps平台主要使用AWS原生安全产品的API来构造，如Config、CloudWatch等;Serverless架构，大量使用Lambda脚本。若打算将界面设计和产品功能，原封不动从AWS移植到Azure，难度不小，工作量巨大。正如上面评论Capsule8时所指出，多云也是有技术壁垒要克服的。
DisruptOps创始团队包括安全咨询公司Securosis核心班底，历来产出的研究和文章质量很高，笔者进入安全行业之初便拜读过。可想而知，他们深谙使用专有名词忽悠客户之道。我们看到国外初创公司也不容易，吹嘘是为了生存。DisruptOps成立于2014年，时间不短了。当然，也是因为DisruptOps客户群体看不到本文，所以笔者才会如此直接落笔。
说实话，笔者浏览此公司网站之后的反应：这不是个产品公司，罗列的都是内部安全运营规范。优秀实践美则美矣，但如此定位的商业模式，能否持续增长是个大大的问号。读者们肯定见过各大厂自建开源的GitHub内容扫描工具，但业内见过厂商推出类似的标准化产品吗?做安全产品要有足够的能力护城河，才能维护市场竞争优势，靠些零散拼凑的配置核查脚本集合，就能建立壁垒吗?需求并不一定等于生意。
什么产品能力可以做护城河?举个简单例子。文件格式解析引擎，用于拆解并导出各种格式文档中的文本图片等内容。迄今，全球成熟商业化供应商只有两家，一家是MicroFocus的KeyView(之前归属于Autonomy和HP)，另一家是思睿嘉得。KeyView不支持导出DWG等CAD图纸中的文本，而后者的引擎可以;KeyView不支持百度网盘大文件分卷上传的还原，而后者可以;等等。全球绝大部分DLP厂商都是外购引擎，从而受制于供应商的缓慢更新延迟;而思睿嘉得掌握全部自研代码，拥有更低的成本、更优秀的性能实现、更灵活的接口控制、以及对最终用户需求的快速响应。唯有多个类似的、友商难以复制的技术能力，再加以堆叠组合，才能有效巩固产品优势。
定期更改访问密钥AK是一种众所周知的安全实践。缩短AK有效时间，即使泄露，业务受到的不利影响也能被缓解。DevSecOps的实施难点，是如何定期生成新AK并准确分发，令使用对应旧AK的所有应用程序自动更新，保证交接顺畅，不会造成任何故障。而DisruptOps产品确实能发现老旧的AK，但之后提供行动的选择只有区区四个：删除、冻结、挂起等着手工操作、以及忽视。这怎么嵌入到DevOps流程里?隔靴搔痒的鸡肋，到底是用还是不用?另一方面，Access key age属性，可以直接去Console查，或者写Lambda脚本集成到自有DevSecOps平台里也易如反掌，让大甲方花钱买这个短板明显的功能有难度，而小企业有没有人手跟随优秀实践也难说，还面临着云服务商不远将来也提供类似功能的竞争，例如AWS Inspector或GuardDuty加入此类报警轻而易举。
总体来看，产品成熟度很低，过于简单，只提供初级安全基线检测，且未见灵活配置和扩展功能。概念不错，落地差得太远，技术门槛低，甲方评估后恐怕会得出采购不如自研的结论。从另一个角度看，DisruptOps倒是提供了一组基础安全范本，云安全团队初建时可以拿来作为起步参照。
